Updates from aidan RSS

  • Subtleties of Facebook Like and the Open Graph

    11:40 pm on November 28, 2010 | 0 Permalink

    Facebook Like is an amazing tool for anyone wanting to promote their work on the internet. It provides a simple way to get your work seen and for it to spread throughout the social network. We think that this method of advertising is rapidly becoming more relevant than the traditional techniques (google advertising and the like).

    When we added the Facebook Like functionality to our sites recently a fair amount of time and consideration was put into the process. It seems like a simple enough thing to do – you just drop some code into your page and voila the little Like button is ready to go. Well, for a host of reasons, it’s not quite as easy as all that.

    You may or may not have heard of the Open Graph. It’s an initiative to give a bit more meaning to the pages out there on the internet. By embedding hidden information into the page you can allow Facebook (or anyone else who reads to tags) to get a better idea of what your page is all about. It’s actually even more than that – it’s essentially a unique home and identity for each one of the images you upload.

    Why is this relevant? We wanted to make sure that your images maintain their identity within the Open Graph as time goes on. When our customers go pro they get a new domain name, and hence a new home for their images. After some experimentation we discovered that Facebook respect canonical urls, so we’ve added those to every page to get around this problem.

    Another issue is to do with the meta data. Our system uses #s in the urls to make the galleries slick and lovely. Unfortunately it means that it’s impossible for us to hide metadata in the page about each image in a way that Facebook can read. To fix this we’ve created new unique pages for each image. Within these pages we can set the metadata that Facebook pulls into the news feeds when people like and share your images. We then use Javascript redirects to jump to the correct album + image. Again, this system ensures that the references to your images and albums are here to stay – changing an album name won’t effect the graph for example.

    We’re still fine tuning things but everything seems to be working pretty well now. Hope you Like it as much as we do…ahem.

    There’s a website for The Open Graph if you’d like to read a bit more about it.

     
  • Outage

    3:48 pm on November 20, 2010 | 1 Permalink

    We had a brief outage today though things are back on track again now. Our main server became inaccessible for reasons I still don’t entirely understand (though am looking into). We’re now running on a new server that should make things run a bit faster in the long run anyway – we had planned on switching to it in the next few weeks but the outage just pushed things a little ahead of schedule!

    We’ll obviously be keeping our eye on the new server to make sure it’s all running smoothly while we continue looking into the issue.

     
  • Huge Images Causing Issues

    9:18 am on July 13, 2010 | 0 Permalink

    As cameras get better and better, the images they create become larger and larger. We’re now at the point when a single snap can take up more than 20mb (in a few years people are going to read that and laugh).

    We’ve noticed in recent days that a few images have become so large that our compression system is struggling to deal with them. This is something we’re working on and hope to have resolved soon. We’ll keep you posted.

     
  • Railo Gotchas - Part III

    3:31 pm on February 27, 2010 | 0 Permalink

    I’ve said it before and I’ll say it again. We love Railo, it’s the very foundation beneath our feet. Though, as we’ve said before, there are some things to watch out for. A known bug that’s come to bite us (just a little) is the whitespace management. When you get Railo to suppress whitespace in the server settings it takes quite an aggressive policy – for example, all additional newlines are removed from the output.
    In normal cases this is ok. Where it falls down is within html <textarea> elements (I can’t think of any other situations where it would be a problem but there may well be a few more). Within textareas you may well want users to be able to enter multiple linebreaks to be converted into <p> tags within the rendered html. Normally the solution would be to wrap textareas in <cfsetting suppresswhitespace=”false”> tags. Unfortunately, due to a (known) bug in Railo once suppresswhitespace is turned on there doesn’t seem to be any way of turning it off.
    When we get enough free time we’ll look into trying to fix the bug in the Railo source. For the moment we’ll have to live with it.

    I’ve said it before and I’ll say it again. We love Railo, it’s the very foundation beneath our feet. Though, as we’ve said before, there are some things to watch out for. A known bug that’s come to bite us (just a little) is the whitespace management. When you get Railo to suppress whitespace in the server settings it takes quite an aggressive policy – for example, all additional newlines are removed from the output.

    In normal cases this is ok. Where it falls down is within html <textarea> elements (I can’t think of any other situations where it would be a problem but there may well be a few more). Within textareas you may well want users to be able to enter multiple linebreaks to be converted into <p> tags within the rendered html. Normally the solution would be to wrap textareas in <cfsetting suppresswhitespace=”false”> tags. Unfortunately, due to a (known) bug in Railo once suppresswhitespace is turned on there doesn’t seem to be any way of turning it off.

    When we get enough free time we’ll look into trying to fix the bug in the Railo source. For the moment we’ll have to live with it.

    D5WGQ8G3FQPY
     
  • Unplanned Outage

    5:20 pm on January 11, 2010 | 1 Permalink

    We are currently experiencing a bit of a blip with our sites. Unfortunately the problem lies with our DNS provider Enom.

    It’s a big deal for the internet – we’re just one of the millions of sites affected by the issue. It’s also a big deal for us, we’ve put a lot of hard work in to make sure our systems are safe and stable. We put a certain amount of trust in our providers and it’s disappointing when they have issues. More disappointing is their response to the issue so far. It’s taken a long time for them to get around to even acknowledging the issue on twitter.

    Anywho, I’m sure they’ll manage to get it sorted out soon. In the meantime we’ll look at what we can do to have a failover in place to deal with this in the future.

    Sorry for the inconvenice. We’ll post back again once things are back to normal.

     
  • Big Albums and The Lazy Loader

    10:43 am on January 7, 2010 | 0 Permalink
    Tags: ,

    When we first built Photoswarm’s photo hosting websites we anticipated that people would generally want to just put a handful of images in each of their albums. We never dreamed that you might like to squeeze hundreds of images into a single album!

    The problem with having so many images in an single album is that it can take a long time to completely load a page. People viewing an album would then experience a delay before they could see the full-size images (at the geek level – there’s only a single thread for loading content). Clearly we needed to do something about this.

    Enter the Photoswarm Lazy Loader. The job of this sweet little addition is to ensure that content that is out of view is only loaded when required. So for example the thumbnails further down an album page will only load as you scroll down that page. In general it should look far enough ahead so that you won’t really see this happening but you should definitely feel the improvement in performance on big albums.

    We’ve also rolled this feature out to admin sections of the photo websites to keep them nice and nippy too.

     
  • What Lurks Beneath?

    3:47 pm on November 19, 2009 | 1 Permalink
    Tags:

    Looking at this blog over the last month you could be forgiven for thinking that there isn’t much going on at Photoswarm Headquarters at the moment. Au contraire! We’ve been so busy that we just haven’t had time to stop to write about it.

    As more and more customers have been using our photo sharing sites it’s become apparent that our existing infrastructure is on the path to reaching capacity. It is by no means at its limits yet but now is the time for future proofing.

    We’re currently moving our photo websites to The Cloud (specifically the Amazon Cloud). The best way to think about is a big shared pool of tens of thousands of computers at our disposal. It gives us unlimited room to expand to meet the growing needs of our customers.

    Unfortunately migration isn’t as easy as just flicking a switch. You have to build, test, migrate, test, rebuild, test some more and repeat until you’re completely satisfied. We’re almost satisfied now (we just have a few more tests to run).

    What does this mean for you? The most apparent initial change will be the performance. Our tests indicate that the existing sites run a magnitude faster than the old ones. Uploads, downloads and everything in between will benefit from the new machines.

    A less visible yet possibly more important change is redundancy. Your data will be safer then ever before with copies of everything replicated the world over. In the case of a serious critical failure (like a fire at our datacenter) we’ll be able to boot up servers in another part of the world to have things up and running again.

    Most importantly, from our point of view, it provides options. Features we’d like to be able to offer, such as full backups of your raw images, are now going to be possible. We’re free from the shackles of a traditional limited infrastructure.

    Yes yes, it’s a very exciting time indeed.

     
  • Uploader Updates

    1:35 pm on October 4, 2009 | 0 Permalink
    Tags: , , , ,

    We’ve made a couple more changes to the upload process to make it even faster and slicker. It’s now also possible to share your albums via facebook, twitter and other social services directly from within the admin section. In fact, we’ve integrated it right into the album upload process to make things as easy for you as possible.

    If you haven’t already grab yourself a free site and try it out yourself.

     
  • iPhone Bugs

    10:15 am on September 21, 2009 | 0 Permalink
    Tags: , , ,

    We’ve been looking into a few iPhone bugs in the gallery this weekend. It seems that due to the iPhone’s unique scrolling and zooming system our gallery calculations (of which there are quite a few) aren’t quite coming up with the right numbers. In fact, this is the first web testing we’ve done on the iPhone and we picked up quite a few things.

    It’s an interesting interface in that there’s not a concept of a mouse pointer anymore, which means that such things as rollovers no longer make sense. As a result our nice album rollover effect no longer works at all. This is a general problem for interface designers. More then ever we need to make sure that buttons look like buttons and not by changing their look on hover. Fortunately users become more and more geek savvy every day.

    A more difficult issue to solve is that fixed positioning doesn’t work as one would expect (hate to say it but it feels a bit IE6). This one surprises me a little bit more. I understand that the scrolling and zooming model is different here – but I’m not sure that Apple’s implementation needs to be. Fixed positioning should put an element relative to the viewport and even though the movement of the viewport is a touch (excuse the pun) different, the viewport itself isn’t. Anywhoo, just need to add it to the ever increasing list of browsers to support I guess. We hope to have some better fixes for these issues out the door soon.

     
  • Adobe CF to Railo : CFExecute

    4:43 pm on September 10, 2009 | 0 Permalink
    Tags: ,

    Just another little snippet on things to watch out for when transitioning from Adobe CF to Railo. As I said last time when we discussed CFQueryParam these articles are not to pitch one engine against the other (Railo would clearly win :) ) more to expose things to look out for….though this one is definitely a minor bug in Railo….

    Now, I haven’t 100% verified that this is still the case, but when I last checked there was a bug in CFExecute whereby any arguments containing spaces will not be treated properly and there doesn’t seem to be any way to escape them. Consider the following:

      <cfset a = ['/this_app/my file.txt'] />
      <cfexecute name="more" arguments="#a#" variable="b" timeout="4" />
      <cfdump var="#b#" /><cfabort />

    It’s important that the second argument be escaped when passed to the system to execute – otherwise it’s going to look for a file called “/this_app/my” instead of “/this_app/my file.txt”.

    Which is the exactly the error you get:

    Error invoking external process – more[/this_app/my: not found

    For us the solution is simply to make sure we never have to deal with arguments with spaces in. Suits us nicely but I’m sure there will be other occasions when it’s not so easily to come up with a solution.

     
c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
esc
cancel