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.

/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.

In the May issue of Hacker Monthly my piece Why you should never ask permission to clean up code (which has received over a quarter-of-a-million views to-date) was published and I’m extremely grateful to the Hacker Monthly team for their consideration.

I highly recommend picking up a subscription to Hacker Monthly (if you don’t already have one shame on you).

This is especially true with writing software but lets think about an everyday task, shall we? What about washing the dishes? How long is it going to take you to wash the dishes the next time you decide to do that oft procrastinated task? Five minutes? Ten? Two hours? The truth is, you don’t know. You might count the number dishes, say 10 dishes, and think it will take you about 5 minutes (or 30 seconds per dish) to wash, dry, and put them all away. But, how dirty are these dishes? Is one a burnt pan? Do you have the right soap or tool to do the job? What if you find that, while you’re washing a pot, that the pot’s handle is loose? Do you fix it right then or wait till next time? If you fix it right then how long will that take?

You see where I’m going? Estimating the amount of time it will take to complete a task is – well, I’ll just say it – impossible. But we try. We try to calculate all of the possibilities, rule in error, and even give ourselves some padding in the estimate to lower expectations and over deliver. But we almost always fail. Sometimes miserably. The difficult part is coming to grips with that and embracing it.

In my entire life I’ve never been 100% accurate on estimating time. I’m forever an optimist and because of that I’m almost always late at getting something done because I always think it will take less time to finish something than it really will. I think in rose pedals and rainbows.

One quick example to beat this horse until bloody. Recently I was playing around with a pet project of mine and I wanted to add Twitter’s authentication tools to it. In short, this allows people to use their Twitter credentials to log into my application. Should be relatively straight forward, right? Well, ever the optimist and being smart and efficient I grabbed an open source library that claimed to do exactly what I needed. I thought, foolishly, that I’d simply plug the library into my application, follow the setup instructions and I’d move on in less than 30 minutes. It works this way sometimes but not very often. Suffice to say it didn’t work like this for me. In fact, I still haven’t finished hours later. Hours. Something I thought would take me less than 20 minutes and I have now spent hours trying to get it to work properly. And guess what? I’ve decided to scrap it. Hours and hours wasted only to figure out that I’d have been better off building this myself. And now it will take me a few hours to do just that (or much longer).

I’ll never learn. I’m freely admitting that right now. I’d rather be an optimist than be the person that thinks that everything they ever want to do will take too long, be too hard, and will ultimately not be possible to achieve and thus; never try. I’m going to continue to try and continue to fail but – every once and while – I’ll succeed (although later than I would have thought) and be happy.

“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?

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.

/via Simon Willison.

After searching on GitHub for scripts that did the same thing I didn’t come up with much. Hopefully this both fills that void and gets better because it is now out in the open.

I love that they came right out and said that they were inspired by WordPress’ move.

Hopefully this feature will be available via a plugin sometime in the near future?

/via Tony Schneider.

Update January 19, 2010: This script is now available on GitHub. Go forth and fork.

Today I noticed that my now ancient PHP script to update Twitter automatically using PHP/cron needed to be updated. It turns out that Twitter stopped recognizing URLs with ? in them as clickable links. Here is an example tweet where you’ll notice this happening.

I could have told Twitter and asked that they update the way they handle URLs but in reality my script was old, slow, too long, and shouldn’t include ? anyway so I figured I’d write a new one from scratch that included my short URL scheme.

So, here is the PHP script to parse an RSS feed and send the posts to Twitter. It includes a caching mechanism so that you won’t have duplicate URLs posted to Twitter. If you want it, take it. However, if you are better than I am at PHP (most 6yr. olds are better than I am at programming) then I ask that you fork the script on Gist and try to improve it.

Update Dec. 6 @ 5:34p: Kyle Slattery, follow Viddler team member, loves him some Ruby on Rails. As such he’s offered up this version of the script rewritten in Ruby.

Next up we have Anthony Sterling, self-proclaimed “PHP addict”, who has rewritten the script to make the configuration a bit easier. He also changed the way the cache is saved. He’s using a hashed version of the title for each post as his key. I do not believe this to be the best way to go, since post titles can easily change after publishing – but I do like that the script is about 20 lines shorter and the code is arguably cleaner.

Thanks to both Kyle and Anthony for their versions. Lets keep this going and see if we can get this script much more succinct, stable, faster, and usable by others?

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.

Even though he’s publishing all of these “drafts” on the site for free, I will be getting the paper version when it is published.

Via John Gruber.

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

Fellow Viddler and friend Kyle Slattery is reworking his tag search pages. He’s created a really nice way to filter through the various types of content on his site based on tag search results. For instance, going to a tag search for my name will result in a few photos and a few links that he tagged with my name. You can then filter those results to only show you the photos or only the links.

But what if you hack the URL and search for a tag that shows no results? At current Kyle shows an error page. However, there was no error. His Web site should never link you to a page that doesn’t return any results (though it does right now). So how did the person end up here? They may have done a search, they may have hacked the URL, or someone else linked them to this page. Which ever way they ended up on that URL – there is still no reason to show an error.

