Disqus - Latest Comments for mevans

Re: Defile: Fixing Ruby File Uploads

mevans — Wed, 25 Feb 2015 17:23:57 -0000

Hi - this looks like a cool gem - nice one! I'm glad you've found dragonfly useful in creating it. For your info dragonfly does support form redisplays - http://markevans.github.io/... and direct uploads are quite easy as you use some js library to upload, then just set the model uid attribute with the s3 path, but I see with refile these things are more central/straightforward
Really nice idea including the Javascript for s3 upload within the library - looks pretty easy
Mark

Re: Notes from the open source battlefield

mevans — Tue, 07 Jan 2014 10:38:03 -0000

haha you might be right! cheers mate

Re: Snake Game using HTML5 Canvas tag @ Bamboo Blog

mevans — Wed, 02 Mar 2011 07:08:57 -0000

Gordon - as you seem to be so knowledgeable about "good game structure" and javascript, maybe you'd like to spend hours of your time writing a tutorial on something cool and then releasing for the general public for free.

I don't think you're as knowledgeable about "being constructive", however, so maybe you should look at some of the other comments to see how it's done.

Re: On-the-fly image handling with Dragonfly @ Bamboo Blog

mevans — Sat, 07 Aug 2010 08:56:32 -0000

@Millisami - see response on the google group.
I reckon the best way is to use the file data store for test/cucumber environments

Re: On-the-fly image handling with Dragonfly @ Bamboo Blog

mevans — Fri, 16 Apr 2010 06:15:13 -0000

@polarblau - It shouldn't try to create it every time - no. I haven't come across that before. Rather than reply here I've created a new thread in google groups - see here: http://groups.google.com/gr...

Re: On-the-fly image handling with Dragonfly @ Bamboo Blog

mevans — Mon, 12 Apr 2010 05:55:05 -0000

@pke - yes absolutely - it's built for any content type, not just images. Obviously you'd have to implement your own processor (or by the sounds of it, just your own encoder), as there are no audio ones bundled with Dragonfly.

The only thing is I'd imagine the processing/encoding may take a while, so I don't know how well suited it would be to doing it on-the-fly. It would be cached after the first hit though

Re: On-the-fly image handling with Dragonfly @ Bamboo Blog

mevans — Mon, 29 Mar 2010 05:27:12 -0000

No they can't have the same name. If you want to use the same accessor, then configure the Dragonfly app for images, but also register the 'TransparentEncoder', so that non-image types have an encoder to handle them (which actually does nothing)

Re: On-the-fly image handling with Dragonfly @ Bamboo Blog

mevans — Sat, 27 Mar 2010 21:12:49 -0000

@ncri - first point is a little tricky at the moment as it's not really meant for setting the uid directly. However I'll make some changes for allow for this in due course.
In the meantime it can work by not using the model attribute as an 'image accessor', but instead getting the image urls from the Dragonfly App directly, e.g.
Dragonfly::App[:images].url_for('your_s3_id', '300x200#', :png), etc.

