Colourmod is a Dashboard widget for Mac OS X that you’ll end up using much more than you think you would. I’m not a designer but as someone who fiddles around on the web I find myself in need of a hexadecimal color code from time-to-time. And when I do, I use Colourmod.

There are a few ways that I find myself using Colourmod to find the color I’m looking for. The first, and perhaps most obvious way, is to drag the “blue dot” color picker around the main color well and find the color I want making subtle adjustments by using the slider. The second, is to manually enter in the hexadecimal color code that I’m currently tweaking and make small changes until I get exactly what I want.

One nice feature is the blue arrow that will quickly copy the current color code and place that value into your clipboard. This makes finding, selecting and copying a color code into your text editor very, very quick.

Feature suggestions? Sure. One thing I’d like to see is a single text area that gives the proper RGB color values for a color. Although Colourmod supplies these values they aren’t easily selected. I’d also like to see a much easier and more accurate way to use the color picker. It is very tough to make small changes especially to light gray colors.

Oh, and I’d ditch the ‘U’ in Colourmod. But that’s just me.

One of the distinct features in the Path app is the fly-out menu that allows you to share photos, comments, location, etc. Two developers took it upon themselves to build out that menu both in CSS3 and using CoreAnimation. Both open sourced their work and gave credit.

• Path menu in pure CSS 3 by Victor Coulon.
• Path menu using CoreAnimation by ??? (Levy)

/via Mike Rundle on Twitter.

This site makes, at most, 39 connections and is, at most, 12Kb or so larger than the largest photo I post. Most of those 39 connections come from the WordPress plugin that I use to show the location in which I published the post. I’m thinking of disabling this plugin and if I did my site would go down to well under 12 connections.

This recent tirade is a good excuse to revisit the site(s) that you administer to see if you can cut some cruft.

/via John Gruber.

/via Kyle Neath on Twitter.

“Broken windows are the reason most large software projects suck to work on. A little technical debt here, a few shortcuts there, and pretty soon you’ve got a codebase so full of broken windows that no one even cares if they throw another pile of broken glass on the heap.

But just as broken windows are contagious, so is a dedication to quality. Carve out a little piece of a messy codebase and clean it up. Sharpen the edges, polish the surface and make it shine.”

This bubbles all the way up to the top of the product too. The code of a not-so-great feature can be gorgeous but it is still a feature that isn’t quite right. Focusing on the quality of the product from the engineering to the coding to the marketing is also contagious.

Shaun Inman, who just released The Last Rocket for iOS, put together a quick game called Data Entry Sentry that works on an iPad (or any Webkit browser). Fun to play. I don’t know where he gets the energy.

“Can I take some time to clean up this code? It is horrendous.” The answer should always be yes to this question. However, often times we find ourselves up against walls in the form of budgets, time, due dates and expectation and so the typical “powers that be” at companies often veto the request. My advice to you, dear developer, is to never ask for permission for things you know are vital to your work.

You know your work environment better than I do so perhaps you can ask this question and immediately have the full support of your team. Sad to say that many aren’t so fortunate. They’ll ask their boss if they can take some time to clean up their code, make it efficient and extensible and, while the boss may recognize the need for such tasks, ultimately the boss will simply say “maybe we can do that later”.

Why is this the typical reaction? Because bosses don’t have to read, edit and support the code.

This is folly and every developer knows it. Bosses, (if you’re reading this) putting off a few hours worth of code clean-up now will only turn into many hours or days in the future. So by allowing your developers time to do this much needed code maintenance you’re actually saving your company money. But don’t worry – they’re not going to ask you for permission anymore. They’re just going to do it.

We’ve set up a special page on Viddler just for Magic Ruby to help let people know some of the things we’re already doing with the Ruby community. We hope to learn a little about Ruby, to let attendees know about Viddler, and to enjoy the weather.

Viddler’s offerings to developers aren’t limited to only Ruby. We’ve got a fantastic API that has been recently overhauled and wrappers for just about every language. We power some of the biggest brands online and our platform has been used to power web sites, applications, iPhone and iPad applications and much more. I personally hope to help Viddler grow in this area in 2011.

If you’re a developer and ever have any video needs – consider using Viddler for your next project.