This brings me to why I call these types of URLs “These aren’t the droids you’re looking for URLs”. These are URLs where you know what the person is looking for (droids) you just don’t have any. In the example URL I use above, a tag search for my name filtered by entries, Kyle does a good job of stating that there are no entries tagged with my name. This is much better than showing an error. In the other example, of a tag search that ultimately returns no results, he should do something very similar. This isn’t an error. There is just no content on his site that is tagged with ‘asdf’.

One of the suggestions I gave to him was to do a search through his own tags and try to see if, perhaps, they’ve mistyped the tag. I’m not sure what ‘asdf’ could have been, maybe sad? Or, what if someone spells my name with two Ls? This isn’t easy to program against – but there is an easier option that he could set up. Offer a search box with the tag that they entered already filled in and show a message of “Sorry, but I have nothing tagged with ‘asdf’. Maybe you misspelled what you’re looking for?”

My site isn’t a good example of best practices here. It used to be. But I had to hack WordPress to bits to get it to work last time and I’ve since upgraded WordPress too many times for those old hacks to work. However, if you’re looking for good examples – I’m sure Kyle’s site will end up being a pretty good example soon enough.

Have you seen any really good examples of this?

“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.)

Viddler’s current lack of any way to record video on a mobile phone, for instance. More specifically the iPhone. I take a lot of mobile photos (more here) on my iPhone. I’ve wanted to shoot videos on my iPhone too. Now I can.

The first step I had to take was to jailbreak my iPhone. Qik’s iPhone application, while not perfect, allows me to shoot video on my iPhone and have it be recorded, live, on Qik’s servers. In fact, if the connection is good enough you can watch me recording the video only a few seconds delayed.

But I wanted my video on Viddler. It is my player of choice. Qik’s player is great, especially since it allows you to watch the video as it is being recorded. It also has some interesting interactive features like chat. But, like MTV – I want my Viddler.

So my second step was to build a bridge from Qik to the Viddler. Once the live session has been saved as an FLV Qik creates an RSS feed with a link to the video file. I’ve built a dead simple PHP script that reads that RSS feed, downloads the FLVs, and then transfers them to Viddler. I then took the liberty of creating a quick bit of code that then Twitters the link to the video on Viddler. I do this for my mobile photos posted to Flickr so I thought why not do that for mobile videos as well.

After talking with Qik about this bridge we’ve both decided to do something a little bit better than what I have hacked together using nothing more than what I had access to. So stay tuned.  Until then, you may have my script that I wrote in an hour to play with.

When I switched to this theme in April of this year I had created two header images that would display at random on each page refresh. I had aspirations “to some day find the time to have as many as ten random header images”. Later that month I had 10 total header images. As of today I have created about 40 header images for this site, 24 of which are active.

In August of this year, after visiting a Peter Lik gallery in Las Vegas, I had decided to spruce up the random header images on this site by also changing the color of the background, or frame, of the site based on the image being displayed. This added a lot of fun to creating the images for me and I hope that as people found this site they too enjoyed the display of them.

As of today, however, we’re kicking it up a notch.

The first update that I made is that now the link color also changes when the header image and background color do. This small adjustment makes it feel just a little bit more refined then just changing the background color. Some of the background colors I had originally chosen were a little too light to read on white. So I had to make a few small adjustments to the color choices I made. This has two interesting side effects the first being that I now have 4 or 5 brand new “looks” for this site. Just by making a new color choice for each. The other side effect is that I now have to choose colors that are readable on white. For better or worse, I’m not sure yet.

The second update is one I’m really excited to talk about because I have yet to see how it will effect the site overall. The headers are no longer totally random. The way it worked prior to today was that when the page loaded I allowed PHP ((The programming language this site is written in.)) to choose a random number between 1 and 24 – and I’d use that number to determine the header image to show. It was incredibly simple, worked well, and made for each refresh to be a surprise!

In an effort to make the selection of which header image to show a smarter process I’ve added two layers of complexity to how a header image is chosen in addition to the random selection. This might get confusing, if it does, sorry.

If you visit the home page of the site, or any sub-page like the about page, it will figure out what time of day it is ((Here in the eastern United States.)) and display one of many images I’ve designated for that time of day. I have images categorized as morning, day, evening, and night. I’ve split up the hours using the 24-hour clock this way; 6am-12pm = morning, 12pm-5pm = day, 5pm-9pm = evening, 9pm-6am = night.  I may adjust those time slots but that is where they are now. I have several images for each time of day. So on these pages you will still be getting a randomly selected header, but it will be randomly selected based on the current time of day, rather than from the entire pool.

If you visit a note, photo, mobile photo, etc. on this site you will be shown an image contextually. What I mean is that for each header image I have associated a tag to it. The tag may describe what is in the image, where the image was taken, or something the image has to do with. I then compare the tags that are associated to the post you’re currently reading and create a list of matching headers.  If there are one or more matches the site randomly displays one of those matches.  If there are no matches the site reverts to the time of day method.

So what does this all mean? Well, I’m not sure yet as the system still has some randomness to it. But generally speaking, if you are reading a post about my trip to Hawai’i, like this one, or this one, you should see a header related to Hawai’i. If you are reading a post about animals, you’ll see a header that probably has animals in it. If you are watching a video about food, then a header relating to food will most likely be displayed. And, again, if you are reading about New York City or Philadelphia - those headers will show up.

I’m still fine tuning the way that the site decides which header best fits the current post being shown but so far in my testing it has done a pretty good job.

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!

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.

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.