fedward, tumbling

goes on, and the heat goes on
~ Friday, November 6 ~
Permalink

Mac OS X: Do not remove or modify the SyncServices folder Last Modified: September 18, 2009 Article: HT1865 Old Article: 301920

Summary

As if it were a swarm of bees, you should stay away from the SyncServices folder. Removing or modifying anything in the SyncServices folder—or in any subfolders within it—may cause unexpected issues. (This folder is located in your Application Support folder, in your Library folder, in your Home folder.) Deleting or modifying things in the SyncServices folder may cause unexpected results such as:

Duplicate contacts in Address Book or appointments in iCal. Data loss in Address Book or iCal. Important: Any lost or duplicate data could propagate to other devices and computers via iSync and MobileMe sync. This means data could be lost on other computers.

(via tbridge)

Have you looked at the internals?  It’s Perl.  Of COURSE Perl programmers write documentation like that.

Tags: reblog mac os x Perl SyncServices
1 note
reblogged via tbridge
~ Wednesday, July 29 ~
Permalink

What’s the Deal with PHP?

I write code. I maintain servers. I’ve been doing this a long time, and I’m curious:

Am I that stubborn or are that many people just doing it wrong?

In my professional history I’ve written and/or maintained code in the following languages and/or environments:

  • Perl
  • Java
  • C# / .NET
  • C
  • Objective-C / Cocoa
  • PHP
  • Javascript
  • Visual Basic

In addition I have at least passing familiarity with Python and Ruby, although my coding experience with them amounts to a couple lines of debugging in each.  So I feel pretty well qualified in saying that some technologies are better suited for the ways they’re being used than others are.  I know the knock against Perl is that it makes it too easy to write bad programs, but I’ve seen a lot of bad PHP and Java — and I’ve never seen good Visual Basic. The bad Java was in an enterprise-class, critical-level-support-guaranteed application that reliably crashed the server under 1/3 the load the company promised its customers it could handle(1).  From the people I’ve worked with I’d say that smart Perl programmers are much easier to find than smart Java programmers are. That’s not to say that there are no smart Java programmers (I know a few), but that my experience leads me to distrust the companies that rely heavily on it.

1) The flaw was in management of a database handle. The database interface was simple, by-the-book Java, and the server would run out of resources. I wrote the testing program that identified the flaw, but other people were responsible for writing and fixing the code. I’m pretty sure it wasn’t a singleton implementation, and I think there were reasons for that, but I’ve long since forgotten why it was built the way it was. All I know is it didn’t increase my faith in Java as an application platform.

PHP, though, just mystifies me.  From my experience with it I get the idea that PHP makes it even easier to write bad programs than Perl does.  I’ve written a few extensions for PHP apps, and every time I find myself dealing with issues of variable persistence and scope I never have in Perl.  I LOATHE the way it handles regular expressions.  I don’t see anything in PHP that lends itself to more rapid development than you get with Perl, and I feel like the server lacks the all-around robustness you get with Perl.  I’ve also had a harder time debugging PHP than I’d expect(2). Plus there’s the whole mixy-mixy thing with HTML and code, about which my feelings are, well, mixed(3).

2) This probably comes down to scoping, where I expect things to work the way Perl does them, and PHP seems to have its own understanding of when a scoped, private variable should cease to exist (much later than I expect it to, usually). But there were other issues too.

3) The mixy-mixy can be useful, but it can also be hell on earth, but even the useful stuff turns into hell on earth after a few months or years of maintenance and feature requests). When I saw a ColdFusion demo at Internet World ten years ago I thought it was what my company should have been using for its code and I pushed for an implementation of it. Now that I’m older and wiser, though, I just get headaches thinking about managing two different types of code in the same files.

Set me straight, though. Am I just looking at it the wrong way? Is PHP, in fact, awesome? Are Java application servers now more robust than I once knew them to be?

Also also, all the young Turks now either seem to be using Python or Ruby. Python I get. I’ve never written anything in it, but it’s solid, stable, etc. Ruby, though? Seems like yet another solution for a problem you could have solved with, well, Perl or Python (to name two). Is Ruby really all that, or is it just that the young Turks are starting out with it, so they don’t know what else they’re missing?

Tags: PHP Perl Java ColdFusion technology Ruby Python
~ Friday, July 3 ~
Permalink

More Administrivia

A month ago, as noted in this post, I turned off the import of my twitter feed into this here tumblelog.  I looked into deleting the imported posts just to clean out the archive, but it seems that the tumblr people didn’t choose to make such a thing possible (they’ll allow you to delete your whole site, but not selected posts in it).

Last night I got curious about the problem again, and discovered that the API will let you delete posts, so this morning I hacked together a quick script using the WWW::Tumblr Perl module, and I have now deleted all those posts.

Oddly, the API still says I have almost 1000 posts, even though the web interface properly displays only the ~100 I didn’t delete. I’m not sure what that’s about at all.

Anyway: this will have broken Google’s archive links, but I’m OK with that. If you’re interested in the minutia of what I have for breakfast, follow me on twitter.

Tags: tumblr twitter perl API
~ Tuesday, June 23 ~
Permalink
I’m not just decommissioning computers around here. Unless, well, you consider the TiVo to be a specialized computer, in which case I’m still just decommissioning computers. Anyway, there are two DirecTV/TiVo combo receivers that have been sucking down electrical power solely for the purpose of serving up stored programs since I canceled my DirecTV service almost a year and a half ago. I’ve scripted the copying of those stored programs onto the computer plugged into the TV, which has a 1.5GB HD and thus plenty of room for them.
Interestingly, I tried recompressing the MPEG2 files into H.264 MPEG4 and the got larger instead of smaller. I tried turning the compression up to the max, but then they got noisy instead, which isn’t worth the trouble. So I’m just going to store everything in MPEG2. VLC can play it just fine even if Quicktime can’t. If I ever pick up an AppleTV I guess I’ll deal with the format problem then.

I’m not just decommissioning computers around here. Unless, well, you consider the TiVo to be a specialized computer, in which case I’m still just decommissioning computers. Anyway, there are two DirecTV/TiVo combo receivers that have been sucking down electrical power solely for the purpose of serving up stored programs since I canceled my DirecTV service almost a year and a half ago. I’ve scripted the copying of those stored programs onto the computer plugged into the TV, which has a 1.5GB HD and thus plenty of room for them.

Interestingly, I tried recompressing the MPEG2 files into H.264 MPEG4 and the got larger instead of smaller. I tried turning the compression up to the max, but then they got noisy instead, which isn’t worth the trouble. So I’m just going to store everything in MPEG2. VLC can play it just fine even if Quicktime can’t. If I ever pick up an AppleTV I guess I’ll deal with the format problem then.

Tags: TiVo Perl TiVoTool