My handy dandy little script that makes it easy to parse an RSS feed and send links to Twitter using PHP just got a nice little update. It now supports OAuth and has been cleaned up quite a bit.

Oh, version 1.0 is still available.

I’m working on a relatively big update to Viddler’s WordPress plugin and something that doesn’t seem to be documented anywhere is how to test a Dashboard Widget if your plugin supports one.

It is fairly easy to add just a bit of code to make it pretty simple to test your widget. First, rather than only loading your WordPress Admin URL (ie. yoursite.com/wp-admin) you simply prepend the appropriate information to the end of the URL. Like this: yousite.com/wp-admin/index.php?page=viddler&noheader.

Then, somewhere within your plugin’s code, you add something like the following:
function viddler_page() {
if ( isset( $_GET['noheader'] ) )
return viddler_dashboard_content();
}

Obviously viddler_dashboard_content() is the function that I use to build the HTML for the Dashboard Widget. This will return the HTML you’re creating for your WordPress Admin Dashboard Widget sans JavaScript and CSS. But at least you’re able to test your output.

/via the Viddler Developers Group.

Doing JavaScript for mobile platforms? Maybe you should check out Zepto.js.

Update: Via Kyle Slattery on Twitter: Sencha.

I haven’t yet had any experience using jQuery mobile (I simply do not do too much JavaScript anymore) but I wanted to make sure that any “competitors” to such a popular framework gets some attention. Does that make sense?

For more information, see the Viddler developers page.

Note: If you are using Google Reader you may not be able to see this video. The Reader team is dragging their feet on supporting Viddler’s latest embed code. Come on over to my site to see it.

Recently Drew wrote up the backstory to how this all happened and it is a fantastic read.

Last night I ran into such a problem wherein, so far at least, I’ve been unable to find the cause. It is very frustrating. Trial, error, trial, error, hunt, poke, literally cause my app to crash on purpose hoping I can find the problem, comment out line after line after line, change settings, etc. Usually during this process I will end up breaking my application even more and forget how to change it back (thank goodness for Git).

The problem I’m currently having seems to be environmental. The problem doesn’t exist in one environment but does on another. This actually causes even more fist-pounding because I know my code works.

The part about this process that is most frustrating is that the time spent solving one of these minor problems (that have a major impact on the app) could be time spent making a great application. It is my least favorite part about programming. Nowadays it is possible to accomplish an incredible amount of work in a short period of time yet, still, you run into these little time wasting seemingly no cause no solution problems that take a very long time to work out. Grrr!

Although it may seem like an anal attempt at control style guides can go along way in making a lot things easier in the project workflow. Reading through and fixing bugs in someone else’s code, less conflicts will occur when merging branches and the speed at which new features can be added are all fringe benefits.

As Jon said: “It helps with everything from readability to quality control and especially helps a team become that much more cohesive.” So, do it.

Pie Guy is a fun game for your iPhone that is free, is installed via the Web (it is a fancy Web page), works offline, and is actually a lot of fun (works sorta like Pac-Man).

Neven Mrgan, the developer of Pie Guy, built the game – not only so people can enjoy the game – but to help show what is possible via HTML, JavaScript, and CSS for building games or applications on the iPhone using the Web browser rather than native cocoa technologies.

“If you find Pie Guy a fun game to play, well that’s grand.

But, I hope Pie Guy will also be an opportunity for the code-savvy among you to learn a trick or two about making serious web apps for the iPhone. Just grab my source code and tweak it. I’m not talking about just a fancied-up webpage here; this is a fullscreen game, with fast gameplay and responsive touch controls. I can’t wait to see what a better programmer does with this stuff (it’s not hard to program better than me!)”

A very notable thing to do and I hope a ton of talented developers take him up on it. I’d love to see stuff like jQuery for iPhone games/apps (which I’m sure exists in some form or another).

Also of note: As Neven pointed out in his announcement post – don’t try this on your first generation iPhones. This game only performs well on an iPhone 3GS.

/via Simon Willison.

Viewing the source of a page on Google Chrome is, for the most part, a terrific experience. Chrome supports syntax highlighting of the underlying code of a page making it much more readable for us geeks while we look under the hood.

