[Dancer-users] Writing tests for Dancer::Plugins

[sawyer x]

On Sun, Aug 7, 2011 at 6:43 AM, Colin Keith <colinmkeith at gmail.com> wrote:

>
> Thanks for the welcome and the information. Sorry for the delayed
> response. I'm trying to get a project pushed out at work. Also sorry
> if this reply is out of context, I was subscribed to the list digest
> when I first posted.
>

Your delayed response? Check out my delayed response! :)


>
> I was also wondering if there is a list of any Dancer apps floating
> around. I saw the links on  perldancer.org, but from looking through
> them it seems that Dancer is being used just for parsing the URLs.
>

Since Dancer is a thin layer for routes, it's best used for parsing the URLs
for you. A lot of modern applications are centered around Javascript and
thus use little code on the backend. While I personally put a lot of logic
into the backend, a lot of other applications won't. They won't necessarily
feature all their code if it contains a lot of company logics.

Also, and this is awesome: Dancer makes you feel more comfortable with
short, succinct and subtle code rather than large blobs of it. I've noticed
huge applications reduced to clean beautiful (and readable) short code with
Dancer. Quite the accomplishment.

That isn't a criticism of course, I'm just super curious and I would
> like to find some examples of applications built around Dancer so that
> I can try and learn the style that is used. For example what is the
> most common method for session storage, data storage, etc. Obviously
> I'm reading the documentation, but I would love to look through some
> real-life code too.
>

Hard to answer this. Different people really do have different needs. You
can ask people what they use and get a clearer image, but it's hard for us
to point at just one option and say "that's the one". At least when it comes
to storage.

I personally use encrypted cookies for session information at the moment.


> We currently produce Apache/CGI applications so I think Dancer would
> be a huge difference since it would likely let us run things much
> faster and we would be able to slot in new actions so much more easily
> to make development easier. Of course there's still the convincing the
> boss part of it that needs to be done :-) but that might be easier
> with some smaller projects in Dancer.
>

CGI is problematic because:
- the code is bigger
- it's more complicated
- you have to add a lot of stupid logics just for routing users to your real
application logic
- it's bloated, takes more memory
- it's slower
- it's harder to add features
- it's harder to fix/maintain the current features
- it's harder to find people who will work on it
- it's harder to find people who will sustain their position for long with
it, because working with CGI makes you feel sad

By moving to Dancer (or other frameworks) you gain:
- shorter code == less to maintain!
- less duplication of logic (such as hooks, routes, etc.)
- readable code
- easy to develop and add features
- easy to fix and maintain
- faster performance
- smaller footprint (more features, less server costs, more users, whatever
equation you wanna add here)
- easier to find people who will work on it
- employees will be happier and keep their job for much longer

Once I explained this to my boss, there was no further discussion really.
"I'm cutting maintenance headaches and costs, how's that?" -- pretty simple.

I hope it works well for you too. :)

It's generally a good idea to start with small stuff, seeing them work and
then doing bigger stuff. We've currently started writing two small
interfaces with Dancer. If they succeed (and why wouldn't they, really?)
we'll add a few more.

All the best!
Sawyer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.backup-manager.org/pipermail/dancer-users/attachments/20110811/54fed841/attachment.htm>