2013Q2 GP: YACT - Yet Another Conference Tool
Sat, 04-May-2013 by
Alberto Simões
edit post
<![CDATA[
<dl>
<dt id="Name">Name:</dt>
<dd>
<p>Torsten Raudssus (Getty)</p>
</dd>
<dt id="Amount-Requested">Amount Requested:</dt>
<dd>
<p>$3000</p>
</dd>
</dl>
<h2 id="Synopsis">Synopsis</h2>
<p>The current Act software and their instances are an often discussed topic in the world of Perl. The migrating of those instances, and the move forward to more modern Perl solutions in the system are often discussed. Last year we were able to address and start a concept at the Quack and Hack Europe 2012, we called it YACT - Yet Another Conference Toolkit, which targets to be a "in place" replacement for the existing Act software. It accesses the same database, and (should) be usable with the same templates. It also implements the idea of using git (and so GitHub) to maintain the Act setup for a conference.</p>
<p>YACT will not replace the Act name, Act will stay as the name for the complete project/platform/service, YACT is just a specific implementation state.</p>
<p>Additionally YACT is supposed to be also a management for Perl Monger groups and so should animate people to startup a Perl Monger group "instantly" and get all the nice shiny fuzz to manage it. This also means that we need a more flexible theme based style for this. A better support for localization is also a very important point here.</p>
<p>The current state is a very good database setup already, but the web interface setup is not really started and no administrative tools are added yet. There is still lots of work todo. (Current state: <a>"/github.com/perl-act/yact" in https:</a>)</p>
<h2 id="Benefits-to-the-Perl-Community">Benefits to the Perl Community</h2>
<p>The most important and most used Act instance is managed since many years, nearly alone by Maddingue (Sébastien Aperghis-Tramoni) and the French Perl Mongers, but is still suffering from the problem of integrating help easily. Alone the missing scalability disallows other system infrastructure to support the Act in a productive manner (which many many companies would I bet). We would open a new door to relieve those hard working Perl people from their stress level.</p>
<p>The new features will allow to make a more decent and more perfect conference experience. Especially with the experience of the French Perl Mongers in making events, we planned on several very important features which would give help for all event organizers in the future, like checklists or features for managing common processes inside the act itself (like setting up extra pages for extra situation like a special dinner with extra reserveration informations).</p>
<p>Also a very important point is making the experience for the user more interesting, like the idea of integrating Booking.com a bit more to make it very easy to manage the accommodation. I hope there that we will find some love from Booking.com to get all the informations we need for this :).</p>
<h2 id="Deliverables">Deliverables</h2>
<pre><code> * DBIx::Class schema of the Act DB
* Dancer implementation of the web interface to the Act DB
* Simple CLI application for administration of the Act instance
* Testsuite for YACT::DB, YACT::Web and YACT::App
* Making git the conference holding instead of SVN
* Integrating template themes
* Better integration of localization
* "Making a conference" checklist feature
* Support for custom hostnames and conference independent landing pages
* Making a scalable DB setup (read only at least)</code></pre>
<h2 id="Project-Details">Project Details</h2>
<p>The implementation itself is pretty straight forward. The existing urls and endpoints will be translated over to Dancer step by step. On those transfer the required functions are added to the result classes on the DBIx::Class schema. The same goes for the development of the application. This way we have a clean and straight forward model, we also can bind to XMPP, IRC, and all other protocols to allow more interesting accessing features (IRC bot in your conference channel?).</p>
<p>The administrative tools will be made with Moo and as primitive as possible. In general we avoid to use bigger systems (so far we have no Moose in play, so why bring it in). The template engine will be staying to Template::Toolkit, but we might implement a switch for this to other templates (very optional).</p>
<p>For scalability I would consider some database experts to find a very sane simple way to get read only sharing of the database to outposts. With some simple tricks we will then drive write access to the specific central instance. A serious spreaded backup could be added here, too.</p>
<p>The templates will be heading towards bootstrap, as this is one of the most accepted concepts on this and offers by itself already themes (which will not replace that we offer totally different "layout" themes for this).</p>
<p>For the localization I will be using my own Locale::Simple, which is not much more than a wrapper around gettext (Oh please god, someone make a grant for fixing the xs implementation). This allows us even to make out of code from the DuckDuckGo Community Platform, where this is open source, to make an own translation platform (another grant?).</p>
<p>The optional migration process should be "perfect" in the way to try to link the accounts and so allow migration of all the conference informations of a person.</p>
<h2 id="Inch-stones">Inch-stones</h2>
<p>The project is really a bit bigger, then one grant might cover. Those are the Inch-Stones I see, but depending on how much work those steps cost, additional grants for those sub tasks could be made (and also given out to other people)</p>
<pre><code> * Finish up the existing YACT source code to deliver all the base features
required for most acts (as reference I would take a German Perl
Workshop).
* Integrating modern template themes. For this I already have
aknowledgement
of several organizations (shadow.cat) and private persons (Marek Suppa,
Valentin Schmid) who want to supply results here.
* Making administration tools for setting up acts and managing them most
easy
* Providing a cross-conference, permanent user profile people can point to
from their other profiles (MetaCPAN, LinkedIn, etc). Probably with
nickname
in the URL as well, instead of meaningless number, something like:
http://act.yapc.eu/profile/getty
* Adding scalability features to allow it to run "readable" from several
points in the world, a central write point would be still fine enough for
the current situation (I hope YAPC::Asia agrees).</code></pre>
<p>Definitly outside this grant are those points, even tho I think there could happening by the community automatically, if the points before are reached.</p>
<pre><code> * Migrating over all features not so common in use (API, Payment, ...)
* Migrating all non-French Perl Mongers Acts into the French Perl Mongers
Act
* Adding new modern features (Twitter, Facebook, Flickr, Hotels, ...)</code></pre>
<h2 id="Project-Schedule">Project Schedule</h2>
<p>I want to start as soon as possible with the project, as my personal schedule allows me to take the time. I target with help of the community to finish the first Inch-stone in 3 weeks, seeing the already existing state. The additional assets like templates and the involvement into the existing administration of the main act instances might bend the process to a longer time, indepedent of the code evolvement.</p>
<p>So far the community and the French Perl Mongers are very supportive, which will help accomplish the target soon. Sébastien Aperghis-Tramoni already has a clear process plan for the migration process.</p>
<h2 id="Completeness-Criteria">Completeness Criteria</h2>
<p>There is a conference and a Perl Monger group running YACT which access the existing Act DB parallel to the other Act instance on the French Perl Monger hosting.</p>
<h2 id="Bio">Bio</h2>
<p>I'm doing Perl since now around 4 years and worked over 15 years as system developer and technical leader for several agencies in PHP before that. With Perl I started to get a complete new experience of how you can integrate yourself into the community. I always loved this aspect of Perl most, and with my seat in the Marketing Committee I try to bring this experience also to the outer world. The Act system is the very important key here, because the Perl community delivers the best community driven conferences and we should concentrate on those key features of our community. I currently work mostly as contractor for DuckDuckGo which allowed me to visit many conferences in the last year, and additionally allowed me to organize 2 events on my own, the 2 Quack and Hacks, one in US, one in France together with the French Perl Mongers.</p>
]]>
Category:
(none)
Comments (16)
Maybe I missed this in the proposal, but is Sebastien on board with your plan?
Can you call it something else? Anything else? "Yet Another Whatever" is anti-inspiring. How can anyone get interested in a project that is "Yet Another Something"?
Yeah, you just it, in the end, I say something about it:
"So far the community and the French Perl Mongers are very supportive, which will help accomplish the target soon. Sébastien Aperghis-Tramoni already has a clear process plan for the migration process."
I have a deep contact with the current act crew on this topic, they were in the room when YACT was first pushed :).
Book really wants to make his Act2 vision, which I really like to support, but this is not helping the current situation, the YACT is really just a workaround, a quick solution for a daily problem, so the name is more like meant to be unattractive :). In general I agree, but I hope that when YACT is running, and we have a stable situation there, that then the prototyping for Act2 will start, and people should get really attracted for this product of the Act family. Of course, if you have a genius nice name that is also "leaning" towards Act, then I'm open :) but I must say I find YACT just fine, especially cause it hits the situation, it is "Yet anoter Act", nothing more :) (just hopefully a final one which migrates all the other Act forks).
I'm actually in favor of this grant, but I'd still like to see Sebastien (or other people who've worked on / maintained Act for a long time) comment with an endorsement. Sorry to be such a pain. :)
--Steffen
In this case they all have read and approved the grant text before it was send to TPF, all is fine :-). I can tell them now to comment here just for you ;) hehe.
Based on the comments above, it sounds like this version is being written with the intention of throwing it away when Act2 happens - how is this more advantageous to the community than the current version? Versions (you mention "all the other Act forks" but I don't know how many there are or how this helps)
Based on the proposal and comments, I don't see how this is a benefit to the community; I get that a rewrite and a cleansing of internals is work that often needs a grant to get through - but if you're planning on throwing this version out, then I don't see the point.
Can you help me understand the problem this grant is trying to solve?
The people using Act and working with Act, suffer big problems about the current situation. Act2 is far far away, there is nothing started, and even if its started, it would require some test runs to assure its stability in the use cases. This is all a long time.... And so far we have 0 lines of code, the project is not even started.
So far we have at least 3 forks, YAPC:NA, YAPC::Asia and YAPC::Brazil, which should get integrated. Those are a HUGE part of the Perl community, which is just splitted up. The missing features are big, and its very hard, nearly impossible to add them to the structure right now. Also setting up your own Act to work on it, is the pain, try it, doesn't make fun :) (and has no test data). We could actually just go and fix all those problems in the existing code base, but we calculated that for sure this is definitly more time and will not make it easier for the next people working on it. Also is Act not yet made for managing usergroups, those are totally new features.
I think its really relevant to be part of the Act users/developers to fully understand the benefits of this grant. We suffer on every conference :). Also I think we all want finally a "conference profile page" and we want to give pull requests to make the webpages of the conferences better :).
The #act IRC channel and the Act Mailinglist are good resources to get a better picture of the current situation and the urgent need for such a liftup. YAPC::NA tried to make it happen, a remake of Act with Plack, but it seemed that this fork has totally stalled (and didnt included anything to make the development of features more easy).
P.S.: Act2 will not mean that YACT is gone, YACT still is the base dataset for Act2, so whatever Act2 does it will integrate all the developed features of YACT, and probably most code will be just transferred, the only point here is (and that makes Act2 so expansive in time) that Act2 will be designed to be ONLY an API server which then gets a web application split up on top it. Its a very big plan, and will take lots of time.
Steffen, I confirm that I endorse Getty in this project.
yAct started during Quack & Hack Paris 2012 in december. Getty worked on this with sjn, myself and one or two other people from DDG iirc. I created a test environment on the server to test it with an access to the production database.
@Coke & @Andy, yAct is just a codename for, if you prefer, rewrite current Act, 100% compatible, using current web stack (PSGI) instead of mod_perl1 on which nobody wants to work on (and as a matter of facts, nobody works on it). Then, on this ground, it is hoped to make it easier to install and administrate. The other instances have de facto forked & drifted a bit from the main instance, because they added a couple of features here & there. yAct should be an opportunity to merge everything back.
Also, the plan is to reduce the administration burden that is currently inherent to the main instance. Less admin time, and no more need for root access means more people could be admins. And I would no longer be a SPOF.
In the longer term, what we call Act 2 really is distributed Act. This is needed to address the latency problems, as well as load-balancing and backuping. In the case of YAPC::NA, I guess it's still acceptable because there are a number of cables across the pond, however the latency between Europe and Japan makes it difficult to use for our fellow mongers there. Ask lestrrat about this. They used our instance for YAPC::Asia 2009, suffered from the latency, and preferred to hack a small Plack app to handle their conference. Remember that, in termes of attendees, YAPC::Asia >= YAPC::NA + YAPC::EU. As far as I know, they would enjoy to use Act again, provided it is responsive from their part of the internets. A very reasonable request.
I'd vote for this, if - in the process of rewriting - the folks involved would strive to make yAct as easily installable, configurable, customizable and stylable with as little Perl knowledge as possible.
The best approach to marketing Perl imho is providing useful and usable applications. And yAct apparently has much potential there.
Out of the experience with the DuckDuckGo Community Platform, i find it essential to make it "one click" away to patch and test your changes to the code and the style. Continous integration via TravisCI and easy access via pull requests on Github are another part of the easy access.
This definitely gets my support. I'm thinking of putting on a conference here in San Francisco, so I'd love to have better tools for that.
I especially like the proposed integration with Git (and GitHub). I think that will really help make conference organizing a more collaborative effort.
I'm sure Act 2 will be a beautiful thing, but YACT is good interim evolution that can benefit the community sooner rather than later.
Go Getty!
I'm all for improving ACT, and if the current maintainer is behind this effort then so am I.
This is an excellent plan getty!
I'd vote for a more gradual evolution over throwing away and starting fresh which would mean that this would have a long term benefit.
If this is thrown away for Act2, then we'll still have the lessons learned in implementing the features to inform the next version so it's still worth doing.
idn.
As one of the original authors of Act, I support this proposal.
I very much like the fact that Getty wants to keep the existing database / userbase, as the current Act has been used by more than 120 conferences and events in the past decade. Act is one of the many little things that bind the community together, and Getty does explicitly not want to lose that.
"Act2" is a nebulous thing in a distant future, that I might never get around to simply start. I don't want my pipe dreams to stop Getty from getting things done for the good of the community.