However, something I’ve run into of late is that it doesn’t work very well for dynamically generated pages. The issue seems to be that since Google Chrome opens a new tab to view the source of the current URL that you’re on, it actually “reloads” that page with new session data, as well as ditching all of the POST variables you may have sent to it. This causes some confusion and may lead to head scratching (as it did for me).

I don’t know of a work around currently but knowing this may save you some time.

Side note: I’m loving Google Chrome for Mac.

/via Mike Rundle on Twitter.

• Use your own API. The very best way to make sure your API is equipped with everything one would need to build something of value is to use it yourself. You will find that by using your own API to build your product you will work out a lot of kinks that would otherwise frustrate third-party developers.
• Remove as many learning curves as possible. An example of this is to provide more documentation than you really need to by writing tutorials and not just flat documents. Code examples go a long way too. Provide “wrappers” or frameworks in common languages that help third party developers to “plug and play” with your API.
• Follow standard conventions. This is related to removing learning curves, but you do not go against the grain. Try to utilize as many standards as possible. Chances are any third party developers that use your API will already be familiar with much of what you’re doing.
• Support multiple response types. Do not assume that third party developers will only use the response type that you prefer. Supporting XML, JSON, PHP, and others is not too much more work and yet has a measurable impact on your APIs adoption.
• Create and keep your own conventions. If you have one way to do things try to stick with it all the way through your API. An example of this would be how Twitter recently added a Lists API to their API and used the very same convention of interacting with that API as they do with accounts. This makes integration of new features dead simple and it will be appreciated.
• Add some brains! If there are common actions that must be taken by all third party developers to interact with your API try to build those actions into the API. A good example of this is Flickr’s support for machine tags. Although a third party developer could do all of the work on their end to work with namespaces, predicates, and ultimately the values they are looking for – Flickr makes it easy by doing all of that work on the server-side. Taking the most common actions and rolling them back into the API will slowly build tremendous value in your API.
• Open source as much code as you can. If you build any tools, frameworks, testing applications, products, or anything that uses your API – try to release that stuff as open source. This will help any new third parties to be able to see real examples of products that use your API. It would also be a good idea to promote open source projects to use your API as well so that the entire development community that you build can benefit.
• Communicate with those using your API. Give the developers a clear path to communicate with you about your API, their applications, or anything they may need to get their jobs done. You will learn a lot about what you are lacking that you may have never thought of.
• Drink a lot of caffeine.

These are just a few tips that I’ve learned in working with Viddler‘s development team to build our API. We’re currently working on the next version of our API, dubbed version 2, and we’ll be making massive improvements to the way that the API works, is documented, and how we use it internally. We’ve learned a lot over the last few years and we’re taking all of the tips above and everything we’ve learned from our development community to build what we think is a much more solid offering.

I hope that if you are building an API you can learn from our experience, our failures, and our successes (and I’ll try to share more of them here). If you have anything you’d like to add about good API design please do so in the comments.

The photo of the fire hydrant has nothing to do with this post but I liked it. It is one from my Lincolnton, North Carolina photo set.

I’ve been dabbling with zen-coding plugins with Coda for about a week. Loving it.

“The Viddler team is using CodeIgniter more and more for our internal PHP projects. Obviously we need to use CodeIgniter with the Viddler API quite a bit so we figured we’d share with you how easy it is to include PHPViddler, the open source PHP API wrapper class for the Viddler API, in your CodeIgniter application.”

Read more in the blog post titled How to: Use the Viddler API with CodeIgniter.

Speaking of Code Igniter, Jonathan Snook (way back in March 2007) compared it to CakePHP. Although both frameworks have matured slightly since then, this overview still holds up ok – although he is a fan of CakePHP where I’d choose Code Igniter. Thank goodness for choices.

Go forth, and hack! Oh, and its completely open source too. (More on this later.)

I couldn’t agree more. I’ve been using this solution for some time now – in fact, many of the Viddler team members have. It strikes an excellent balance between simplicity, ease of use, and efficiency to help us get our work done.

Source: Friday Favorite: Coda + Versions + Beanstalk.

Pickles helps out. Circa January 2007.

