Archive for 2009

Kenta’s Free Time

Tuesday, August 18th, 2009

The Pig(Log)

Tuesday, August 18th, 2009

I have few reasons to like Twitter, especially given how disjointed its Ruby On Rails underpinnings seem to be. With that said, it conceptually works for the terse musings that makeup The Pig‘s day.

Hopefully he can build a legion of followers and rise up as the benevolent dictator we all envision him to be, or showered with offerings of cold-cuts.

Snow Leopard Pre-Order

Tuesday, August 4th, 2009

If you’re planning on pre-ordering Snow Leopard from Amazon, then use this little banner so we make some referral money.

Thanks.

Recent Apple Store Layoff?

Sunday, July 12th, 2009

Early last week (June, 6th) I was trying to make a Genius Bar appointment at the 5th Ave. Apple Store. Normally I cannot make one any sooner then a day away, but this time I couldn’t make an appointment at all, for any day. Instead I was prompted to check availability at other Apple Stores. The only available slot was at West 14th St. for some time Friday night, which I was not ready to sacrifice. This implied virtually no availability at any of the Manhattan Apple Stores for the next three days, aside from that one inconvenient slot. Only a few weeks prior I was able to make an appointment with selection of times to choose from, without even having to consider other stores.

While I found this odd, I assumed it must be related to the 4th of July weekend that had just passed. I tried again on Tuesday morning and didn’t find any open slots. It prompted me to check stores outside of the city. A second attempt was made that evening with the similar results. Not until Wednesday was I able to make an appointment in one of only two available times-slots, across all 3 Manhattan stores.

When I went in for my appointment I offhandedly asked if this was an issue of staff on vacation. I was instead told this was the result of a significant reduction in the number of Geniuses. This came as a surprise given the recent release of the iPhone 3G S and the large queue of people downstairs waiting to buy one. I speculate that this is recent and the stores have done their best to keep things quiet, though this could be a continuation or result of announced layoffs a few months back.

While I don’t suspect this will impact the overall quality of service, it does make it more difficult to get it in a timely manner and throws out any possibility of walk-ins. The whole concept of the Apple Genius as a manner for accepting repairs and troubleshooting is nothing short of a luxury when compared to the mail-in alternative. Hopefully this is just a short term cost saving tactic for the summer and not a sign for things to come.

AIM Push Notification and Multiple Sessions, Who Wins?

Sunday, June 28th, 2009

A question was recently posed by a friend. He noticed that as long as his AIM client was signed in on the iPhone, actively or just for Push Notification, that messages would no longer be sent to his desktop client anymore. This sort of behavior could render the “always signed in” Push Notification useless if the desktop client can no longer receive messages while the iPhone application is considered to be signed in.

It turns out that AOL uses a precedence order in deciding which client should get the message, or in some cases both. Here is the precedence order:

Available (1)
Away (0)
Idle (-1)
Invisible (*)

AIM clients with the same precedence “score,” the number in parenthesis, will get the same message. If one client has a higher score, no other clients will get the message. Idle time will subtract one from the score. Available + Idle is the same thing as Away + Active.

For example if both clients are Available and not Idle, both will get the message. If one is Available and the other Away, the Available client will only get the message. Here is where things get interesting, if a client is Available and Idle, and the other is Away but Active both get the message.

The most effective way to use both the iPhone AIM client and a desktop client like Adium, iChat, or AIM, you need to have the desktop client set to Available and the iPhone client set to Away. The desktop client shouldn’t be set to artificially Idle, or both will get the message.

This is a little annoying because I tend to set Adium to Away all the time. Going forward to utilize AIM for the iPhone I’ll have to keep available and not idle, otherwise messages are going to start appearing on my phone. I guess this promotes some additional honesty about my actual status.

I hope this solves the mystery for someone. I couldn’t find anything too definitive elsewhere on the web.

*Note: Setting Invisible in one client changes your status in all logged in clients. It’s not possible to be Away in one, and invisible in another. I was hoping I could leverage this somehow by setting the iPhone to invisible so that it would only get messages if the desktop client went offline.

Now with Fancy

Thursday, June 25th, 2009

A quick post just to point out the obvious, the blog has a new look. More on this later, but Kenta is to thank for the design.

Enjoy.

When BS is so bad it hurts

Thursday, June 25th, 2009