as for your second point, yes, you can have as many accessors as you like and they can be linked to different Dragonfly apps. So you could configure one app for images (e.g. Dragonfly::App[:images]) , as above (or using an 'image_accessor' if you don't want to use that approach - see docs for using with AR), and another for general attachments (e.g. Dragonfly::App[:attachments]), using 'attachment_accessor' attributes ( see http://markevans.github.com... for more info)

I don't quite understand what you said about your controller actions needing a sha! Yes, only image urls should need it. The only possible cause of this i can think of is that you don't have a 'path_prefix' set for your app. You need one to use in rails so that only urls under this prefix are handled by Dragonfly. See the docs for more details.
Hope that helps

Re: On-the-fly image handling with Dragonfly @ Bamboo Blog

mevans — Tue, 16 Mar 2010 08:19:32 -0000

If the initial build time is something you really wanted to avoid, then you could pre-cache the page at some point, e.g. when the image is changed, etc.

I guess there's no substitute for just trying out different things to suit your site's needs.

Re: On-the-fly image handling with Dragonfly @ Bamboo Blog

mevans — Mon, 15 Mar 2010 05:43:42 -0000

@Quentin - exactly - the point is to use a caching proxy like varnish in front of it on a big site.
Currently the header sent out is Cache-Control with a configurable age (defaults to 1 year). Which means that after the first time, the app isn't hit at all and images are served straight from Varnish.

Re: On-the-fly image handling with Dragonfly @ Bamboo Blog

mevans — Fri, 12 Mar 2010 20:21:01 -0000

@Millisami - no. You can create a custom processor to do it yourself though.
(see http://markevans.github.com... )

If it's commonly needed then I may add one - feel free to fork the repository if you want one included.

Re: On-the-fly image handling with Dragonfly @ Bamboo Blog

mevans — Fri, 12 Mar 2010 05:17:46 -0000

@zhenning - good question!
Actually there's built-in Denial-Of-Service protection for this very case.
Have a look at the bottom of http://markevans.github.com... - it adds an extra 'sha' parameter which uses a secret you can specify.

Which means that when it's turned on, if someone's tampered with the url then they'll get a 400 ("bad parameters") response.

Re: On-the-fly image handling with Dragonfly @ Bamboo Blog

mevans — Mon, 01 Mar 2010 07:09:44 -0000

@needto - funnily enough someone else asked that - seems like a common use case - maybe it'll be worth me adding something to easily plug in to apps using Paperclip.

Anyway I think the best way is to create a custom datastore (should be fairly straightforward - see http://markevans.github.com... ).

This datastore should map between 'uids' created by Paperclip (maybe the paperclip attachment.url ?) and the stored data.

Re: On-the-fly image handling with Dragonfly @ Bamboo Blog

mevans — Sat, 20 Feb 2010 11:55:10 -0000

Update - I've just released version 0.5 which is Rails 3 compatible.

Re: On-the-fly image handling with Dragonfly @ Bamboo Blog

mevans — Mon, 15 Feb 2010 05:45:14 -0000

@Alex - thanks for the tip. Out of interest do you know what the errors were related to?

Re: On-the-fly image handling with Dragonfly @ Bamboo Blog

mevans — Thu, 14 Jan 2010 14:31:36 -0000

@justinwr - point us to the code if you can find it - good to get any ideas

@Peter - theoretically yes (fingers crossed!!), although I must admit I haven't actually tried it with edge rails. I'm pretty sure that the only thing that would change is using gem bundler instead of 'config.gem' (and then :lib => 'dragonfly/rails/images' would change to :require_as => 'dragonfly/rails/images' if you use it).

But I'll certainly check to make sure it works with Rails 3.

Re: On-the-fly image handling with Dragonfly @ Bamboo Blog

mevans — Thu, 14 Jan 2010 10:13:21 -0000

Hi grimen - no it's definitely not dependent on RMagick.

I specifically designed it so that people who wanted to use ImageScience / Minimagick / etc. could do.

Which is why you need to do "config.gem 'rmagick', :lib => 'RMagick'" yourself, **IF** you want to use the supplied 'dragonfly/rails/images' file, which configures it with RMagick.

But if you want to use something else you can register your own custom analyser/processor/encoder in whatever library you want (see the docs at http://markevans.github.com... and look at analysis/processing/encoding)

By the way, what's wrong with RMagick? I think it's fantastic! I've heard people talking about memory leaks but never had problems myself.

Re: On-the-fly image handling with Dragonfly @ Bamboo Blog

mevans — Wed, 13 Jan 2010 18:17:58 -0000

@cracell - shame you couldn't use it earlier - hopefully it'll help next time!

Re: On-the-fly image handling with Dragonfly @ Bamboo Blog

mevans — Wed, 13 Jan 2010 18:15:44 -0000

@Matti - thanks for comment - will check out that link - could be useful to get some ideas!

@Paul - if you look at http://markevans.github.com..., you can see some of the stuff you can do with the accessors, and there are a number of ways you could do this kind of thing. You could for example use 'magic attributes' to save the original width and height, so you have the aspect ratio of the original file, then you can work it out for the thumbnail.
Or you could save, for example, the result of
album.cover_image.transform('200x100').width
before saving, but this is expensive.
Personally I don't bother using width and height attributes on image tags because I think they never really add much.

@Jason - there's already an S3 storage implementation - see http://markevans.github.com... and http://markevans.github.com....
As for MongoMapper, I've never used it personally but it's really easy to implement a custom datastore (just three methods) - see http://markevans.github.com.... Feel free to create one and send a pull request on github if you want it included.

Re: Bamboo Blog - Easy template navigation with partial identifier

mevans — Sun, 23 Aug 2009 16:13:32 -0000

Hi Ivar - I just had a quick try with Haml and it almost works as is (but not quite!).
Yes I intend to support it when I get the chance - shouldn't be too much work.
Hopefully over the next couple of weeks - also feel free to fork it on github if you fancy giving it a go.

Re: Bamboo Blog - Block Helpers in Rails Views

mevans — Sun, 16 Aug 2009 17:30:43 -0000

Hello mate! Yeh I only recently put the gem up on github.
Well I must admit I'm the only one round here not using twitter!
I'll probably join the 21st century one day

Re: Bamboo Blog - Block Helpers in Rails Views

mevans — Fri, 14 Aug 2009 20:02:36 -0000

Thanks for comments guys - yes peterlih I agree - working with helpers like this means the views are more meaningful - it's not just about being 'clean', it's also that things are in the right place (and in terms of the DRY principle, things which shouldn't be repeated aren't, and things that should be are).