Viddler’s player is, in my incredibly biased opinion, the best Flash video player available. Especially if you’re of the sort that likes to engage in conversation or put an incredible amount of metadata in your videos.

Using Viddler’s API for various projects has always resulted in some sort of learning experience for me. Not only in using APIs in general, but in how to best utilize Viddler’s platform, player, API, etc. etc. to get the best results. This helps to improve Viddler’s services, but also the Web at large.

One of the things I, and the entire team at Viddler, have learned is that most people want their player to perfectly wrap their video. That is, they’d like their video to be as chromeless as possible while retaining the conversational quality of the enhanced timeline that Viddler affords.

Knowing this we were excited when oEmbed, and its underlying methodology, allowed for this to happen programmatically.  This made it rather easy for developers, such as the team at Pownce, to use this service on Viddler to embed videos knowing only the URL assigned to it, in a way that shows off the quality of the player, and keeping the aspect ratio of the video that the publisher created. Perfect.

That one underlying and undocumented feature of oEmbed, that is, that the response from oEmbed was an embed code with the dimensions perfectly suited for your video based on a maximum width – is what I think will make the following JavaScript useful to developers using Viddler’s API.

The response from the API method of viddler.videos.getDetails includes the dimensions of the original video uploaded.  It does not, however, include the embed code of the proper dimensions given a specific width. You have to either figure that out own your own, use oEmbed (which is yet another call), or do the math yourself.

Included in this simple ZIP file is both the JavaScript and PHP functions you would need to determine the appropriate height for a video given a specific maximum width.  These files do not include the ability to use the oEmbed service. For that, you will need phpViddler or your own homegrown way to call that service.

Happy embedding!

John Nunemaker, of Ordered List, decided that Cabel’s implementation of this effect could use some improvement.  Not only was Cabel’s “built from scratch”, which means to say that he didn’t take advantage of any of the Javascript libraries that so many web application developers already have included in their projects, but it also relied on AJAX to load the frame’s contents.

What that means exactly, is that Cabel’s implementation retrieved the data for the “pop up” window the moment you clicked, whereas John’s actually loads all of the “pop up” window’s data that he needs on the initial page load.  Obviously both of these methodologies have their place, their pros, and their cons, but it is all about choice, isn’t it?

The one thing I do like about John’s implementation over Cabel’s is that it allows for just about anything to be loaded in the “pop up” window rather than only images.  But this is only a small distinction in that Cabel’s code could be easily modified to allow the very same thing.

Now, if someone would take the time to simply port this to jQuery so that I don’t have to…

Source: FancyZoom meet Prototype.

Especially on today’s Internet. I’ve had “my own site” for as long as I’ve ever been online. It all started on some Geocities and Tripod powered sites in the mid-90s. Then, when I switched from using AOL  (read: When I finally realized AOL was not the Internet.), I used some shared space on Prodigy.net, my ISP at the time. It wasn’t long before I discovered the world of Web development and purchased a domain (then called colinspage.com) for around $70 per year.

Fast forward about a year and a few of my friends put together a Star Wars related news site called thehutt.net. I didn’t help out too much with the design and development but I did write some for the site.  It wasn’t long after that when I wanted to scratch my own itch and had my own blog.  Which ended up turning towards theubergeeks.net, and now I have cdevroe.com.

I think having your own Web site is a valuable thing, especially for those of us that work on the Web.  It helps you stay in touch with what people are going through when they want to publish content online, edit some code, or even customize an open source project.  There are countless lessons to be learned by having your own site to fiddle with.

Great work Kyle. I’ll check in on you and your site(s) in 14 years.

Source: Kyle Slattery.com.

My 404 page consists of a simple message asking you to contact me to let me know that something went wrong.  There are a lot of services that do much more than simply display a typical “Page Not Found” message, and today we’re going to look at Brightkite‘s “smart” “profile not found” pages.

Brightkite knows how their user’s are using the system.  An example of this was brought to my attention by my coworker Kyle Slattery.  He told me about Brightkite’s ability to detect when a user does not exist on Brightkite, but may exist on Twitter.