It appears that Movable Type has been forked into a new project called “Melody.” Now this is why I love Open Source software, if something isn’t working right fracture the code, take some of the developers, and subdivide the user base. I understand that one piece of software can’t do everything. By all means it shouldn’t, but there doesn’t seem to be any driving goals of this project that aim to make it vastly different the Movable Type.

A quick read of the sparse About page and FAQ, seems to indicate that this fork is driven by the need to work with the community more. In other words they don’t have any unique design principles yet, but invoking the term “community” implies that we soon will have all that we’ve been missing from Movable Type. They suggest trying to be more like WordPress. Maybe that means documentation that isn’t habitually wrong. I’m not sure.

On face value it looks like some sort of internal fallout happened. When you drop all of the idealistic bullshit, thats the most common reason for a fork. Two people couldn’t agree and they go their own way but try to make it look all happy and mutual, as if this will somehow be “better for everyone.”

The way I see it, Movable Type has been trying to become a CMS and failing miserably. It’s once rapid rate of progress during the 3.x builds has become a snails pace under 4.x., and this fork may finally kill it or get SixApart off their asses and take a look at what their actually trying to accomplish.

Internet Explorer 6 Duplicate Characters Bug

Monday, May 11th, 2009

Just for reference if you come across the old issue with IE 6 duplicating characters at the end of a block of text, check out this article at Position Is Everything.

Opening a Link in a New Window, and How Not To

Friday, May 8th, 2009

I often tell everyone here to avoid examples of JavaScript on the Internet, because more often then not it’s incorrect. The same goes for most of the popular examples of how to cause a link, an A tag more specfically, to open in a new window.

The most popular and incorrect way is using the target attribute:

<a href="http://www.example.com/" target="_blank">Using Target</a>

The target attribute was meant to direct content to load in a specific frame. In this case the keyword directs the browser to load the page in a new window, but with frames long dead and gone this little gem lives on as a reason people “can’t use HTML Strict.”:

The most common solution that people came up with this was to use JavaScript, but in some strange ways. Instead of opening the link directly, the page would go to an anchor and JavaScript would open the URL in a new window:

<a href="#" onclick="window.open('http://www.example.com/');">Using Onclick</a>

The HTML will validate, but if JavaScript is disabled the link won’t go anywhere, and it can’t be copied via a contextual menu. On top of that clicking on the link will cause the page to jump to the top, unless you add “return false;”:

<a href="#" onclick="window.open('http://www.example.com/'); return false;">Using Onclick</a>

Another approach to avoding the jump was to place JavaScript within the href attribute:

<a href="javascript:window.open('http://www.example.com');">Using inline JavaScript</a>

While inline JavaScript has its novel uses, this isn’t one of them. This method doesn’t offer much over the previous one and can be complicated even further when a wrapper function is called instead:

<a href="javascript:wrapperfunction();">Using inline abstracted JavaScript</a>

The only way to fix the issue of JavaScript being disabled was to put the link back in the href attribute:

<a href="http://www.example.com/" onclick="window.open('http://www.example.com/'); return false;">Improved use of onclick</a>

Using “return false;” stops the link from executing, allowing the URL to be put back in the href. This is the farthest I’ve seen any site go. it’s technically complete, but redundant. One last bit of JavaScript fixes that:

<a href="http://www.example.com/" onclick="window.open(this.href); return false;">Ideal use of onclick</a>

The redundancy is elimanted by using this.href. “this” refers to the current object in context, being the A tag. The “href” references the A tags href property and the value (URL) contained within.

The end result is a small generic addition to any A tag to make it open in a new window. The tag will pass HTML strict validation, “SEO” is preserved and if JavaScript is disabled everything keeps working.

Basecamp Writeboard & Message Erratic Formatting

Friday, May 8th, 2009

If you rely heavily on Basecamp, a project management service by 37signals, then you’ve probably run into issues with erratic formatting in Writeboards and Messages. The contextual documentation is sparse at best and doesn’t explain how to stop the unintended formatting caused by the inadvertent use of reserved sequences.

Through a little experimentation, it seems that most HTML tags are left unencoded. While unexpected and also potentially problematic this behavior has it benefits. The <code> and <pre> tags – and possibly more – turn off the Basecamp formatting engine and make it possible to preserve text that would otherwise be mis-formatted.

So next time you notice strange formatting, try surrounding your text in either <code> and <pre> tags. Remember that while these tags won’t show up in the message itself, they will appear in any notification e-mail, but the same is true for standard Basecamp formatting.