tag:blogger.com,1999:blog-72162846949785133052024-02-19T18:07:31.578+01:00The perlish sonic screwdriverWho looks at a screwdriver and thinks, "Ooh, this could be a little more sonic"?Cymonhttp://www.blogger.com/profile/12929196519388090491noreply@blogger.comBlogger35125tag:blogger.com,1999:blog-7216284694978513305.post-38023779293517121192015-07-04T21:41:00.000+02:002015-07-05T17:34:13.449+02:00How to become a Strehler developerStrehler is a strange package to develope. It's easy to install from repository and use, but while you are just writing it you have to arrange many tricks to be confortable with the work. For example, Strehler needs a Dancer2 site to run, something the respository doesn't contain.<br />
<br />
In this little tutorial I'll try to explain how to setup an environment to become a Strehler developer, because Strehler needs you, as any of the packages published on CPAN. It's a very basic tutorial, useful for beginners too.<br />
<br />
I hope it will help.<br />
<br />
<h2>
</h2>
<h2>
The repository</h2>
<div>
You probably already have a sandbox created in one of the many ways available for perl development. I'm still a fan of the good'ol <a href="http://search.cpan.org/dist/local-lib/">local::lib</a> but it's good to use also, for example, <a href="http://perlbrew.pl/">perlbrew</a>. Your sandbox has to be active during Strehler development and you have to put in it Dancer2</div>
<blockquote class="tr_bq">
<span style="font-family: Courier New, Courier, monospace;">cpanm --notest Dancer2</span></blockquote>
But NOT Strehler. After installing Dancer2 most of the library useful to work with Strehler will be in place, but probably you'll need something more, libraries specific to Strehler work. Just install them in your sandbox the same way using cpanm when running the code point out their absence..<br />
<br />
You'll surely need:<br />
<br />
<ul>
<li><a href="http://search.cpan.org/dist/Dancer2-Plugin-DBIC/">Dancer2::Plugin::DBIC</a></li>
<li><a href="http://search.cpan.org/dist/Dancer2-Plugin-Ajax/">Dancer2::Plugin::Ajax</a></li>
<li><a href="http://search.cpan.org/dist/HTML-FormFu/">HTML::FormFu</a></li>
<li><a href="http://search.cpan.org/dist/Authen-Passphrase/">Authen::Passphrase::BlowfishCrypt</a></li>
<li><a href="http://search.cpan.org/dist/IO-Prompt/">IO::Prompt</a></li>
<li><a href="http://search.cpan.org/dist/DateTime-Format-SQLite/">DateTime::Format::SQLite</a></li>
</ul>
All this packages are in the requirements of Strehler package and would come automatically installing Strehler for CPAN. Installing them manually is the cleanest way to obtain them, but you can try some trick, like installing Strehler and then deleting it from repository, keeping all its dependencies.<br />
<br />
<h2>
</h2>
<h2>
The code</h2>
Just pull down all the source from the git repository in a directory you like<br />
<blockquote class="tr_bq">
<span style="font-family: Courier New, Courier, monospace;">git pull git@github.com:cym0n/strehler.git</span> </blockquote>
Downloading the repository you'll have a directory named <b>$GITURL/src/lib</b> and one named <b>$GITURL/src/script</b>. These two directories will come useful soon.<br />
<br />
<h2>
The environment</h2>
<div>
Now that you have Strehler code it's easy to modify it and manage changes using git. Less obvious how to use this code and see it working. We just need to customize a little the environment. Open a file named <b>strehler-devel </b>and put in it</div>
<blockquote class="tr_bq">
<span style="font-family: Courier New, Courier, monospace;">alias perl="perl -I$GITURL/src/lib"</span></blockquote>
<blockquote class="tr_bq">
<span style="font-family: Courier New, Courier, monospace;">alias strehler="</span><span style="font-family: 'Courier New', Courier, monospace;">perl -I$GITURL/src/lib $GITURL/src/script/strehler"</span></blockquote>
When the file is ok source it.<br />
<blockquote class="tr_bq">
<span style="font-family: Courier New, Courier, monospace;">source strehler-devel</span></blockquote>
<h2>
Testing site</h2>
All Strehler power is now available, coming directly from the git repository on your machine. Now you can easly create a testing site with Strehler onboard using strehler script itself.<br />
<blockquote class="tr_bq">
<span style="font-family: Courier New, Courier, monospace;">strehler demo</span> </blockquote>
Just run it as<br />
<blockquote class="tr_bq">
<span style="font-family: Courier New, Courier, monospace;">perl bin/app.pl</span> </blockquote>
to see Strehler and (eventually) your modifications in action.<br />
<blockquote class="tr_bq">
</blockquote>
<br />
<blockquote class="tr_bq">
</blockquote>
<blockquote class="tr_bq">
</blockquote>
<blockquote class="tr_bq">
</blockquote>
<div>
<br /></div>
Cymonhttp://www.blogger.com/profile/12929196519388090491noreply@blogger.com0tag:blogger.com,1999:blog-7216284694978513305.post-3797498077899898692015-02-09T00:32:00.000+01:002015-02-09T00:32:02.851+01:00Manipulating databasesDatabase management is something very difficult to do, because databases are strange things created by strange people and database are also <i>many</i>, each of them doing things the way they think better. There'ra no two databases that thinks the same way.<br />
<br />
When I wrote <b>strehler initdb </b>command I was quite impressed by the deploy function of <a href="http://search.cpan.org/~ribasushi/DBIx-Class-0.082810/lib/DBIx/Class/Schema.pm">DBIx::Class::Schema</a> that worked like magic , creating databases as I want, But creating a database from zero is an easy task, changing an existing one, possibly without DROP TABLE commands that trash data is more interesting.<br />
<br />
There're packages that do exactly this, like <a href="http://search.cpan.org/~ribasushi/DBIx-Class-0.082810/lib/DBIx/Class/Schema/Versioned.pm">DBIx::Class::Schema::Versioned</a>, but they have a static management. You build your database, you give a version to your schema. You change your database, you give another version and something calculate the diff. It's good, but I was looking for something more dynamic.<br />
<br />
Why doesn't a dynamic way to change database exist? Because, obviously, changing a database dynamically is a <i>bad idea</i> in many cases, you should have control on it, but I wasn't thinking about a CMS that change databases through a web interface, I just wanted to do it as a script, to embed it in my strehler script.<br />
And I want to cver just the easy case where I add brand new tables, no modifications to the existing ones.<br />
<br />
My first option was starting from schema. I took my existing DBIx::Class::Schema, I added my tables to it with register method and then I tried a new deploy, turning off the DROP TABLE option. Result was good but... DBIC gave me back a bunch of error about existing tables that it cannot create again, so the output of the operation was really dirty.<br />
<br />
Problem is that noone considered the concept of deploying just a table and, for me, deploying a schema containing only new tables wasn't enough, because this way all the foreign keys to old tables wouldn't be created.<br />
<br />
Solution I found is dirty but... it works and, for now, I didn't find a way to break it. Starting point is the same of the precedent case: take DBIx::Class::Schema and add new tables to it registering DBIx::Classes. Then there's some dirty work you have to do by yourself.<br />
<br />
A step back: deploy function in DBIx::Class::Schema starts from your schema, create queries from it considering the target database and then execute them. The tool that extract queries from yout classes is <a href="http://search.cpan.org/~ilmari/SQL-Translator-0.11021/lib/SQL/Translator.pm">SQL::Translator</a> and you can use it also without DBIx::Schema::Class deploy function.<br />
<br />
You can run SQL::Translator on your original schema, obtaining a list of queries to create it. Then you can run it on you database modified using register function. Considering that you're just adding tables you'll have a new array with same queries from before and a couple of new ones.<br />
<br />
Deploying new tables only is about calculating the diff between these two arrays and run just it on your DBIC connector... with little tricks to avoid running queries in wrong order.<br />
<br />
If you want to see an implementation of this little hack you can see it in <a href="http://search.cpan.org/~cymon/Strehler-1.5.5/lib/Strehler/Element/Role/Maintainer.pm">Strehler::Element::Role::Maintainer</a>.<br />
<br />
<br />Cymonhttp://www.blogger.com/profile/12929196519388090491noreply@blogger.com0tag:blogger.com,1999:blog-7216284694978513305.post-31677891998816429042014-12-08T11:34:00.000+01:002014-12-08T11:34:22.621+01:00EX powerSo this weekend Strehler received a major release and two minor bugfix releases and it's now at 1.4.2.<br />
<br />
When I completed Strehler backend I was so excited about how easy was to install it and start writing contents for a site. Then, I started working on a real frontend and I found doing that a very boring work, with a lot of copy-and-paste and clumsy writing.<br />
<br />
Creating Strehler I was obsessed by the opportunity to make it highly configurable because in my life I always stop loving packages like it when I found what they decided by themself, without asking my opinion. Most of Strehler has a parameter that control it, side effect of this is that you have to write a lot to make the whole thing having the right place.<br />
<br />
High level refactoring of this exists. What about taking all the boring code I wrote for fulfill simple tasks and "hide" it behind Dancer2 keyword? The EX plugin was born.<br />
<br />
The EX plugin is a collection of keywords for standard cases. In particular they can be used to serve a content called using its slug, to display a list of contents of a category or just to manage a page with contents that you write once and then you throw away (like homepage boxes).<br />
<br />
EX plugin keywords can still be a little complex to understand, because they need obviously nested hashes to work well, but at least you have just to understand the meaning of their parameters and not perl code to use them and <a href="http://search.cpan.org/dist/Strehler/lib/Strehler/Dancer2/Plugin/EX.pm">documentation</a> can help you doing this.<br />
<br />
It's also a point of my <a href="http://www.strehler-cms.org/todo">todo page</a> so i'm really proud of it!<br />
<br />
I'm less proud about the two minor releases. The first was done because I wantend more options and configurable things in EX plugin plus a smarter way to write code. The second was done because I did the first too fast :-)Cymonhttp://www.blogger.com/profile/12929196519388090491noreply@blogger.com0tag:blogger.com,1999:blog-7216284694978513305.post-38553045079580635582014-11-15T23:54:00.002+01:002014-11-15T23:54:57.506+01:00A matter of timeStrehler 1.3.0 is released. This means that all the problems with Dancer2 0.15x are solved. More than that, requirement about Dancer2 moved up from Dancer2 0.11 to Dancer 0.15002.<br />
<br />
In the previous episodes we saw that Dancer2 App, from version 0.15, try to find their configuration file in a directory near the one they are installed, ignoring where is the script that uses them. This was very bad for Strehler becase Strehler apps like Strehler::Admin are installed using CPAN so they are in the local repository, a place where no configuration file can be stored.<br />
<br />
Only available solution (for now) is overriding thi behaviour setting environment variable DANCER_CONFDIR to the path where our config.yml actually is. Can we do it inside a script so that we can use this solution in any context, like CPAN tests? The answer is yes, if you know the right things about perl.<br />
<br />
First of all, any perl script can access environment variables through the %ENV hash, a read/write variable always available. So, first step should be to write in your code:<br />
<br />
<span style="font-family: Courier New, Courier, monospace;">$ENV{DANCER_CONFDIR} = /the/directory/I/want</span><br />
<span style="font-family: Courier New, Courier, monospace;"><br /></span>
<span style="font-family: inherit;">Now you can think that, including my app, all will work, so you're thinking about something like this:</span><br />
<span style="font-family: inherit;"><br /></span>
<span style="font-family: Courier New, Courier, monospace;">$ENV{DANCER_CONFDIR} = /the/directory/I/want</span><br />
<span style="font-family: Courier New, Courier, monospace;">use Strehler::Admin</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"><br /></span>
<span style="font-family: inherit;">Don't run too fast, this code WILL NOT work.</span><br />
<span style="font-family: inherit;"><br /></span>
<span style="font-family: inherit;">There's a lot of interesting concepts about <i>perl interpreter </i>behind this problem. Concepts, I hope, one day you'll be curious about. For now it's enough to say that "use" directive will run before DANCER_CONFDIR assignment even though you write it in the end of your file.</span><br />
<span style="font-family: inherit;"><br /></span>
<span style="font-family: inherit;"> Modules must be loaded before any other piece of code because consistency of any piece of code can be verified only with all the module loaded. Perl interpreter does it without asking nothing, ignoring that you necessary need to do something before.</span><br />
<span style="font-family: inherit;"><br /></span>
<span style="font-family: inherit;">Can you change this behaviour? Yes, two ways to do it:</span><br />
<br />
<ul>
<li>BEGIN directive will run all the code inside its block before any other code, including use.</li>
</ul>
<div>
<span style="font-family: Courier New, Courier, monospace;">BEGIN</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;">{</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;"> $ENV{DANCER_CONFDIR} = /the/directory/I/want</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;">}</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;">use Strehler::Admin;</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;"><br /></span></div>
<div>
<ul>
<li><span style="font-family: inherit;">require directive instead of use load the module only when someone ask for it,with no precedence on anything.</span></li>
</ul>
</div>
<br />
<div>
<span style="font-family: Courier New, Courier, monospace;">$ENV{DANCER_CONFDIR} = /the/directory/I/want</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;">require Strehler::Admin;</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;"><br /></span></div>
<div>
<span style="font-family: inherit;">You can see an example of this <a href="http://cpansearch.perl.org/src/CYMON/Strehler-1.3.0/lib/Strehler/demo/app.pl">here</a>.</span></div>
<div>
<span style="font-family: inherit;"><br /></span></div>
<div>
<span style="font-family: inherit;"><a href="http://search.cpan.org/~cymon/Strehler/lib/Strehler/Manual/Installation.pod#DANCER_CONFDIR">Here</a> are described many ways to configure DANCER_CONFDIR.</span></div>
<div>
<span style="font-family: inherit;"><br /></span></div>
<div>
<span style="font-family: inherit;">Why don't I want to consider this as the definitive solution for the problem? Because I think it's still a dirty way to do things because force you to use an environment variable and disable the original App behaviour that allow each of them to have a separated config file, something that could come useful in some situations.</span></div>
Cymonhttp://www.blogger.com/profile/12929196519388090491noreply@blogger.com0tag:blogger.com,1999:blog-7216284694978513305.post-7468872731285876012014-11-09T12:41:00.001+01:002014-12-23T00:15:14.636+01:00Plack::Test and Dancer Session<a href="http://en.wikipedia.org/wiki/PSGI">PSGI</a> is very easy to understand: a black box, something goes in, something goes out. What goes in: a request made of a path and headers. What goes out: a response with a content and more headers.<br />
<br />
<a href="http://search.cpan.org/~miyagawa/Plack-1.0033/lib/Plack/Test.pm">Plack::Test</a> follows this structure. What you have to test is the black box, you inject the request in it and analyze the response you receive back.<br />
<br />
Important thing to understand is that Plack::Test is something very different from an emulation of a browser like <a href="http://search.cpan.org/~mschilli/libwww-perl-6.08/lib/LWP/UserAgent.pm">LWP::UserAgent</a>. Most important difference is, obviously, in session management, because that's something that should survive between calls and in Plack::test every call is a test by itself, with no memory of what happens around it.<br />
<br />
What do you have to do if you want to test something like a login using Plack::Test? Well, the solution is very easy because the concept of session is AN ILLUSION throughout all the web. It's not just Plack::Test, the HTTP protocol itself is session-less. The "session" you see is just a set of tricks that clients and servers do under the hood.<br />
<br />
As we said: a request go, a response returns, nothing more, so the session is something that must be hidden there. In particular, session is controlled throught headers, in particular headers that control browser cookies.<br />
<br />
There're a lot of documentation about how cookies and response headers have to interact and probably studying it could be very interesting, but <a href="http://search.cpan.org/~gaas/HTTP-Cookies-6.01/lib/HTTP/Cookies.pm">HTTP::Cookies</a> module contains all the knowledge you need so learn to use it will be enough.<br />
<br />
Let's do a login and get the response from it:<br />
<br />
<span style="font-family: Courier New, Courier, monospace;">$r = $cb->( POST '/admin/login', [ user => 'admin', password => 'admin' ] );</span><br />
<br />
Response object $r contain many headers, one of that ask the client to write in a cookie the identifier of dancer session. We can use HTTP::Cookies to extract this information.<br />
<br />
<span style="font-family: Courier New, Courier, monospace;">my $jar = HTTP::Cookies->new;</span><br />
<span style="font-family: Courier New, Courier, monospace;">$jar->extract_cookies($r);</span><br />
<br />
Now we want that, in the next call, the server find us logged in.<br />
<br />
When a browser does a request to a site, it passes in the request all the informations related to the cookies it has. This way it can say to the server what is its dances session identifier. Using that, the server can retrieve any information about the caller, like its status as logged user.<br />
<br />
Let's cook a call for admin homepage.<br />
<br />
<span style="font-family: Courier New, Courier, monospace;">my $req = HTTP::Request->new(GET => $site . '/admin');</span><br />
<br />
<b>WARNING</b>: Remember to ALWAYS create request with complete URL, starting from <b>http</b>, otherwise HTTP::Cookies method add_cookie_header will not work!<br />
<br />
Now we want that this call carry information about the cookies of the previous call, where logged in user session was configured. We just have to get information out from the cookie jar.<br />
<br />
<span style="font-family: Courier New, Courier, monospace;">$jar->add_cookie_header($req);</span><br />
<br />
Now this req will been seen by the server as the logged user from the previous call did it.<br />
<br />
Well, if you configured in a clever way the server too.<br />
<br />
Remember? There's no memory between requests client-side AS server-side. Client memory is in the cookies and HTTP::Cookies helps us to manage it. Where is server memory?<br />
<br />
Standard session management in Dancer leave session information in RAM. On a development server this is enough, but a development server is something that stay alive between different calls so you can consider information stored in RAM persistent. Plack::Test instantiate the black box fresh new at every call so information about sessions is always trashed at the end of it.<br />
<br />
Harddisk is more reliable if you want to store persisten information so switch session management to YAML when doing this kind of test.<br />
<br />
<a href="http://cpansearch.perl.org/src/CYMON/Strehler-1.3.0/t/001_plack_login.t">Here</a> is a little example of what we said.<br />
<br />
<br />
<br />Cymonhttp://www.blogger.com/profile/12929196519388090491noreply@blogger.com0tag:blogger.com,1999:blog-7216284694978513305.post-32907229769680638922014-11-04T00:30:00.000+01:002014-11-04T00:30:16.645+01:00The darkest hourI've been away from this place for long time, I know, and I also know that also Strehler has been left with no updates for many months. There're technical questions about all this silence and I want to explain them here.<br />
<br />
This summer Dancer2 reached release 0.150000, quite an improvement! A lot of things changed with this release of the framework, most of them related to the concept of App.<br />
<br />
Major architectural changes are something I know I have to deal with, talking about Strehler's developement. Dancer2 code is not stable, it's usually considered alpha and I know that chasing its releases is one of the most difficult but important tasks for me as mantainer of a module based on it.<br />
<br />
Problem is 0.150000 Dancer2 was too much. I described the issue introduced by this release <a href="https://github.com/PerlDancer/Dancer2/issues/674">here</a>, Briefly, an App installed in your local repository gives a lot of trouble when it's time to read configuration files, because App uses its own path to find site resources, ignoring the path of the script that manage site startup.<br />
<br />
For now, in my opinion, there's no way to solve the question fixing Strehler. Problem is inside Dancer2 architecture so I hope that the Dancer2 development team will do something. Waiting for it, this is what I can say if you want to use Strehler:<br />
<br />
<br />
<ul>
<li>Strehler latest release is perfectly working with any Dancer2 0.14x release. So, if you don't update Dancer2 packages too much you have nothig to fear.</li>
<li>You can make Strehler works with Dancer2 0.15. You just have to ignore all the tests and run your site setting the environmental variable DANCER_CONFDIR as the directory where your config file is. It's quite simple and I know I could consider it the definitive fallback, but it's not clean and still I don't know how to use it to run the test suit, so I take this as a temporary workaround.</li>
</ul>
<div>
Well, I don't have much more to say, this is the situation at today. I hope it will change soon and I think it will, but patience, for a bit, has to be your new best friend.</div>
<div>
<br /></div>
<div>
Last announcement: Strehler has now a site. Click <a href="http://www.strehler-cms.org/">here</a> for it. Important articles from this blog will be reported there, as a place to aggregate every communication about the development.</div>
Cymonhttp://www.blogger.com/profile/12929196519388090491noreply@blogger.com0tag:blogger.com,1999:blog-7216284694978513305.post-68183607618366874252014-07-20T12:15:00.000+02:002014-07-20T12:15:47.331+02:00Strehler 1.2.1: the hiveStrehler made the jump from 1.1.x to 1.2.x. Obviously, the first attempt had a dirty bug related to old perl versions, so the package we cleebrate now is the 1.2.1.<br />
<br />
Strehler 1.2.1 is about Strehler frontend. No real front-end will be ever developed in the Strehler project, Strehler will never become a Wordpress or a Joomla! (but a CMS like them could be built on top of it). Otherwise, 1.1.x system is too limited, because it gives you no way to access contents you created. Yes, you can write a site that do that, but there's nothing out-of-the-box.<br />
<br />
Most trendy way to serve contents in our days is through APIs, preferably APIs that some clever JS library like <a href="https://angularjs.org/">AngularJS</a> can manage. So I added to the projct a package, <a href="http://search.cpan.org/dist/Strehler/lib/Strehler/API.pm">Strehler::API</a>, that, using the same logic of the admin views, generate paths to return Strehler contents in JSON(p) format.<br />
<br />
Here below, the rules I found on internet about APIs that I used developing Strehler's (just a reminder for myself):<br />
<br />
<ul>
<li>Return format is JSON. It's the most friendly for javascript and open systems. Other formats will probably follow in further development.</li>
<li>Along with JSON you can ask data in JSONp format in any situation, just adding a callback parameter. This is important when working with cross-domain platforms and... it's so easy to do that not implementing it would be just cruel.</li>
<li>JSON response content-type is 'application/json', JSONp response content-type is 'application/javascript' (don't laugh, there're many questions on Stackoverflow about this).</li>
<li>API path contains a reference to API version, so is /api/v1/... I can't imagine, now, a reason API version can change but it's always better to expect the unexpected.</li>
<li>Error codes are returned with a JSON content with the error message. In my opinion is right that error "pages" are JSON too, because whatever is calling your API, you can assume it's not a human being using a browser. Giving him back a kitten with a sorry face on 404 will be probably not easly understood by IT. (probably this feature should be improved a little, considering 1.2.1 version of the package)</li>
<li>Singular and no ending slash => an element, Plural and ending slash => a list. "Ending slash" rule is not written anywhere, it's just how I like things. I think it works well.</li>
</ul>
Cymonhttp://www.blogger.com/profile/12929196519388090491noreply@blogger.com0tag:blogger.com,1999:blog-7216284694978513305.post-70770586132333490252014-06-02T16:09:00.000+02:002014-06-02T16:09:00.913+02:001.1.10 is da boss + something about AJAXIt's impossible to be sure about something like this, but I think I can consider Strehler 1.1.10 version as the first actual mature version of the product.<br />
<br />
When I released on CPAN 1.1.0 I didn't consider it mature because I knew that a lot of features were implemented in the wrong way and many tools were hard to be used by a developer. There were too much cut and past, too much hocus pocus, too complex documentation to read.<br />
<br />
Now, in my opinion, a developer can implement his site in a very quick way, understanding what he's doing and with the right level of trust in what I did and in what I will do (for example: update my code).<br />
<br />
So, this time i want to make a toast bigger than the ones about previous releases.<br />
<br />
Closing the last little bugs about Strehler I found something very interesting about <a href="http://search.cpan.org/~xsawyerx/Dancer2-0.140001/lib/Dancer2/Plugin/Ajax.pm">Dancer2::Plugin::AJAX</a> that I want to share with you.<br />
<br />
Dancer2 AJAX plugin is a little piece of code that wrap few interesting features you like to have where you serve an AJAX request.<br />
More than this: it's really easy to use, you should never understimate that.<br />
<br />
The strange thing about the plugin is that answer content type default is XML... In my opinion this is a little weird because when I think about AJAX I usually think about Javascript interaction where JSON is easier to use.<br />
<br />
You can just configure the plugin to give you back a different content type, but when we modify global configuration I don't completely understand, I become a little paranoid. So my decision for my routes was to force the right content-type directly in the function.<br />
Cymonhttp://www.blogger.com/profile/12929196519388090491noreply@blogger.com0tag:blogger.com,1999:blog-7216284694978513305.post-42378714517941633752014-05-21T00:11:00.000+02:002014-05-21T00:11:02.236+02:00Strehler 1.1.9 releasedReleased but not perfect. There're little problems about documentation and I probably found a little error in strehler script, layout function. Well, as usual...<br />
<br />
I'm not sure I can find a way to test Strehler script but I should, at least to check if it gives an error in standard situations. The script, in my opinion, is a very sensitive part of the package. Strehler script go to war on the open ground of user's file system, it can find strange things and fight insidious enemies, it deserves attention. For example, I'm not sure how it works under Windows...<br />
<br />
Another point in my TO-DO list is find a way to see how CPAN page will be rendered, after package upload, just to avoid little glitches in documentation as I'm experimenting now.<br />
<br />
Well, stop with the bad things, a Strehler release is always something to celebrate, 1.1.9 bring order in FormFu elements and configuration and we love it for that!Cymonhttp://www.blogger.com/profile/12929196519388090491noreply@blogger.com0tag:blogger.com,1999:blog-7216284694978513305.post-83012085256222819452014-05-18T18:56:00.001+02:002014-05-18T18:56:16.609+02:00HTML::FormFu BeastmasterI'm not a great fan of <a href="http://search.cpan.org/dist/HTML-FormFu/">HTML::FormFu</a> package.<br />
Let me explain: HTML..FormFu does a lot of dirty job and give you an easy way to write down forms with a lot of business logic, but when you try to open is source code to do some customization it's quite a labyrinth with too much trolls and few indications about the right road.<br />
In my opinion the module could be ten times more powerful giving an easy way to hack elements and modify them for new purposes.<br />
<br />
Writing down Strehler interface I obviously had to manage a lot of forms. I wrote many of them following Strehler business logic to offer easy ways for javascript to work with them, this logic is something built on top on HTML::FormFu elements.<br />
<br />
The category selector, probably the most complex widget I had to use, in forms configuration files is something like this:<br />
<blockquote class="tr_bq">
<br />
- type: Select<br />
id: category_selector<br />
name: category<br />
label: Category<br />
constraints:<br />
type: Required<br />
message: 'Category needed'<br />
- type: Select<br />
name: subcategory<br />
label: Sub-category<br />
id: subcat</blockquote>
Problem is that Strehler should give other developers the opportunity to implement their own entities and forms managing them. These forms could contain my category selector and I can't ask people to copy and paste all this code in their YML files. It's really clumsy and what if I change this structure? I should call them one by one and ask to change their files.<br />
<br />
TIdy implementation wants that, when you need a category selector, you just add in your form configuration:<br />
<br />
- type: "+Strehler::FormFu::Element::Category"<br />
<br />
An ad hoc HTML::FormFu element.<br />
<br />
There's not a real path to implement something like that, best way I found is to hack a HTML::FormFu::Element::Block nailing in it a fixed configuration with the elements of my category selector. The result is <a href="https://github.com/cym0n/strehler/blob/d4fdefb7b92796853306125fc01857756880b3e3/src/lib/Strehler/FormFu/Element/Category.pm">here</a>.<br />
<br />
You can do a lot of thngs exploiting the after BUILD of the HTML::FormFu::Element sub-classes, but you'll be always limited to the possibilities given by the class and its methods and, for example, you'll not have any chance to add custom configuration entries. So this pattern can be useful when you just want to make a package of some existing configurations, but nothing more.<br />
<br />
Strehler::FormFu::Element::EntitySelect is something a bit more smart, as you can see <a href="https://github.com/cym0n/strehler/blob/8c22f4b77a77d87ec43d6a2d95877c68ad74350b/src/lib/Strehler/FormFu/Element/EntitySelect.pm">here</a>, but it's still an hack on Select I did after giving up on creating a FormFu::Element completely by myself.<br />
<br />
Working on that, I drew a class diagram of HTML::FormFu (still 0.9 version), doing a bit of reverse engeneering on it. <a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhlgY9ASi6XWDELxvbnjFsqlA-kROpYSsv5EfvnWz_eOkTFwOp4glIU6aJhKW6UtaxJK2hkf4tD72oVoasCr4td4Sc5qJAH4ZQ5Qdt2IXg1pWKRvSrrNtmv6402nZgNIgivgYySYwXnikU/s1600/HTML_FORMFU.jpg">Here it is</a>, as a gift from me.<br />
<br />
<br />
<br />Cymonhttp://www.blogger.com/profile/12929196519388090491noreply@blogger.com0tag:blogger.com,1999:blog-7216284694978513305.post-86337069019530103462014-05-09T00:37:00.002+02:002014-05-09T00:37:53.794+02:00Refactoring configurationI'm going through an interesting refactoring that I'm doing using roles (my first time) and I'd like to summing up what I'm doing in this blog.<br />
<br />
I think that an important feature of Strehler is the possibility to manage custom entities, custom "database tables" that can be manipulated through Strehler backend using all the features Strehler makes available.<br />
New entities can be easly (I hope) added as said in this <a href="https://github.com/cym0n/strehler/wiki/extra-entity-tutorial">tutorial</a>, but to give enough freedom to developer, as you can see, there's a lot of flags available in Strehler configuration to change the behaviour of the entity itself.<br />
<br />
The actual problem is that not only new custom entities need values for those flags, but also standard entities: Article, Image, User and Log and they can't just use all the default values. Log, for example, is not creatable or editable, it's interface has to be read-only while Article, Image and User allow a complete CRUD flow.<br />
Big question is: where configurations for them are?<br />
<br />
Solution until Strehler 1.1.8 is horrible. I've and horrible method (<a href="https://github.com/cym0n/strehler/blob/fb0096913ed77d7dc8fcbc372443d038fac3cee6/src/lib/Strehler/Helpers.pm">see it here</a>) that fetch informations from config.yml and assign hardcoded values for standard entities.<br />
<br />
This solution has, in my opinion, two problems:<br />
<br />
<ul>
<li>It's in the wrong place. Six months from now I'll never think that Article configuration is in a curious Strehler::Helper packages package.</li>
<li>Makes config.yml the only way to configure entities. Flags are A LOT and many configurations can make this file a real mess.</li>
</ul>
<div>
This is the reason I'm introducing a role consumed by Strehler::Element where every parameter is a method returing, with no input parameters, the value of the flag itself. Standard implementation of every method is just a little piece of code reading from config.yml, as in Strehler::Helper.</div>
<div>
Why is this solution better? Because is... more object oriented and allows me (and Strehler developers) to keep informations about entities in the entity class, where they should be. </div>
<div>
So, for example, Article parameters doesn't need no more an external method in a strange place. They're just in Strehler::Element::Article, an override of the standard methods where fetching from config.yml is replaced by returning just the hardcoded value... hardcoded in the right place.</div>
<div>
<br /></div>
<div>
This way, a Strehler developer creating a custom entity can now choose between write down all the configurations in the config.yml or just leave in config.yml minimal configuration needed and add all the parameters in the custom class.</div>
<div>
I think that both methods should be used: config.yml when a flag can change through time or in different environments, class methods when a parameter is... "endemic" for the designed entity.</div>
<div>
<br /></div>
<div>
I talked about methods and not attributes because in many cases I need to know class configuration, without an instanced object. Is the same logic of the metaclass_data method.</div>
<div>
<br /></div>
<div>
I hope to release this new configuration soon!</div>
<div>
<br /></div>
Cymonhttp://www.blogger.com/profile/12929196519388090491noreply@blogger.com0tag:blogger.com,1999:blog-7216284694978513305.post-61593440171041980272014-05-04T00:10:00.000+02:002014-05-04T00:10:35.757+02:00Messing a lot with filesSo we have a <b>1.1.8 </b>just to bugfix <span style="font-family: Courier New, Courier, monospace;">strehler statics. </span><br />
<span style="font-family: inherit;">Problem using it to update (not create) files on a package update was that file were created all read-only, as they are saved in the CPAN package, and when new ones tried to overwrite them they obtain a permission denied.</span><br />
<span style="font-family: inherit;">Only solution I found is to delete the public/strehler directory from the target project and then copy again it with all the files in the last version. This is not an operation easy to do using perl libraries, I found them a little complicated to use. They don't actually map the shell commands (rm, cp, mv) but follow their logic, so using them for what I needed was a bit difficult.</span><br />
<span style="font-family: inherit;">For example there's not a straight way to copy a directory from a place to another as in:</span><br />
<blockquote class="tr_bq">
<span style="font-family: inherit;">cp -r $DIR $DESTINATION</span></blockquote>
If you just use dircopy from <a href="http://search.cpan.org/~dmuey/File-Copy-Recursive-0.38/Recursive.pm">File::Copy::Recursive</a> as:<br />
<blockquote class="tr_bq">
dircopy($DIR, $DESTINATION)</blockquote>
<span style="font-family: inherit;">then all files in $DIR will be trasferred under $DESTINATION (files, NOT the directory).</span><br />
<span style="font-family: inherit;">To obtain what I said you have to... well, copy and paste the magic string:</span><br />
<blockquote class="tr_bq">
$File::Copy::Recursive::CPRFComp = 1;</blockquote>
The magic and not-exactly-human-readable string.<br />
<br />
I already released a new version because update problem wasn't the only problem of the statics command... Well, the whole command implementation was a mess, with wrong messages and other problems, so i wasn't confortable leaving it in CPAN for a long time. It's just a little number increase...Cymonhttp://www.blogger.com/profile/12929196519388090491noreply@blogger.com0tag:blogger.com,1999:blog-7216284694978513305.post-77506552744392823912014-05-02T11:49:00.000+02:002014-05-02T11:55:51.963+02:00All the releases come with a bugSo I released Strehler <b>1.1.7</b>. Now the filter is improved and you can select a category to obtain all the elements in it <i>and in its children</i>.<br />
<br />
The real reason I did it, however, is that <b>1.1.6</b> has a terrible bug that break the <span style="font-family: Courier New, Courier, monospace;">strehler initdb </span><span style="font-family: inherit;">command making impossible a complete Strehler installation as described in the documentation. Strehler installation process is something that MUST go well plain and fast or I judge the entire package useless, because I created it to make a CMS deployment easy.</span><br />
<span style="font-family: inherit;"><br /></span>
<span style="font-family: inherit;">But... now I found a little problem on </span><span style="font-family: Courier New, Courier, monospace;">strehler statics </span><span style="font-family: inherit;">when it comes to use it to update your statics after an update of the package. Less vital than the solved bug on initdb, but still annoying, probably e new release will be done soon.</span><br />
<span style="font-family: inherit;">At the moment, if you update Strehler package from a version to another (for example from 1.1.6 to 1.1.7) to make all works delete the public/strehler directory in your project and then run </span><span style="font-family: Courier New, Courier, monospace;">strehler statics</span><span style="font-family: inherit;"> again. Al the resources will be regenerated in the right version.</span><br />
<span style="font-family: inherit;"><br /></span>
<span style="font-family: inherit;">Also the <a href="http://blogs.perl.org/users/sawyer_x/2014/04/major-dancer-2-release-0140000.html">Dancer2 0.14000 release</a> gave me some work. As described in the release notes, Runner-Server was untangled. I like the explanation about why this was done, my problem is that all my tests were written using </span><b>Test::TCP </b>relying on the Dancer2 Standalone Server for the server part. With Dancer2 0.140000 al this part went broken.<br />
So I managed to change this line of code:<br />
<br />
<blockquote class="tr_bq">
Dancer2->runner->server->port($port);</blockquote>
with this if clause<br />
<span style="font-family: inherit;"><br /></span>
<span style="font-family: inherit;"> if( $Dancer2::VERSION < 0.14 )</span><br />
<span style="font-family: inherit;"> {</span><span style="font-family: inherit;"> Dancer2->runner->server->port($port); </span><span style="font-family: inherit;">}</span><br />
<span style="font-family: inherit;"> else</span><br />
<span style="font-family: inherit;"> {</span><span style="font-family: inherit;"> Dancer2->runner->{'port'} = $port; </span><span style="font-family: inherit;">}</span><br />
<br />
just to keep retrocompatibility.<br />
<blockquote class="tr_bq">
</blockquote>
Cymonhttp://www.blogger.com/profile/12929196519388090491noreply@blogger.com0tag:blogger.com,1999:blog-7216284694978513305.post-51206408370716917962014-05-01T12:05:00.001+02:002014-05-01T12:05:16.397+02:00Strehler: state of the artI know that i'm not a frequent writer so a lot of interesting things about me doesn't appear on this place because i'm lazy. So I decided to write just a post to summing up how Strehler is going on after the <a href="http://perlishscrewdriver.blogspot.it/2014/02/habemus-strehler.html">1.0.0 release</a>.<br />
<br />
Well, a lot of things changed and got better since that day. The first, fundamental step, with <b>1.1.0</b> was landing on <a href="http://search.cpan.org/dist/Strehler/">CPAN</a> with a real test suite and some supporting script. Now you can install Strehler using just cpan -i Strehler and getting an up and running CMS with few commands. In many ways the 1.1.0 release of Strehler is the <i>real </i>first release, because I know that the long, boring and messy installation procedure of 1.0.0 is something NOONE would use, out of me, obviously, but I'm the father of Strehler and my judge is irrilevant.<br />
<br />
Strehler 1.1.0 was my first package released on CPAN so I learned a lot releasing it. I learned about <a href="http://pause.perl.org/">PAUSE</a>, about <a href="http://dzil.org/">distzilla</a> and about how many thing to your code after you upload it on the perl repository. I did a lot of things wrong because mistakes are the way nature teach you things, so in the week after 1.1.0 release I released FIVE bugfix packeges bringing rapidly Strehler to <b>1.1.5</b> version. Well, it's a good thing, high numbers make your software truly professional.<br />
<br />
With a quite stable version of my software on the public repository, I started work about little features not yet implemented, like function to order admin list and searchbox. All these things went in the <b>1.1.6</b> version and i'm quite proud of it. Yes, a lot of work could be done on the search box because it is implemented in the easiest and plainest way I found, with no indexing or optimizations. It's good because it's accessible just from the backend of your site, but it's probably not a good implementation if you want it also on the frontend. Probably in the future I'll do something, pluggable if I can, about it.<br />
<br />
I'll probably release soon a <b>1.1.7</b> version. I wanted to wait after some implementations, but I found a big bug in the strehler script that make impossible to create a strehler database on your custom site, making all the installation process useless. I fixed it and I want to share it with the world as soon as possible.<br />
<br />
After that, a lot of adventures are waiting for us!<br />
<br />
<br />Cymonhttp://www.blogger.com/profile/12929196519388090491noreply@blogger.com0tag:blogger.com,1999:blog-7216284694978513305.post-12361821924680794062014-03-29T15:14:00.000+01:002014-03-29T15:14:47.493+01:00The spring of HTML::FormFuHTML::FormFu arrived on his first major release (1.00) this christmas. It's quite an event considering that previews release was on 05 Oct 2012.<br />
<br />
I'm very happy for that because now form rendering is better and cleaner. Problem is that this new rendering had some incompatibility with my Strehler forms (javascript and CSS) so, when I upgraded, thing went a little messed up.<br />
<br />
The most interesting thing (the only worth to be written here) is about my little CategoryUnique validator.<br />
<br />
Strehler backend manage a category tree that you can use to organize contents. For example:<br />
<br />
<span style="font-family: Courier New, Courier, monospace;">foo</span><br />
<span style="font-family: Courier New, Courier, monospace;">foo/bar</span><br />
<span style="font-family: Courier New, Courier, monospace;">foo/ber</span><br />
<span style="font-family: Courier New, Courier, monospace;">yetanothercategory</span><br />
<span style="font-family: Courier New, Courier, monospace;">newcategory</span><br />
<span style="font-family: Courier New, Courier, monospace;">newcategory/newson</span><br />
<br />
When you create a new category you have to give its name and its parent. The CategoryUnique validator check if the category already exists under that parent.<br />
<br />
In the example up there you can create bar under newcategory, you can't under foo, because there's already one category named that way.<br />
<br />
So the validator can't just check about the value of the category field, but it has also to consider the second parameter of the form, to check if the category has the same name under the same parent.<br />
<br />
With HTML::FormFu 0.09010 it was easy:<br />
<br />
<span style="font-family: Courier New, Courier, monospace;">my $self = shift;</span><br />
<span style="font-family: Courier New, Courier, monospace;">my $parent = $self->form->param_value('partent');</span><br />
<br />
Easy, yes, but apparently forbidden by <a href="http://search.cpan.org/~cfranks/HTML-FormFu-0.09010/lib/HTML/FormFu.pm#param_value">documentation</a>.<br />
<blockquote class="tr_bq">
If the value is invalid or the form was not submitted, it returns undef.</blockquote>
In a validator a value cannot be already valid :-)<br />
<br />
But it worked because there was a bug, <a href="http://comments.gmane.org/gmane.comp.lang.perl.modules.html-formfu.general/3294">a bug fixed in the December 2012</a>.<br />
<br />
We could exploit it just because no new release of HTML::FormFu come after that fix... until December 2013.<br />
<br />
What can we do now, with the shiny fixed 1.00 version of the software? The only way I find to do the same thing is to use the <i>undocumented </i>HTML::FormFu::FakeQuery. The query method of the form, infact, doesn't return an hash as documentation still say, but an instance of this object.<br />
<br />
Luckly, using it is easy enough:<br />
<br />
<span style="font-family: Courier New, Courier, monospace;">my $self = shift;</span><br />
<br />
<span style="font-family: Courier New, Courier, monospace;">my $query = $self->form->query();</span><br />
<span style="font-family: Courier New, Courier, monospace;">my $parent = $query->param('parent');</span><br />
<br />
<br />
without passing through the param method of the form, that HTLM::FormFu documentation itself doesn't trust.<br />
<br />
<br />
<br />Cymonhttp://www.blogger.com/profile/12929196519388090491noreply@blogger.com0tag:blogger.com,1999:blog-7216284694978513305.post-76528392233602458452014-03-07T01:01:00.001+01:002014-03-07T01:01:48.703+01:00The clock kingI wrote about <a href="http://perlishscrewdriver.blogspot.it/2014/02/entering-time-zone.html">timezones</a> telling how avoid problem using them and, in particular, using timestamp fields. As I said in the end of the article the solution has a big flow: it depends on MySQL configuration.<br />
<br />
This is not good because best practice is to make your code as system-indepentent as possible. It's good if you can install your sotware without checking MySQL timezone. Because MySQL timezone could be configured by someone who is not you, because you could never know the real MySQL timezone and because YOU'LL NOT CHECK MySQL timezone at installation time. You'll forget it. Don't try to fool me, we both know it will go this way.<br />
<br />
So? Is there a better solution? Obviously yes.<br />
<br />
Problem is that timestamp field is a field that carry in it timezone information calculating it using its envionment. This property bind it to MySQL timezone and gives us headaches. So, solution is throw timestamp field away and use datetime instead.<br />
<br />
Datetime field has no timezone information (basically, it's not converted to UNIX Timestamp when saved on the DB table) so it's just a magic string with a day and an hour. It's less powerful so you can have better control on it. The only thing you have to keep in mind is to ensure that, every time your app write a datetime on the database the timezone it uses is always the same. UTC is usually a good choose.<br />
<br />
So, when you insert a new line and you want to trace the moment of insert you no more relay on the MySQL auto-update, but you assign:<br />
<br />
<span style="font-family: Courier New, Courier, monospace;">timestamp => DateTime->now()</span><br />
<br />
DateTime->now() is already with UTC timezone.<br />
<br />
Now you can display your timestamp using any timezone you like. The value you'll receive from database will be UTC so conversion is easy.<br />
Just:<br />
<br />
<span style="font-family: Courier New, Courier, monospace;">my $ts = $dbix_row->timestamp;</span><br />
<span style="font-family: Courier New, Courier, monospace;">$ts->set_time_zone('UTC') #Remember? Value arrive from database with floating timezone</span><br />
<span style="font-family: Courier New, Courier, monospace;">$ts->set_time_zone('TIMEZONE_YOU_LIKE') #Starting from UTC the datetime will be converted</span><br />
<br />
<br />
<br />Cymonhttp://www.blogger.com/profile/12929196519388090491noreply@blogger.com0tag:blogger.com,1999:blog-7216284694978513305.post-10914067650860820992014-02-26T22:57:00.001+01:002014-02-26T22:58:39.431+01:00Habemus Strehler!Well, i worked a lot about it behind the scene, so i'm now a little excited to talk about Strehler, my most complex Perl work.<br />
<br />
Link to github first: <a href="https://github.com/cym0n/strehler">https://github.com/cym0n/strehler</a><br />
<br />
As the README says, Strehler is a light-weight, nerdy, smart CMS in perl based on Perl Dancer2 framework. The story of his creation is very simple: I had to create a website (well, more than one) and after I decided to use Dancer2 I also decided to write the backend interface for it once for all, developing a tool easy to install on any type of webapp you need and with a lot of customizations available out of the box.<br />
<br />
Strehler implements just the standard CRUD needed for a standard site. It can create articles, upload images, organize things with tags and categories. I said more about it in the <a href="https://github.com/cym0n/strehler/wiki">github wiki</a>.<br />
<br />
In my opinion the software reached enough stability to deserve version 1.0.0 tag. My hope now is for people to download it, try it and tell me where I'm wrong thinking this. At this point of development Strehler needs to be seen by fresh eyes, this is the reason i'm announcing that with so much emphasis.<br />
<br />
You can try Strehler, you can use it, you can just find something you don't like and tell me. If you like collaborative work or if you think that Strehler can be what you need with some modifications, just work on it. Code is open and the git repository is there to be used. If you need some advice about how to improve the tool, try the <a href="https://github.com/cym0n/strehler/wiki/todo">TODO page</a>. It's there for me as for everyone ho like to develope using Perl.<br />
<br />
Strehler is ready! Cheers!Cymonhttp://www.blogger.com/profile/12929196519388090491noreply@blogger.com0tag:blogger.com,1999:blog-7216284694978513305.post-40624188412012813682014-02-22T16:42:00.002+01:002014-02-22T16:42:29.957+01:00Entering the time zoneIt' a lot of time I don't write here, i'm working on something that will make me write a lot (I hope) but i'm keeping silence until it is finished. However, today I had to understand timezones more that how much I did before so I want to throw all the knowledge I acquired in this blog, to make it remeber it instead of me.<br />
<br />
Problem of the day is common, but not simple. You have a database with a timestamp field, you want to print it on the screen. It seems easy, a timestamp is just a date and an hour, what could go wrong? Easy, the hour you print IS NOT the hour you expected.<br />
<br />
We are a lot of people who lives in a lot of places. Sun can't shine on all these places at the same time. But everyone wants to wake up in the morning and go to bed in the evening so: timezones are born.<br />
<br />
We assume that you have a MySQL database, that you will read the timestamp column using DBIx::Class and then that a Dancer app will make it visibile on the screen. Every step has its timezone issue.<br />
<br />
<h3>
Timezone Steps</h3>
<h4>
MySQL</h4>
<div>
MySQL knows its timezone and every time it gives you a timestamp the timestamp is considered in that timezone.</div>
<div>
MySQL timezone is the default_time_zone option in my.cnf. If no timezone is provided, the server will use the one of the machine where it it hosted.</div>
<div>
<br /></div>
<h4>
DBIx::Class</h4>
<div>
DBIx::Class has a lot of tools to manage timestamps. Using <a href="http://search.cpan.org/~ribasushi/DBIx-Class-0.08270/lib/DBIx/Class/InflateColumn/DateTime.pod">InflateColumn::DateTime</a> is nearly a standard. Problem is DBIx::Class can't ask MySQL what is its timezone so you have to configure it when you write the model. Your timestamp field will be:</div>
<div>
<br /></div>
<div>
<div>
"timestamp",</div>
<div>
{</div>
<div>
data_type => "timestamp",</div>
<div>
datetime_undef_if_invalid => 1,</div>
<div>
default_value => \"current_timestamp",</div>
<div>
timezone => "Europe/Rome",</div>
<div>
is_nullable => 0,</div>
<div>
}</div>
</div>
<div>
<br /></div>
<h4>
Dancer</h4>
<div>
Dancer is not really involved in this question. Every time you want to print a timestamp you'll go through this code. But this could be used when Dancer has to give you an output on the screen. Here you can decide once more what is the timezone to use. </div>
<div>
<br /></div>
<div>
Few lines:</div>
<div>
<div>
$ts->set_time_zone("Europe/Rome");</div>
</div>
<div>
<br /></div>
<div>
<br /></div>
<h3>
It's a trap!</h3>
<div>
What could go wrong? </div>
<div>
If timezone is not configured in the DBIx::Class you will have, as output, the hour in the timezone of MySQL, but with a "floating" timezone. This means that conversion will be... well... erratic.</div>
<div>
If timezone configured in DBIx::Class is different from the timezone in the MySQL, MySQL timezone will be ignored although the time you receive is made from it. DBIx::Class timezone will be attached to timestamp instead. No automatic conversion will be triggered and you'll have to work just with wrong data.</div>
<div>
<br /></div>
<h3>
How to deal with this</h3>
<div>
Problem I see with this situation is that MySQL is part of the environment while the rest is part of your code. You write the code, but the environment can change. I think that a good idea is always configure the timezone when you output the data ("Dancer" level) so you have a good point to change it if it's needed, without touching the structure below. Than be always sure of your MySQL configuration when you write DBIx::Classes.</div>
<div>
<br /></div>
Cymonhttp://www.blogger.com/profile/12929196519388090491noreply@blogger.com0tag:blogger.com,1999:blog-7216284694978513305.post-402911245050360572013-12-14T19:34:00.000+01:002013-12-15T16:21:59.584+01:00Ballroom Blitz (2)<h1>
Silence in the library</h1>
<div>
When you write a perl program you don't need just the perl interpeter, but also a lot of libraries that someone else wrote. It's easy to fetch them while you're in your developement environment, but when you go to production you have to manage a lot of issues about this problem.</div>
<div>
<br /></div>
<div>
First of all, there's the scenario where you don't have root access for the system where you are so libraries installation appear to be an impossible task. </div>
<div>
A worse scenario is the one where you <i>have </i>root access and you install the libraries directly in the system.</div>
<div>
The worst case scenario is the one where you're installing things in the system, the system die and someone behind you start hitting you with a club. No, the problem is not the one with the club, the problem is you. The club is the solution.</div>
<div>
<br /></div>
<div>
Never do installations at system level. System level is just for... the system, the libraries installed that are the libraries need by your OS, not the libraries you need for your site. In many years of developement and deployment people found many ways to do things better.</div>
<div>
<br /></div>
<div>
The <a href="http://perlmaven.com/getting-started-with-perl-dancer-on-digital-ocean">article</a> I linked last time, for this task, uses <a href="http://perlbrew.pl/">perlbrew</a>, one of the best practices for that. Perlbrew manages not only libraries, but also perl version, so it can also be used to ensure that the bizarre incompatibilty between 5.16.0 and the cutting edge 5.18.0 is not an issue because you will configure on your machine just the version that <i>works.</i></div>
<div>
<br /></div>
<div>
But <i>timtowtdi </i>so in this article I'll speak about probably the oldest practice about managing libraries, the oldest but still useful, clean and sharp: <b>local::lib.</b></div>
<div>
<b><br /></b></div>
<div>
local::lib is a library that you have to install at system level:</div>
<div>
<br /></div>
<div>
<span style="font-family: Courier New, Courier, monospace;">(as root) cpan -i local::lib</span></div>
<div>
<br /></div>
<div>
after that you'll have the power of playing with perl libraries just moving directories. Remember the directory where we decided to place our site, /var/www/com/example/my/?</div>
<div>
Create under this directory a directory <b>env</b> and then a file named <b>perl_sandbox</b> with these lines:</div>
<div>
<blockquote class="tr_bq">
<span style="font-family: Courier New, Courier, monospace;">libdir=/var/www/com/example/my/env<br />export PS1='\[\e[1;35m\]\u@\h:\w\$\[\e[0m\] '<br />eval $(perl -I$libdir -Mlocal::lib=$libdir)</span></blockquote>
</div>
<div>
Now source the file:</div>
<div>
<br /></div>
<div>
<span style="font-family: Courier New, Courier, monospace;">source perl_sandbox</span></div>
<div>
<span style="font-family: Courier New, Courier, monospace;"><br /></span></div>
<div>
<span style="font-family: inherit;">This way your shell will become pink (the export PS1 line) and all the operations you'll do about perl libraries will have effect just on the env directory. However, with the perl_sandbox active, every perl command you'll use will see the libraries in the env directory.</span></div>
<div>
<span style="font-family: inherit;"><br /></span></div>
<div>
<span style="font-family: inherit;">Just a last tip: remember to install cpanm</span></div>
<div>
<span style="font-family: inherit;"><br /></span></div>
<div>
<span style="font-family: inherit;">cpan -i App::cpanminus</span></div>
<div>
<span style="font-family: inherit;"><br /></span></div>
<div>
<span style="font-family: inherit;">and use that for installations, with --notest option. Life is too short to let cpan to check all the repository every time you need an environment.</span><br />
<span style="font-family: inherit;"><br /></span>
<br />
<h1>
<span style="font-family: inherit;">Up to the plack</span></h1>
</div>
<div>
<span style="font-family: inherit;"><a href="http://plackperl.org/">Plack</a> is a server used to run PSGI applications. PSGI is a interface that we can use to communicate with the webserver that will bring our site on the World Wide Web, so Plack is something we really need to make things work.</span></div>
<div>
<span style="font-family: inherit;"><br /></span></div>
<div>
<span style="font-family: inherit;">Talking about this issue, working with Dancer makes thing really easy because the standard bin/app.pl script that run your webapp can be used as is as a PSGI startup file, as the <a href="http://search.cpan.org/~sukria/Dancer2-0.01/lib/Dancer2/Deployment.pod">Dancer2 Deployment page</a> says.</span></div>
<div>
<span style="font-family: inherit;"><br /></span></div>
<div>
bin/app.pl script must run under a perl web server supporting PSGI. My favourite for this is starman (yes, I like David Bowie, but it's not just for that).</div>
<div>
Copy&Paste from Dancer2 Deployment page how to run plackup and make your site works, however, is not enough for something that will need maintenance in the future.</div>
<div>
<br /></div>
<div>
The last piece of the puzzle is <a href="http://search.cpan.org/~kazuho/Server-Starter-0.09/start_server">Server::Starter</a>, a perl module that provide you the start_server script that will change you plackup server in a daemon (Argh! WItchcraft!), making easy for you stop/start procedures and monitoring.</div>
<div>
After installing that module and after creating a /tmp directory under our site directory, you can try THIS copy&paste:</div>
<div>
<br /></div>
<div>
<blockquote class="tr_bq">
<span style="font-family: Courier New, Courier, monospace;">WORKINGDIR=/site/directory</span><br />
<span style="font-family: Courier New, Courier, monospace;">PROJECT=/where/bin/directory/is</span></blockquote>
<blockquote class="tr_bq">
<span style="font-family: Courier New, Courier, monospace;">source perl_sandbox #as seen in the previous paragraph </span></blockquote>
<span style="font-family: Courier New, Courier, monospace;"> cd $PROJECT</span><br />
<blockquote class="tr_bq">
<span style="font-family: Courier New, Courier, monospace;">start_server \</span><br />
<span style="font-family: Courier New, Courier, monospace;">--pid-file=$WORKINGDIR/tmp/starman.pid \</span><br />
<span style="font-family: Courier New, Courier, monospace;">--status-file=$WORKINGDIR/tmp/starman.status \</span><br />
<span style="font-family: Courier New, Courier, monospace;">-- \</span><br />
<span style="font-family: Courier New, Courier, monospace;">plackup -E ec2 -s Starman --workers=2 -l $WORKINGDIR/tmp/plack.sock -a bin/app.pl & </span></blockquote>
</div>
<div>
as your start_server script.</div>
<div>
And this as last command:</div>
<div>
<br /></div>
<div>
<blockquote class="tr_bq">
<span style="font-family: Courier New, Courier, monospace;">start_server \</span><br />
<span style="font-family: Courier New, Courier, monospace;">--pid-file=$WORKINGDIR/tmp/starman.pid \</span><br />
<span style="font-family: Courier New, Courier, monospace;">--status-file=$WORKINGDIR/tmp/starman.status \</span><br />
<span style="font-family: Courier New, Courier, monospace;">--restart</span></blockquote>
</div>
<div>
<br /></div>
<div>
For restart.</div>
<div>
<br /></div>
<div>
For the <i>timtowtdi </i>section, take a look at <a href="http://search.cpan.org/~symkat/Daemon-Control-0.001004/lib/Daemon/Control.pm">Daemon::Control</a> for an alternative implementation of the daemon. For a PSGI webserver general purpouse, one of the most used technologies of these days is <a href="http://uwsgi-docs.readthedocs.org/en/latest/index.html">uWSGI</a>.<br />
<br />
<h1>
Gentlemen, start your NGINX</h1>
Last step is the easiest one. NGINX is just a proxy from the internet to your plackup structure. NGINX and Plackup will communicate using the plack socket that we configured in the start script: /my/site/dir/tmp/plack.sock. Obviously we're talking about an environment where Plack and uWSGI are on the same machine, otherwise you'll have to sail for the TCP/IP, as everything on the network.<br />
Let's see nginx configuration:</div>
<div>
<br />
<br />
<span style="font-family: Courier New, Courier, monospace;">upstream siteplack {</span><br />
<span style="font-family: Courier New, Courier, monospace;"> server unix:/your/site/directory/tmp/plack.sock;</span><br />
<span style="font-family: Courier New, Courier, monospace;">}</span><br />
<div>
<span style="font-family: Courier New, Courier, monospace;"><br /></span></div>
</div>
<div>
<br />
<span style="font-family: Courier New, Courier, monospace;">server {</span><br />
<span style="font-family: Courier New, Courier, monospace;"> server_name www.yoursite.com;</span><br />
<span style="font-family: Courier New, Courier, monospace;"><br /></span>
<span style="font-family: Courier New, Courier, monospace;"> access_log /your/site/directory/logs/www.site.it_access.log;</span><br />
<span style="font-family: Courier New, Courier, monospace;"> error_log /your/site/directory/logs/www.site.it_error.log;</span><br />
<span style="font-family: Courier New, Courier, monospace;"><br /></span>
<span style="font-family: Courier New, Courier, monospace;"> root /your/site/directory/project/src/public;</span><br />
<span style="font-family: Courier New, Courier, monospace;"><br /></span>
<span style="font-family: Courier New, Courier, monospace;"> location / {</span><br />
<span style="font-family: Courier New, Courier, monospace;"> try_files $uri $uri @proxy;</span><br />
<span style="font-family: Courier New, Courier, monospace;"> access_log off;</span><br />
<span style="font-family: Courier New, Courier, monospace;"> expires max;</span><br />
<span style="font-family: Courier New, Courier, monospace;"> }</span><br />
<span style="font-family: Courier New, Courier, monospace;"><br /></span>
<span style="font-family: Courier New, Courier, monospace;"> location @proxy {</span><br />
<span style="font-family: Courier New, Courier, monospace;"> proxy_set_header Host $http_host;</span><br />
<span style="font-family: Courier New, Courier, monospace;"> proxy_set_header X-Forwarded-Host $host;</span><br />
<span style="font-family: Courier New, Courier, monospace;"> proxy_set_header X-Real-IP $remote_addr;</span><br />
<span style="font-family: Courier New, Courier, monospace;"> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;</span><br />
<span style="font-family: Courier New, Courier, monospace;"> proxy_pass http://siteplack;</span><br />
<span style="font-family: Courier New, Courier, monospace;"> }</span><br />
<span style="font-family: Courier New, Courier, monospace;">}</span><br />
<div>
<br /></div>
<div>
Few things to say. The public directory of the Dancer2 project should be server directly, because DancerApp has nothing to do with static things like css and javascripts. All the others things are just to copy and paste.</div>
</div>
<div>
<br /></div>
<div>
Restarting NGINX, praying all your gods, if all you did was did well your site will rise.<br />
If not probably it will be my fault writing something wrong in here, but I'll be too far from you to be blamed. Just solve your problems and tell me how to fix the article. Comments are there for this reason.</div>
<div>
<span style="font-family: inherit;"><br /></span></div>
Cymonhttp://www.blogger.com/profile/12929196519388090491noreply@blogger.com0tag:blogger.com,1999:blog-7216284694978513305.post-73976891165962991052013-11-16T12:08:00.001+01:002013-11-16T12:08:30.750+01:00Ballroom blitz (1)I read <a href="http://perlmaven.com/getting-started-with-perl-dancer-on-digital-ocean">this interesting article</a> about Dancer2 deployment. I have a lot to learn about Dancer2 deployment so I thought seriously about apply this practice to my sites. However, working on it, I didn't feel so confortable with the techniques applied there, probably because of my habist more than other reasons.<br />
So, at the end, I came to a different solution and I want to describe it here, to clarify it in my head and to demostrate, once more, that <i>timtowtdi.</i><br />
I will skip the part about the provider subscription, I want to focus just on the technical issues and I don't want to talk about a specific environment. Let us think just about you having a server, anywhere you want, and the Power of Root is in your hands.<br />
<br />
<h3>
Who's the man?</h3>
<b><br /></b>
When you're young and stupid you can think that root is enough, because root is powerful, shiny, charming and has a silver armour with gold drawings on it. Uncle Ben died to teach you that with great power comes great responsibility and you're still so stupid to use root and just root, also for pron watching!<br />
<br />
Then you grow up and you know that there're three type of users:<br />
<br />
<ul>
<li>root: the boss. Period. You don't annoy the boss with stupid deployment issues.</li>
<li>human users: they have to log in on your machine and do dirty things. They need a little, walled garden (some guards on the wall, too)</li>
<li>application users: they're on the machine just to work. They're strictly linked to the processes they run.</li>
</ul>
<div>
So, you need to start your app deployment and you have to choose a user that will do it. For this issue, after years chasing not-so-writable directories and evoking the sacred chmod sevensevenseven, I chose the easy way: do all using the nginx application user (nginx or www-data, usually). It's not perfect, it's not the cleanest way, it's not the most secure, but it's tidy enough and give you a lot of space to manage things.</div>
<div>
From now on, consider yourself logged as <b>nginx</b>. It's home directory will be <b>/var/www</b>.</div>
<div>
<br /></div>
<h3>
Where's the man?</h3>
<div>
Just a small paragraph about directories. If you don't have a strict discipline your system will become a mess. It's its destiny, it's nature. Entropy is part of every job in the universe.</div>
<div>
My favourite idea about how to organize different sites on the same machine is to use reverse domain as subdirectories.</div>
<div>
So, mylittlepony.evilgenius.com will go under <b>/var/www/com/evilgenius/mylittlepony </b>and fluffy.bunny.org will be <b>/var/www/org/bunny/fluffy.</b></div>
<div>
This way it will be easy to find the site you're looking for and directory names will never be too long. The policy for domain names is also one of the strictest of the computer science, so you'll never have to manage UTF-256 characters or things like that.<br />
<br />
<br />
<h3>
Beam me up Scotty!</h3>
<div>
This article will speak also about the <i>obvious.</i> </div>
<div>
The easiest way to put the code of your webapp on your server is through some versioning system like git. You just have to pick up an account on <a href="http://www.github.com/">github</a> or <a href="https://bitbucket.org/">bitbucket</a> and then, after finishing the development, push all you did on a repository. Then, on your webserver, you just have to clone the project and then maintaining that pulling every update you push.</div>
<div>
There's a part of me that don't like working this way. The cleanest and most clever way to deploy a software is packing it someway and then installing it on the server. Packing and installing must be done through a clean, sharp and smart suite of scripts tailored on the software you are managing.</div>
<div>
This is the old school procedure and as a lot of old school procedure it's still good, but I have to admit that git is easier and perfect for lazy people.</div>
<div>
But! Remember! :</div>
<div>
<ul>
<li>Think about if you need a private repository. It could be that someone doesn't want that the code of the site is exposed to everyone with a google bar. I know, I know, open is better, open is good, open i what tender kittens wants, but sometimes it's not what YOU want.</li>
<li>gitignore is the <i>most important file </i>of your repository. Design it thinking that nothing about your server environment should be in the git repository. For two simple reasons. One: if you have on git something related to an environment it could change the environment configuration on deploy just because on your developement server something is different and making a git pull a disaster. Two: you don't want your production database password written on a public github repository... and probably you don't want it also on a private one, if you don't know all the contributors to your project.</li>
<li>Take a branch as the production branch and never touch it before deploy time. When you have to develope a feature branch from production and develope there. On deploy, merge your new branch with production and push. You have to trust in production branch. Every time you go on your server and do "git pull origin production" you have to know exactly what will happen. Nothing, in the most cases, the deploy of something you planned, on the happy release date.<br />Again, if you don't trust all your contributors, there're many ways to prohibit people to push on production. Enforce them. Your contributors are not always malicious, but they're still users. They do users' things. Users things are often stupid things. Stop them.</li>
</ul>
</div>
</div>
This project about Dancer2 deployment will be quite long. I'm putting in it a lot of random things from my experience. So I stop it now and I put a number on the title. We'll be back, i hope soon.<br />
<br />
<h2>
<br /></h2>
<br />Cymonhttp://www.blogger.com/profile/12929196519388090491noreply@blogger.com0tag:blogger.com,1999:blog-7216284694978513305.post-18860222671374461802013-09-29T15:40:00.000+02:002013-09-29T15:40:22.927+02:00404 Ghost workaroundA little recap:<br />
<br />
<a href="http://perlishscrewdriver.blogspot.it/2013/06/the-dawn-of-combining-robots.html">Here</a> I stated a problem about phantom 404 and a (wrong) solution to it.<br />
<a href="http://perlishscrewdriver.blogspot.it/2013/09/in-previous-episodes-of-battlestar.html">Here</a> I confessed I was working on the issue.<br />
<a href="https://github.com/PerlDancer/Dancer2/pull/464">Here</a> It's the work I'm doing with a long and boring description of the problem that I'll not repeat in this blog.<br />
<br />
...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.<br />
<br />
Oh yes, the problem! Let me say it with few words:<br />
You have a plugin that modify the request path in a before hook. You want that, when the user write (for example) <b>/prefix/good/path,</b> your plugin change it to <b>/good/path</b>. Obviously the code that will answer to this will be:<br />
<br />
<b>get '/good/path' => sub {...}</b><br />
<b><br /></b>
You don't define anything about <b>/prefix/good/path</b> because the plugin will always change it, so you'll never need to answer with it.<br />
This works! I can swear it calling Wotan on my side. But when you try to test it with <b>dzil test</b> the test you wrote fails.<br />
<br />
Long explanation for why this happen, as I said, is <a href="https://github.com/PerlDancer/Dancer2/pull/464">here</a>. Little workaround you can use to stop this happening is adding a <b>public </b>directory under the <b>t </b>with just a dummy file. This way fix the problem and make you test suit running flawless!<br />
<br />
<br />Cymonhttp://www.blogger.com/profile/12929196519388090491noreply@blogger.com0tag:blogger.com,1999:blog-7216284694978513305.post-72884000214750731362013-09-09T19:38:00.000+02:002013-09-09T19:38:29.795+02:00In 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.<br />
<br />
First important news, for me, is that <b>use Dancer2 :sytanx </b>is no more from 0.07. I was a little puzzled about it because, as I wrote <a href="http://perlishscrewdriver.blogspot.it/2013/06/the-dawn-of-combining-robots.html">here</a> the pure <b>use Dancer2</b> is a powerful spell that do many things and sometimes it could be more than what you want.<br />
I asked for enlightement (i'm still a barbarian, you know) and Sawyer X himself gave me <a href="http://lists.preshweb.co.uk/pipermail/dancer-users/2013-September/003371.html">this answer</a> about it.<br />
So, using <b>use Dancer2 </b>also when you're not creating an app is good.<br />
All I said about apps and scope is still valid, so we can say farewell to <b>use Dancer2 :syntax </b>(a legacy of Dancer) with no regret.<br />
<br />
Second question I'm working about is nasty like a leprechaun with no sense of humor that hate Harry Potter. In <a href="http://perlishscrewdriver.blogspot.it/2013/06/dancer2test-undiscovered-countries.html">this article</a> 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!<br />
<br />
Stay tuned!Cymonhttp://www.blogger.com/profile/12929196519388090491noreply@blogger.com0tag:blogger.com,1999:blog-7216284694978513305.post-77916571724211301712013-08-10T12:07:00.001+02:002013-08-10T12:07:31.247+02:00The accentMy name is Simone Far<b>é</b> and I'm italian. I think you can understand how important is for me UTF-8 and character set management.<br />
<br />
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.<br />
<br />
The first point is the easiest, the most powerful and it comes for free.<br />
It's just the <b>charset: "UTF-8" </b>configuration key in the config.yml. Spend a moment reading the <a href="http://search.cpan.org/~sukria/Dancer2-0.03/lib/Dancer2/Config.pod#charset_(string)">documentation page</a> 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.<br />
<br />
The second point is about your template engine, if you're using template toolkit add:<br />
<br />
<b>template: "template_toolkit"</b><br />
<br />
<b>engines:</b><br />
<b> template_toolkit:</b><br />
<b> ENCODING: utf8</b><br />
<b><br /></b>
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.<br />
<br />
Obviously the third point is very important, very insidious and very well hidden in the documentation, because there's no gain without pain.<br />
<br />
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?<br />
<br />
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?<br />
In the database configuration:<br />
<br />
<br />
options:<br />
RaiseError: 1<br />
PrintError: 1<br />
<b>mysql_enable_utf8: 1</b><br />
<br />
<br />
Just that. But remember it or you'll suffer. Suffering is good, but suffering forever is unfair.<br />
Cymonhttp://www.blogger.com/profile/12929196519388090491noreply@blogger.com0tag:blogger.com,1999:blog-7216284694978513305.post-23472103049113316982013-08-04T13:20:00.002+02:002013-08-04T13:20:48.662+02:00Initiation riteWe're here to celebrate!<br />
<br />
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.<br />
<br />
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.<br />
<br />
For me, it's the <a href="https://github.com/PerlDancer/Dancer2/pull/344">pull request</a> Dancer2 team accepted today. It's something about sessions and forward that I found while developing the <a href="https://github.com/cym0n/Dancer2-Plugin-Multilang">Dancer2::Plugin::Multilang</a>. It's just a small thing, nothing revolutionary, but seeing it merged in the Big Project gives me a good feeling.<br />
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.<br />
<br />
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!<br />
<br />
<br />Cymonhttp://www.blogger.com/profile/12929196519388090491noreply@blogger.com0tag:blogger.com,1999:blog-7216284694978513305.post-36406728511114003982013-07-28T14:19:00.001+02:002013-07-28T14:19:29.537+02:00The dumb code festival - 4Authentication and authorization is something every framework must manage. Because they're boring and frameworks exist to manage boring things.<br />
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.<br />
<br />
The "auth" thing is a pattern well known in the web world and you can find many solutions for it, looking for "<b>Dancer::Plugin::Auth</b>" you'll find a lot of stuff. Unfortunately Dancer2 is still a young project so the only tool we have is the <a href="http://search.cpan.org/~dagolden/Dancer2-Plugin-Auth-Tiny-0.003/">Dancer2::Plugin::Auth::Tiny</a> from Golden.<br />
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 <a href="http://perlishscrewdriver.blogspot.it/2013/06/doctor-dancer2apps.html">Dancer2 App scope</a>.<br />
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.<br />
<br />
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.<br />
<br />
session 'user' => $the_username;<br />
<br />
This is what our hook will check:<br />
<br />
<br />
<script src="https://gist.github.com/cym0n/6098353.js"></script>
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.<br />
<br />
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.Cymonhttp://www.blogger.com/profile/12929196519388090491noreply@blogger.com0