Brightkite and Twitter share the same prefix for username detection, the @ symbol ((Other services, like Pownce, use the ! exclamation point.)).  Since Brightkite knows that some people use their system as a geo-enabled Twitter client, like I explained the other day, sometimes you’ll find people “talking” to or about people that do not yet have a Brightkite account. Kyle gave me the example of the username @mikemangino.  That username does not exist on Brightkite but it does on Twitter.

Here is what the profile page looks like on Brightkite for this user.

Rather than show their typical 404 error page, Brightkite asks if you are looking for the same username on Twitter, and even gives you the option to invite that person over to Brightkite.  Kyle thought this was “brilliant”, and I do too.  Kyle was wrong about one thing though; Brightkite’s “profile not found” page isn’t as smart as he might have thought.  Here is what Kyle said:

“Brilliant, if you go to a user on BrightKite that exists on Twitter, but not on BK, there’s a link to invite them, not a 404.”

I don’t think Kyle actually meant to say that Brightkite detects the user on Twitter, because they definitely do not.  But I just wanted to be sure it was clearly stated.

Brightkite’s “profile not found” page is smart enough to know that people are probably on that page because they clicked an @username to a Twitter account and not a Brightkite account. And that is indeed brilliant.  It is a great example of how Brightkite is continuously showing themselves to be “in touch” with how people use their system which makes Brightkite a joy to use.

These changes are really, really small.  Unless you come to this site on a daily basis (you do, don’t you?) you may not notice any of them.  A pixel here, a color adjustment there, an array sorting issue here, a speed improvement there. But these changes were mounting up.  Even browsing my site myself, looking for old entries, I became annoyed with some of the existing bugs because I knew I had already fixed them on my local install.

So today, while I’m running out to spend the weekend in The Finger Lakes region of New York for a wine festival, I published these “little things” to the live site.  I wish there was a way I could calculate the changes (perhaps I should be using Subversion or something), but my guess would be somewhere in the hundreds.  I still have some things that I’d love to get around to adjusting, but they’ll have to wait for the next update.

So, if you’re feeling adventurous, go ahead and poke around.

The most notable take-away from this first weekend of my using third-party applications on my iPhone is how very different the applications I’ve downloaded from the store feel from the applications I’ve been using for over a year.  It is something I didn’t think about as I was anticipating the release of this update.  Nearly all of the iPhone applications that are currently available are, in my opinion, beta-level 1.0 applications.  Add to it that they’ve not been built by Apple, and we’re talking about a lot of poorly designed applications.

This isn’t to say that the applications that were release on day-one aren’t valuable, good applications to have, worth the money they’re asking for, or even that they’re bad applications in any sense.  It is just that they don’t feel nearly as refined as the applications that Apple has released themselves.

Some of the most glaring examples of this are Facebook’s application, Connected Flow’s Exposure, and the Mobile AIM (this is an iTunes link) client by AOL.

First, Facebook’s iPhone application, while built natively for the iPhone – is not nearly as refined or aesthetically pleasing as their Web application for the iPhone. Don’t get me wrong, it is a great application, and I think it works well.  But at the moment I prefer their Web app.

Exposure.

Second, Connected Flow’s Exposure application, the one I linked to the other day, is a pretty good way to browse through Flickr.  If I had to guess at the UI of this application prior to launch I would have been dead wrong.  The application feels very much like the Contact app on the iPhone.  Click a menu item, slide to the right, see that information, then slide back.  But, clicking on the photo and clicking on the arrow give you two different information panes.  One is the photo, full-screen, another is the photo’s metadata (ie. number of views, comments, tags, etc.).  I think all of this information should be on the same panel, inline, and the ability to leave a comment on a photo should not be 3 or 4 clicks into the application.  I think this application should look like the iPhone’s built-in photo browser, with added metadata on touch.  But it isn’t.  It went a completely different direction than I would have assumed. It isn’t all bad, Exposure is free!

Mobile AIM

Last, at least in this post, is the Mobile AIM client. This application feels like someone built it that never built for the Macintosh before – but they tried really hard and nearly pulled it off.  Some of the UIs largest faults is that there is no way to sign out from the application unless you go into your iPhone’s settings panel first, there is no way to close an IM “tab” without first clicking edit on the active IMs list and then clicking the minus button, and that Mobile AIM does not use your iPhone’s contacts.  There are many, many things wrong with this application but the fact that it works and you can be on AIM anywhere in the world makes this one a must-have-installed application.

