A little recap:
Here I stated a problem about phantom 404 and a (wrong) solution to it.
Here I confessed I was working on the issue.
Here It's the work I'm doing with a long and boring description of the problem that I'll not repeat in this blog.
...but probably you don't want to wait until the problem is really closed because you have (as me) a package that you want on CPAN to share it with the world.
Oh yes, the problem! Let me say it with few words:
You have a plugin that modify the request path in a before hook. You want that, when the user write (for example) /prefix/good/path, your plugin change it to /good/path. Obviously the code that will answer to this will be:
get '/good/path' => sub {...}
You don't define anything about /prefix/good/path because the plugin will always change it, so you'll never need to answer with it.
This works! I can swear it calling Wotan on my side. But when you try to test it with dzil test the test you wrote fails.
Long explanation for why this happen, as I said, is here. Little workaround you can use to stop this happening is adding a public directory under the t with just a dummy file. This way fix the problem and make you test suit running flawless!
Sunday, 29 September 2013
Monday, 9 September 2013
In the previous episodes of Battlestar Galactica...
I didn't write anything for a lot of time because I was on holiday and (more important) a lot of things happened in the Dancer2 World and I was a bit confused about some of them.
First important news, for me, is that use Dancer2 :sytanx is no more from 0.07. I was a little puzzled about it because, as I wrote here the pure use Dancer2 is a powerful spell that do many things and sometimes it could be more than what you want.
I asked for enlightement (i'm still a barbarian, you know) and Sawyer X himself gave me this answer about it.
So, using use Dancer2 also when you're not creating an app is good.
All I said about apps and scope is still valid, so we can say farewell to use Dancer2 :syntax (a legacy of Dancer) with no regret.
Second question I'm working about is nasty like a leprechaun with no sense of humor that hate Harry Potter. In this article I talked about phantom 404 that raise instead of the right answer while testing. I thought this issue was solved using TCP::Test. This is not true, there is still a lot of work to do about this fascinating enigma and it's exactly what I'm doing right now. It's an indispensable step to release my Dancer2 plugin (Dancer2::Plugin::Multilang) on CPAN so I'm working hard about it!
Stay tuned!
First important news, for me, is that use Dancer2 :sytanx is no more from 0.07. I was a little puzzled about it because, as I wrote here the pure use Dancer2 is a powerful spell that do many things and sometimes it could be more than what you want.
I asked for enlightement (i'm still a barbarian, you know) and Sawyer X himself gave me this answer about it.
So, using use Dancer2 also when you're not creating an app is good.
All I said about apps and scope is still valid, so we can say farewell to use Dancer2 :syntax (a legacy of Dancer) with no regret.
Second question I'm working about is nasty like a leprechaun with no sense of humor that hate Harry Potter. In this article I talked about phantom 404 that raise instead of the right answer while testing. I thought this issue was solved using TCP::Test. This is not true, there is still a lot of work to do about this fascinating enigma and it's exactly what I'm doing right now. It's an indispensable step to release my Dancer2 plugin (Dancer2::Plugin::Multilang) on CPAN so I'm working hard about it!
Stay tuned!
Saturday, 10 August 2013
The accent
My name is Simone Faré and I'm italian. I think you can understand how important is for me UTF-8 and character set management.
Using a framework should allow you to avoid all the boring parts of stuff and UTF8 in Dancer2 is actually like that, but you need to remember the three points where the magic spell lies and ensure to activate all of them.
The first point is the easiest, the most powerful and it comes for free.
It's just the charset: "UTF-8" configuration key in the config.yml. Spend a moment reading the documentation page about it and you'll find how many things this little word do. You could try it also with girls in pubs, probably It will do something good also with it as well.
The second point is about your template engine, if you're using template toolkit add:
template: "template_toolkit"
engines:
template_toolkit:
ENCODING: utf8
This is a useful configuration, but not as powerful as the other one. If you're in an environement where all the charset are managed for good your template engine and the browser will not need to do lucky (wrong) guess about encoding. I think that this configuration can help just when guessing is needed.
Obviously the third point is very important, very insidious and very well hidden in the documentation, because there's no gain without pain.
The first configuration is about the framework, its internal logic, the second is about HTML and templating, so who are we forgetting? Never heard of something named MySQL?
DBA are strange people, very different from developers. A database has encodings, collations, things about tables, magic and curses everywhere. What I know is that if you don't nail down your DB connection to what you want you will never save good data in it. How to do this?
In the database configuration:
options:
RaiseError: 1
PrintError: 1
mysql_enable_utf8: 1
Just that. But remember it or you'll suffer. Suffering is good, but suffering forever is unfair.
Using a framework should allow you to avoid all the boring parts of stuff and UTF8 in Dancer2 is actually like that, but you need to remember the three points where the magic spell lies and ensure to activate all of them.
The first point is the easiest, the most powerful and it comes for free.
It's just the charset: "UTF-8" configuration key in the config.yml. Spend a moment reading the documentation page about it and you'll find how many things this little word do. You could try it also with girls in pubs, probably It will do something good also with it as well.
The second point is about your template engine, if you're using template toolkit add:
template: "template_toolkit"
engines:
template_toolkit:
ENCODING: utf8
This is a useful configuration, but not as powerful as the other one. If you're in an environement where all the charset are managed for good your template engine and the browser will not need to do lucky (wrong) guess about encoding. I think that this configuration can help just when guessing is needed.
Obviously the third point is very important, very insidious and very well hidden in the documentation, because there's no gain without pain.
The first configuration is about the framework, its internal logic, the second is about HTML and templating, so who are we forgetting? Never heard of something named MySQL?
DBA are strange people, very different from developers. A database has encodings, collations, things about tables, magic and curses everywhere. What I know is that if you don't nail down your DB connection to what you want you will never save good data in it. How to do this?
In the database configuration:
options:
RaiseError: 1
PrintError: 1
mysql_enable_utf8: 1
Just that. But remember it or you'll suffer. Suffering is good, but suffering forever is unfair.
Sunday, 4 August 2013
Initiation rite
We're here to celebrate!
If you're a wotan worshipper the initiation rite is a very important part of your life. Usually, this rite is something about killing bears, drinking blood, dancing all night and having sex with virgins.. while they try to kill you with a sacred knife.
If you're a programmer you don't have to do anything of this, but you still need something that demostrate that you've grown up.
For me, it's the pull request Dancer2 team accepted today. It's something about sessions and forward that I found while developing the Dancer2::Plugin::Multilang. It's just a small thing, nothing revolutionary, but seeing it merged in the Big Project gives me a good feeling.
I think that working on a big open source project like Dancer2, also giving little contribute, is good to learn a lot about coding, collaboration and computer science. I think all people should try something like this, just to improve their skills.
Probably I'll talk about this some day, a technicle, boring post about data flows, but that time is not now. Now it's just time to celebrate!
If you're a wotan worshipper the initiation rite is a very important part of your life. Usually, this rite is something about killing bears, drinking blood, dancing all night and having sex with virgins.. while they try to kill you with a sacred knife.
If you're a programmer you don't have to do anything of this, but you still need something that demostrate that you've grown up.
For me, it's the pull request Dancer2 team accepted today. It's something about sessions and forward that I found while developing the Dancer2::Plugin::Multilang. It's just a small thing, nothing revolutionary, but seeing it merged in the Big Project gives me a good feeling.
I think that working on a big open source project like Dancer2, also giving little contribute, is good to learn a lot about coding, collaboration and computer science. I think all people should try something like this, just to improve their skills.
Probably I'll talk about this some day, a technicle, boring post about data flows, but that time is not now. Now it's just time to celebrate!
Sunday, 28 July 2013
The dumb code festival - 4
Authentication and authorization is something every framework must manage. Because they're boring and frameworks exist to manage boring things.
When a user can be considered authenticated? The easiest way to check it it searching is its session for a user key with some interesting value. Is this secure? Enough, because we're talking about server-side session, something a user can't touch, we have to trust it well... until a new security flaw is found in one of the layer of our system.
The "auth" thing is a pattern well known in the web world and you can find many solutions for it, looking for "Dancer::Plugin::Auth" you'll find a lot of stuff. Unfortunately Dancer2 is still a young project so the only tool we have is the Dancer2::Plugin::Auth::Tiny from Golden.
We'll not use it. Ok, the plugin is a very good piece of software but its main purpose is define which routes need login to redirect on login page the not authenticated users. I think that this is made useless by the Dancer2 App scope.
In a situation where routes for logged users and routes for not-logged users are mixed up probably D2::P::A::Tiny is the right solution, but here we have an app where every route needs auth so we'll solve our problem just with a before hook defined in the app itself.
But we have to start from: how to open the doors to a logged user? Login went well, user and password were right, what the server will do? As I said before, it will write in the user session the username.
session 'user' => $the_username;
This is what our hook will check:
Yes, just this. The most common mistake is forgetting that the login route has to skip the check because is the only page allowed for not logged users. In every other case the hook does NOTHING for logged users and redirect to the login page the guests.
I made it more longer than what is needed because I like to talk and write and because sometimes I think that also obvious things need some explanation, somewhere. Conclusion is that using the snippets from the dump code festival you have the start situation for an admin tool you can use for every purpose. Probably, working on it, you'll find a lot o things to improve it or make it smarter. But this is just the first step, the dump step, so it's right as it is.
When a user can be considered authenticated? The easiest way to check it it searching is its session for a user key with some interesting value. Is this secure? Enough, because we're talking about server-side session, something a user can't touch, we have to trust it well... until a new security flaw is found in one of the layer of our system.
The "auth" thing is a pattern well known in the web world and you can find many solutions for it, looking for "Dancer::Plugin::Auth" you'll find a lot of stuff. Unfortunately Dancer2 is still a young project so the only tool we have is the Dancer2::Plugin::Auth::Tiny from Golden.
We'll not use it. Ok, the plugin is a very good piece of software but its main purpose is define which routes need login to redirect on login page the not authenticated users. I think that this is made useless by the Dancer2 App scope.
In a situation where routes for logged users and routes for not-logged users are mixed up probably D2::P::A::Tiny is the right solution, but here we have an app where every route needs auth so we'll solve our problem just with a before hook defined in the app itself.
But we have to start from: how to open the doors to a logged user? Login went well, user and password were right, what the server will do? As I said before, it will write in the user session the username.
session 'user' => $the_username;
This is what our hook will check:
Yes, just this. The most common mistake is forgetting that the login route has to skip the check because is the only page allowed for not logged users. In every other case the hook does NOTHING for logged users and redirect to the login page the guests.
I made it more longer than what is needed because I like to talk and write and because sometimes I think that also obvious things need some explanation, somewhere. Conclusion is that using the snippets from the dump code festival you have the start situation for an admin tool you can use for every purpose. Probably, working on it, you'll find a lot o things to improve it or make it smarter. But this is just the first step, the dump step, so it's right as it is.
Monday, 22 July 2013
The dumb code festival - 3
In the first two chapters of our dump code festival we just did a lot of frontend developement, something completely independent from the framework we are using and with no server-side logic.
Well, today frontend developement is very important and HTML::FormFu is a very complex and obscure thing so I think it's not so bad we spent all this time on it.
You know? I'm trying to make HTML::FormFu "cooperate" with Twitter Bootstrap. Yes, it's possible and easy enough, but you have to do tricks and you'll never have all the freedom you probably want. However, letting twitter bootstrap render the form make it nicer than not doing it, so... give it a try.
But now we have to talk about logic.
Business logic in a login form is triggered just on submit, when data start its voyage to the server and the server is committed to give an answer to the user. It's like going to the oracle. Yes, the oracle with eyes turned up to the sky and funny clothes, not the oracle database server.
Easiest and probably most elegant way to manage a login form is making is action calling again the login page. This is the meaning of the any keyword we used last time to define the route. You arrive on the login route with a GET (obtaining the form), you process the submitted data with a POST on the same route.
The four needed steps are:
Well, today frontend developement is very important and HTML::FormFu is a very complex and obscure thing so I think it's not so bad we spent all this time on it.
You know? I'm trying to make HTML::FormFu "cooperate" with Twitter Bootstrap. Yes, it's possible and easy enough, but you have to do tricks and you'll never have all the freedom you probably want. However, letting twitter bootstrap render the form make it nicer than not doing it, so... give it a try.
But now we have to talk about logic.
Business logic in a login form is triggered just on submit, when data start its voyage to the server and the server is committed to give an answer to the user. It's like going to the oracle. Yes, the oracle with eyes turned up to the sky and funny clothes, not the oracle database server.
Easiest and probably most elegant way to manage a login form is making is action calling again the login page. This is the meaning of the any keyword we used last time to define the route. You arrive on the login route with a GET (obtaining the form), you process the submitted data with a POST on the same route.
The four needed steps are:
- Create the form object
- obtain the DATA inserted from the user
- process the data
- Do something with the data (yes, you can throw it away and laugh, but this way you'll never become a professional programmer)
As you can see the code is very simple and it's just HTML::FormFu syntax mixed up with very few Dancer2 magic.
We saw the first two lines in the last chapter. They, with the last one, make the form appear on the screen. The params keyword retriver all the variables arrived with the request, it's a pointer to an hash that's suitable for the $form->process. Process takes every key in the hash and put it in the field of the form with the same name, triggering contraints, validators, inflators etc. etc. The result of this computation is in the submitted_and_valid variable that can be easly tested to see if the data can be processed.
Staying in the same route makes all the messages easy to manage. The process can find a violeted contraint, for example (as an empty field, as we configured), then it can write the error message directly in the form and the rendering, on the bottom of the route, will make it automatically visible.
In the GET scenario no param is present, process receive an undef and do nothing to change the form. The render will display the form untouched, ready to be used.
What about the login_valid? It's up to you, you have to decide when a user is good and when it's not.
This is a easy and dumb implementation:
We saw the first two lines in the last chapter. They, with the last one, make the form appear on the screen. The params keyword retriver all the variables arrived with the request, it's a pointer to an hash that's suitable for the $form->process. Process takes every key in the hash and put it in the field of the form with the same name, triggering contraints, validators, inflators etc. etc. The result of this computation is in the submitted_and_valid variable that can be easly tested to see if the data can be processed.
Staying in the same route makes all the messages easy to manage. The process can find a violeted contraint, for example (as an empty field, as we configured), then it can write the error message directly in the form and the rendering, on the bottom of the route, will make it automatically visible.
In the GET scenario no param is present, process receive an undef and do nothing to change the form. The render will display the form untouched, ready to be used.
What about the login_valid? It's up to you, you have to decide when a user is good and when it's not.
This is a easy and dumb implementation:
Users and passwords are on a little DB table, accessible using the Dancer2::Plugin::DBIC (as always). Remember: just the MD5 for your password IS NOT a secure way to store it. But, as I said, this is just an example.
Well, there's just one more thing to say, probably the most interesting because it's the one about Dancer2 structure and server-side logic. It's just this: now we have a login page, what we need is that it appears every time someone try to navigate our admin panel. EVERY TIME.
Well, there's just one more thing to say, probably the most interesting because it's the one about Dancer2 structure and server-side logic. It's just this: now we have a login page, what we need is that it appears every time someone try to navigate our admin panel. EVERY TIME.
Tuesday, 16 July 2013
Dancer2::Plugin::Multilang
So, my wonderful Dancer2 plugin to manage multilanguage sites is released on github!
I wrote in this blog something I learned developing it, so I think that this place is the right one to make the announce.
I tryed to design this plugin as "plug-and-play" as possible. With it, you should be able to make your site multilanguage with no other effort then... translate the contents.
Netx step is releasing it on CPAN but I never did something like that so I have to learn how. I hope to learn it well enough to come back and writing about it in my blog, but now I don't have enough time to do it, so this topic has to wait a little.
In the meantime download, try, fork and play with my plugin as long as you want. Feedbacks (yes, bad feedbacks too) are welcome!
I wrote in this blog something I learned developing it, so I think that this place is the right one to make the announce.
I tryed to design this plugin as "plug-and-play" as possible. With it, you should be able to make your site multilanguage with no other effort then... translate the contents.
Netx step is releasing it on CPAN but I never did something like that so I have to learn how. I hope to learn it well enough to come back and writing about it in my blog, but now I don't have enough time to do it, so this topic has to wait a little.
In the meantime download, try, fork and play with my plugin as long as you want. Feedbacks (yes, bad feedbacks too) are welcome!
Subscribe to:
Posts (Atom)