About Archive Tags RSS Feed

 

Entries tagged picshare

Everybody loves me, and I intend to keep it that way.

3 June 2010 21:50

Would it be wrong to make a new blog entry just to test the blogging platform? If so I'm wrong.

To pretend that isn't the case I'll briefly document some recent events:

Coding

I've been making changes to the blogging software, chronicle, to support RSS feeds on comments, and to allow outgoing Pings on new entries.

I've also been flirting with an OpenID-backed image upload and sharing site, provisionally named picshare. Why? Partly for fun, partly because I like comments, and partly to flirt with RESTful design and API construction.

Photography

I've provisionally agreed to be the photographer for a special event at a local hair-dressers. This will either be fun, or all end badly.

No money, but free food and the chance to experiment more. So all good.

There. Almost like a real entry, right?

ObSubject: Cruel Intentions

| No comments

 

So I put together another picture sharing site

10 May 2011 21:50

Almost a year ago I put together a simple picture sharing site, which was designed to accept uploaded images via OpenID logins and then share them. It was created because none of the existing image sharing sites allowed OpenID logins - and because frankly I rarely trust sites I don't control. (Especially when they're free sites, with no obvious revenue stream. We can reference recent compromises if we wish to be topical, but even without them it is all about trust.)

I opened up the site to allow others to use it, but assumed it would remain Steve-only - After all why would somebody choose to use my site rather than imgur, or similar?

Over the year I've spotted several minor problems with the site. The built-in support for comments was never used, primarily because I didn't have any other users, and some of the tagging aspects were hard to use.

Since I've started using twitter I again found myself wanting a picture-hosting site, one with "short links". I started using twitpic.com, but wasn't happy with it.

So the plan was formed; build another picture sharing site. But this time with short URLS. Sadly my first choice of http://picc.ie was denied to me - I couldn't register it as I don't live in Ireland. But my second choice http://linkti.me was free.

As a challenge to myself this site uses Redis for storing all user-details, all image details, and all session data. It hasn't been difficult to implemenet a multi-user site, with logins, file uploads, and tagging. I guess I cheated as a lot of the code is borrowed from the previous site, but this time it looks prettier and there have been many cleanups due to my previous experience.

This time round I was more focussed upon short links, so each image is allowed an incrementing number, which is then encoded using base 36 math - which is the alphabet you get if you use [0-9A-Z]. I designed three shareable links for each image to keep it simple:

Why "/r" for the thumbnail? Well because it is a random thumbnail. To cope with difference sizes, and allow the recent image display to look regular, I wanted each thumbnail to be 150x150 pixels. My thumbnail generation simply picks a random X,Y co-ordinate from the image and then cuts out a 150x150 square block starting at that offset.

The results of a random segment of an uploaded image are sometimes very cool, altough equally often they are misleading. If I upload naked people there is the possability that we'll just get a nipple or a cock - but I'm actually quite smug about the way it turned out. Simpler to code than to resize, scale, or similar and surprisingly random when you see 9x9 random images (as you do on the front page).

Anyway that's all for now. I was tempted to talk about implementation or migration, but I've written too much for an early morning already. Some other time?

ObQuote: "He's just trying to freak us out. " - 30 Days of Night.

| 4 comments

 

Images transitioned, and mysql solications.

16 May 2011 21:50

Images Moved

So I've retired my old picture hosting sub-domain, and moved all the files which were hosted by the dynamic system into a large web-root.

This means no more uploads are possible, but each link continues to work. For example:

Happily the system generated "random" links, and it was just a matter of moving each uploaded file into that static location, then removing the CGI application.

The code for the new site has now been made public, although I suspect there will need to be some email-pong if anybody wishes to use it. Comments welcome.

MySQL replacements?

Lets pretend I work for a company which has dealings with many MySQL users.

Lets pretend that, even though it is true, such that I don't have to get into specifics.

Let us pretend that we have many many hundreds of users who are very happy with MySQL, but that we have a few users who have "issues". That might be:

  • mysqld segfaulting every few months, with no real idea why.
    • Transactions are involved. So are stored proceedures.
    • MySQL paid support might have been perfect, or it might have lead to "yup, its a bug. good luck rebuilding with this patch. let us know how it turns out kthxbai."
    • Alternatively it might not have been re-producable.
  • Master-Master and Master-Slave setups being "unreliable" such that data inconsistencies arise despite MySQL regarding them as being in sync.
    • Good luck resolving that when you have two almost-identical "mysqldump" outputs which are 6Gb each and which cause "diff" to exit with "out of memory" even on a 64Gb host.
    • Is it possible to view differences in table-data, via the binary records? That'd be a fun project .. for a masochist.
  • Poor usage of resources.
  • Heavy concurrancy caused by poorly developed applications in a load-balanced environment, leading to stalling queries. (Wordpress + Poor wordpress plugins I'm looking at you; you're next on my killfile).

To compound this problem some of these installations may or may not be running Etch. let us pretend they are not, just to simplify things. (They mostly arent' these days, but I'm sure I could think of one or two if I tried)

So, in this hypothetical situation what would you recommend?

I know there are new forks aplenty of MySQL. Drizzle et al. I suspect most of the forks will be short-lived - lots of this stuff is hard and non-sexy. I suspect the long-lived forks are probably concentrating on edge-cases we've not hit (yet), or on sexy exciting things like new storage engines and going nosql like all the cool kids.

Realistically going down the postgresql road is liable to lead to wholly different sets of problems, and a significant re-engineering of several sites, applications and tools with no proof of stability.

Without wanting to jump ship entirely, what, if any, are our options?

PS. MySQL I still mostly love you, but my two most recent applications were written to use redis instead. Just a coincidence... I swear. No, put down that axe. Please can't we just talk about it?/p>

ObQoote: "I've calculated your chance of survival, but I don't think you'll like it. " - Hitchhikers Film.

| 2 comments