Let me be clear, I’ve chosen these applications not because they are the worst user interfaces, but because they are among some of the better ones.  These are some of the applications that I think are going to dramatically improve over time.  I think most iPhone application UIs will improve overtime, just as some of our favorite applications on the Macintosh have.  I think more applications will be released that are better than these and as they do, everyone will benefit from the competition.

Kudos to all of the developers that locked themselves in their closets and tried their best to provide good, stable applications for the launch of the App Store.  And I’m looking forward to the future versions of your applications.

Now, if I could just find time to go through the hundreds of applications in the App Store.

Kyle Slattery, Viddler’s Lead Social Developer, recently released a nice little PHP-snippet for Facebook application developers:

“While building the Viddler Facebook application, I needed to create a pagination tool that worked just like Facebook’s. After looking at their HTML and their logic of what pages to display, I came up with one, which I’m releasing for anyone to use.”

Simple. Straight forward.

However, since I’ve never mentioned oEmbed here on my site, I wanted to quickly go through how it came to be, how I got involved, what it is, and who is using it so far.

How oEmbed came to be

I wasn’t in the room, so I can’t be sure without asking the four most involved people in the development of the spec, who was the “inventor” of oEmbed.  It was either Cal Henderson, Leah Culver, Mike Malone, or Richard Crowley.  Leah, on her blog, says that they were all at dinner and were discussing this solution.  So we’ll give them all credit.

I got involved, not the with the development of the spec itself, but with implementing it in one of the first providers of the spec, Viddler.  Mike Malone, who is a friend of mine who happened to begin working at Pownce, the first consumer of the spec, told me it’d be a neat idea if I implemented oEmbed early-on for Viddler.  I took one look at the spec and immediately thought it’d be a good idea.

What is oEmbed?

If you are like me, then you think of the World Wide Web as a library of information.  This information has a wide range of media types.  Just like in a library, there are countless numbers of books each having their own pages, photos, words, etc.  However, if I said to you – go pick up John Steinbeck’s The Grapes of Wrath, turn to page 157 (which is the first page of Chapter Eleven) and let me see it – you could do that pretty easily.

Now, think of that page 157 as a URI. You’re probably used to seeing the acronym of URL, which rolls of the tongue much easier, but URI or Uniform Resource Identifier, is a much more proper term.  So it is an unique identifier for a resource.  In the case of The Grapes of Wrath, the resource is just plain old text.  But on the web we have URIs that link us to text as well as photos, audio, and video.

If I were to link you to this URI and you followed it, you would see that its primary purpose is to show you my iPhone macro lens video demonstration.  Viddler is the book, my video is the page, the video itself is the resource.

Get it? Got it? Good.

Now. Lets say that you were a developer and you wanted to allow people to link from your application to a any resource on the Web, and embed that resource into your application directly.  Here is a quick example, which at this time does not yet exist but I think it should. Lets say that you are having an instant message conversation with me and you give me a URI to one of your photos on Flickr.  Wouldn’t it be neat if that photo automatically showed up, as a small thumbnail, within our conversation just because you linked to it?  This is the type of innovation oEmbed allows for.

Who is using it?

It would seem that oEmbed.com’s “Providers” section is being maintained, so that’d be the best resource to see who are the providers of oEmbed so far.  It doesn’t seem like the “Consumers” section of the site is being maintained, as I’m fairly sure more than just Pownce is using this. I think Lijit might be experimenting with it, but it may not have gone live yet.

As of this writing Flickr, Viddler, Qik, Pownce, Hulu, and Revision 3 are providing end-points for this service.  You can navigate to the documentation for each of these service providers by going to oEmbed.com’s Provider section.

Conclusion

I think if you are a potential provider of oEmbed you would do well to add it to your development roadmap to implement it when you can.  If you are developing an application where you think oEmbed would come in handy, and you need any help – don’t hesitate to ask me or any of the people I linked to above.  I just got an email last night letting me know about the tutorial on Webmonkey for oEmbed, so it won’t be long before the press of the existence of oEmbed begins to turn into tutorials for use and then I hope a large number of implementations are announced.  Like the IM one I mentioned above, I think that’d be awesome.

Until next time, I’m going to Pownce some Viddler videos.

But I think it is time to stop complaining and start helping.  How?   What if we created a list of “well built” applications that use the Twitter API?  By that I mean applications, tools, widgets, etc. that do a good job of not pummeling Twitter’s servers with requests.

The A-list of Twitter apps

I’m not foremost expert on scalability – but I know a well-built application from a bad one.  Any application, widget, or tool that does not use even the simplest form of caching, for example, will not make this list.

I will need your help.  So please comment below with any applications or tools I have not yet linked to, I’ll vet them a little, and add them to the list if it makes the cut.  If you are a developer – please include what you do to help Twitter with your link.

• MW Latest Tweet - by Eric Meyer – A WordPress plugin that shows your latest Twitter status anywhere on your WordPress-powered site.  In order to make sure that I am also helping Twitter, I’ve installed this here on my site.  You can see it on the sidebar of my front page.
• Twitterrific – by The IconFactory – A Mac OS X application that allows you to view your friends timeline and post to Twitter.  Twitterric only requests the Twitter API on a set interval (customizable, and I have mine set to every 15 minutes now).
• Twhirl – by Marco Kaiser and now owned by Seesmic – An Adobe AIR application, which means it runs on both Macintosh and Windows platforms, that lets you follow Twitter, FriendFeed, Pownce, and others.  The highlight of how this application helps Twitter is that it has a requests-per-hour-slider.  I’ve got mine set to 10 (but I only have it check for new statuses every 15 minutes).

Do you have any applications you think should be added to this list?  Why?  Leave them in the comments.  As I update this, I’ll notify people through Twitter, FriendFeed, and Pownce.  ”Follow” me if you dare.

Miscellaneous tips

A few tips and tricks to helping Twitter out, regardless of the tools you choose to use.

 

• Decrease number of requests.  No matter what applications you use, increase the interval (or decrease the number of requests per hour) between requests to Twitter for updates.  The common “side effect” of doing this is actually being more productive.  Give it a try!
• Don’t manually refresh after update. I’ve noticed myself doing this too.  When you send in a new status, don’t manually update.  Chances are it will take a few moments for your latest status to appear in whatever application you are using.  Send in the new status, if there isn’t an error, wait for the next scheduled request. I can’t imagine how many requests this could potential get rid of.

 

I’m not sure how long I’ll keep this set, but I do have some goals in mind with the random header images.  Eventually I want at least one for each of my interests: basketball, wine, food, family, technology, star wars?, and anything else I’m interested in at the time.  I also have a few favorites from my photo collection, which will also find their way into the rotation.

Refresh a few times and let me know which one is your favorite, I hope you like them.

Timeframe demo

The demonstration (pictured) is by far the best calendar “widget” I’ve seen in a browser.  One of my favorite things is the date range tools which is where Timeframe strived to excel and succeeded.  Not only can you enter in a date range by typing it in, which will then result in the same range being selected in the calendar view above, but you can also click, drag, and select the range within the calendar view itself.

There are some desktop application calendars that pale in comparison to Timeframe.  iPhoto is the first example that comes to my mind – you can’t even select a date range in iPhoto!  Anyways.  Give Timeframe a spin and if you’re a developer, start putting this into your applications pronto.

Source: Timeframe.
Via: John Gruber’s linked list. 

“Google App Engine enables developers to build web applications on the same scalable systems that power our own applications.”

Interesting tidbits upon first glance:

• Uses the Python programming language.
• 500Mb and ~5,000,000 for free!
• Sandbox: In other words, if someone’s applications crashes, yours doesn’t.
• Can use Google Apps for user signup.
• The SDK includes an App Engine emulator.

Looks like interesting things, like massively popular Web applications that should scale perfectly and inexpensively, are coming soon.

Source: Google Application Engine.

“Though CakePHP is lacking in a many areas where Rails really excels, I think it definitely has its place in the world of web frameworks.”

Source: Kyle Slattery » Blog Archive » A Review of CakePHP

(Source: “C4[1] Sasser: Coda Confidential”)