Grant Proposal: Start ACT - Voyager
Wed, 16-Jul-2014 by
_We have received the following grant application "Start ACT - Voyager". Please leave feedback in the comments field by July 25th, 2014._
# Start ACT - Voyager
Theo van Hoesel
- Amount Requested:
$ 1.000 DBIx::Class
$ 2.000 Dancer(2) implementation
$ 1.000 REST api
$ 2.000 Theme Based templates
$ 6.000 TOTAL
The Perl Community is a social community that gathers at several places around the world during Conferences and WorkShops and Hackathons. Since more than a decade ACT has been used to provide organisers of these events a central system for registration, payments, talk-submits and scheduling.
However, development has been stalled for a long time and many good initiatives has been surfaced and not yet materialised over the last years.
Start ACT, Voyager, will be a large project that will lay down the fundaments that allow for growth and expansion, based on top of the deep settled original ACT implementation.
Many of the ideas of 'BooK' about ACT2 and the work done by 'Getty' for YACT are inspirational for the roadmap to a new platform for the essential Conference Toolkit.
## Benefits to the Perl Community
\* we suck at marketing \* is a phrase not to be proud of and as a result of that mind set, the main hub for Perl events is not catching up with courante user experience and not providing the means for front-end developers to change anything about it. Gradually, this will be a 'voyage' to upgrade the current ACT to modern standards so new features can be build upon it.
One thing it will provide is a 'Next Generation' REST api. This will allow others to write their own web-applications that will lift the load from the current ACT server tremendously when done by experienced front-enders. Clients are encouraged to cache their retrieved data locally and most of the mobile apps do rely on the presence of such api's.
Eventually in 'the Final Frontier' there will be a complete working theme-based template that allows for responsive web design, including user-profiles and, not less important, a web-base backend to manage 'instances' of conferences. With a few clicks organisers will be able to have a good looking website based on some default themes and layouts. For those that do not want these predefined templates, one can always setup their own server and make calls to the REST-api.
Too many feature-requests and ideas do exist but Start Act - Voyager is merely a road map and along that road the following are essential deliverables:
### DBIx::Class Schema of the current ACT Database
A working version of ACT, build with the previously written Schema, which is a replacement of the ACT Core templates and modules.
### REST api (the Next Generation)
Mostly responding to GET methods and a few POST and PUTsd
### Theme-based Templates (the Final Frontier)
Easy to setup, possibly through a backend to ACT
## Project Details
Some of the great ideas will be borrowed from the previous Grant for YACT. However it will not have all the nice bells and whistles that make this project insane big. As said before, it is a platform for growth end extensability and others can build more nice features into it. An ACT Hackathon will be a wonderful opportunity to extend with new features.
One email from 'BooK' contains a whole list of inspiring ideas on what the supposed ACT2 (api based) should be providing and next is a quote from his email:
"Working on an API makes it easier to focus on the data (which is the value
of Act) and to leave working on other things for later (the web framework,
the conference management tools, etc). I think Act2 should come up with a
web application (with better support for conference-specific templates),
but should not be tied to it (so that others can do something else with
it, like a smartphone app)."
It would be too much to write down all the details, but that quote shows quite clearly which direction StartAct - Voyager should be going.
Since this is quite a huge project, it is hard to say which tiny steps would be needed to get to the end. The milestones are mostly the deliverables as mentioned before.
## Project Schedule
Starting on this project will be possible shortly after YAPC::EU. A nice opportunity to have some more discussions with the people that are currently on the mailinglist and IRC. Since the complexity of the project and the number of resources that needs to be accessible through the REST api as well as all the templates that need to be doen (twice), It might easily last up to a year, working one or two days per week and spending some evenings here and there.
## Completeness Criteria
The project on itself will be completed when it is possible for an organiser to easily create an instance and choose and modify a predefined theme.
However, each of the for mentioned mile-stones and deliverables need to be completed before actually moving on to the next stage
I'm the oldest 'send-a-newbie', entered into the Perl community back in April 2013. Before that my coding was gibberish but since then I met many many people in the community that showed me how Perl can be really a powerful tool.
Things done in Perl are as simple as an automated 'talks-titler' that generates HD-TV quality title pages from the talks-list in ACT (see the NLPW::2014 video's) to more interesting things like building a OOP wrapper around the ugliest Magento XML-RPC interface.
Currently I'm writing a REST api generator that does for DANCER what schemaloader.pl does for DBIx::Class: writing all the routes and HTTP-methods into separate modules for each resource found in the database.
Before writing Perl, I have done quite some Objective-C for iOS applications. And long before that, I used to be self-employed web designer.
I'm also one of the organisers of the NLPW::2014 and 2015 and have great personal interest in having a better user experience with ACT based websites, both enduser as maintainer.
It has been my desire to change the user experience of ACT since I first used the web-site... checking my schedule personal schedule on the first day of YAPC::EU::2013 in Kiev... on an iPhone (WARNING: DO NOT TRY THIS AT HOME)
My random thoughts about this proposal:
- What about the DBIx::Class schema deliverable will be more than just running dbicdump such that it warrants $1000?
- Will it be Dancer1 or Dancer2 based? If Dancer2, why is the 2 in parentheses? It gives the impression (to me at least) that either you're unsure of using Dancer2 or the idea of using Dancer2 was an after thought.
- The description of the REST API leaves something to be desired. If you're going to implement a specific API that someone else has already mostly worked out, mention that, reference the email thread, cut-n-paste the details of the API, et cetera.
- The project details section essentially says "there are too many details". I'd like to see some details rather than just a general feel for the direction of the project. If you're going to be borrowing some ideas from the previous grant, which ones in particular?
- Given your newness to Perl and the size of the endeavor, I'd be more in favor of funding several smaller, focused grants than one "big" one. Especially if you think this project could take on the order of 1 year. That's several TPF grant funding cycles.
- Do you have some modules or other code examples you can link to show things you've already built? You mention some things, but don't link to them.
Without more information, I feel this proposal is weak as-is and I'd be inclined to recommend against funding it.
If this is accepted, and hopefully it will be, I would like to suggest a review of the schema. In particular the way courses are represented. Running the surveys, it is a constant source of frustration to try and get information about the courses and who is attending them. Some have ended up managing courses in other systems, so bring them back to Act would be great.
With the surveys I use an API for the users and talks, and would like to see one for the courses too. Improving the schema and usability of course admin will be a great benefit for me, and hopefully future organisers.
I would also like to see the ability to integrate survey links into the schedule, or talk description pages, or both, and I am happy to work on an API for the YAPC Surveys to enable this.
APIs are definitely the way forward, so we can see more useful ideas being implemented for future conferences.
Re "Inch-stones: Since this is quite a huge project, it is hard to say which tiny steps would be needed to get to the end." - this does not bode well. I'd like to see the work done, but several smaller grants seems like a better and safer approach.
Without more information, yes, I could more or less agree... so, here is more info:
- When I talk about a DBIx::Class Schema, I am not talking about a dump. Iâ€™m talking about a well tested, documented solid fundamental part of the whole project. Something that will keep running against the original database, something that is going to be referred to in the rest of this project and that interested perl developers need to be able to extend with new functionality.
- Concerning the framework of choice, I would prefer to stick to Dancer2 for personal reasons. However, as far as I know from firsthand contact with SawyerX, Dancer2 is not fully production ready (for example, there are still some missing parts of the ecosystem). Had I written down Dancer2 without the parenthesis, I would risk comments here as well. Choosing for Mojolicious could be an option as well and knowing a bit of the history of the previous YACT development, during the process â€˜Gettyâ€™ has decided to change to another framework as well. At this point, it is for me not written in stone that it MUST be Dancer2, if the majority of the Perl community would strongly advice to use another framework, Iâ€™m happily to change the course of my voyage.
- From that same e-mail â€˜BooKâ€™ has sent to the Act-Mialing list, I will quote:
"API is definitely the way to go. This is what I had in mind for Act2. (and by "in mind" I really mean that nothing ever happended outside of my head...)"quote>
There is no description to the REST api. Surely most of it looks quite straightforward if you look to it from the outside, many developers would imagine some resources that need to be queried. However, it goes a long way to have a RESTful ( ... ) api, that is not only providing bits of JSON or XML, but also is discoverable and has relational links to other parts of resources. Thankfully â€˜Daximâ€™ has written a (near) full implementation of HAL which makes it very easy to have nested resources which can be very convenient when building an application on top of REST. Proper documentation of the api is part of the deliverable.
- Although the grant proposal on it self should not be a discussion forum on details, I am quite willing to answer any questions that arise. And not without reason, this Project is being called â€œStart Act - Voyagerâ€, a road map, that leads to some interesting deliverables. I quite happily will open a new IRC channel to discuss implementation details once the grant has been approved (or maybe stick with #act). I would happily borrow â€˜Gettysâ€™ work done so far and build further on the administration part of Act, so we hopefully will no longer have those emails from organisers â€˜Maddingue, would you yada yada yadaâ€™. Sticking with Moo, rather than Moose, sounds like a good plan. But instead of using Bootstrap as a frontend framework, my choice would be Foundation - since itâ€™s build for scalability and expansion, Bootstrap lovers are free to build another layout template
- My newness to Perl is also an advantage, I am no â€˜old dogâ€™ that canâ€™t be learnt â€˜new tricksâ€™, I can luckily jump straight into Modern Perl and modern frameworks and bring freshness to the Perl community. (thank you Ovid for encouraging me in Brussels during the FOSDEM not to be shy amongst the big people of the community). For some it may take quite a while to get around once introduced to the Perl Community, luckily I had a head start thanks to the EPO Send-a-Newbie program. And I feel surrounded by many of the great â€˜mindsâ€™ behind the essential Modern-Perl stuff. I do not think for one moment that this is a project that is done by one single person, but because of being involved in the Perl-community is done with a lot of help from more knowledgeable people.
- A year might seem long, but this is not done as a main source of income as if I had nothing else to do. Working one or two days per week or some evening hours beside my contract jobs is all I can do. I was asked to give a realistic planning, not what I could do if I would do this 24/7. --- However, splitting up in smaller grants (maybe as shown in the top of the proposal) is quite useless and has a risk of being a wast of money. With this proposal you also have my commitment to the task, rather then small incremental steps that are useless without a successor. Itâ€™s a waist of $1.000 if only a proper tested DBIx::Class implementation would be build if noon would continue. Itâ€™s another waist of money if it would be stalded again and again if there would not come a successor on the Dancer implementation (or what platform of choice)
I can understand your request to reveal code... I will see what I can publish.
More details, like Inch-Stone I will try to fill-in in response to Tim Bunce his comment.
Yay! Barbie I am glad you see the benefits of â€˜Start-Act â€” The Next Generationâ€™ apiâ€™s.
I can imagine you would greatly benefit of a tight survey integration into ACT. As you have personally explained the time and effort it takes to setup a survey for the NLPW::2014, I certainly see this as one of the extensions to ACT.
Therefor, the idea of writing a good DBIx::Class Schema is the first step which will of course be something that is for the public, for whoever wants to review it and propose edits to the schema. Together with the RESTful web service it will then be ready for expansion and growth.
I will be looking forward to see the Survey API extension build on top of this project.
Thanks for the "more info" Theo. Though I have to say that it doesn't much change my opinion that several smaller grants would be better.
Concerning the choice of framework ... you seem to be saying you'll use "whatever the community wants". I'd rather see commitment to a framework; any framework. Mainly because, whether you fail or succeed, the framework you chose wouldn't have mattered. If you fail no one will care that you failed with Dancer2 (for instance), and if you succeed, that there's a working, modern conference tool is way more important than the specific framework used to implement it, IMHO.
And here's how I look at the idea of several smaller grants rather than one big one ... From my perspective, you're an unknown quantity. You seem to have some good ideas, but it's not clear how well you can turn those ideas into reality. Given that, it seems like a better idea to fund a small grant so that you can "prove yourself" to the community and get one step closer to the new and improved ACT. That it doesn't go "all the way" is not a waste of money because it's laying the foundation for you or others to build on. But, equally importantly, it doesn't tie up funds that could be used elsewhere. While the money isn't actually spent until the grant is completed, it is taken out of circulation such that others can not take advantage of it. And I'd much rather reserve one or two thousand for a few months, than six thousand for a year (or more).
Also ... if "small incremental steps" are "useless without a successor", then why would you not continue to apply for grant funding to implement the successors? Would the hurdle of applying for subsequent grant funding be too great?
Anyway ... that's my two cents.
I agree with Tim here in that the goal of the propsal is great, but the lack of clear inchstones are a bit worrisome.
If you're worried that micro-grants would be a waste, I personally would like to see a better thought-out schedule of when features would be ready, so that the community can check on the progress in a shorter interval, instead of waiting around for a year to see if the whole thing is done or not
As the treasurer, I do my best to remain impartial and to also not attempt to sway the decision of the grants committee. So, this is me speaking purely as a conference organizer:
Iâ€™ve been the lead organizer for 6 Perl conferences, including one YAPC::NA. Iâ€™ve also assisted with every North American perl conference that has used TPF as their payment gateway in the past 4 years. So, I have quite a bit of experience with ACT. And, while I do think that ACT needs revisions, I have concerns with the ACT - Voyager grant. In short, it seeks to place an API over top of a bad core so that organizers would have the opportunity to compensate for ACTâ€™s inadequacies themselves. I donâ€™t think this is the right approach. Once we have an external API to support, fixing the bad parts of ACT is going to be much more difficult. We need to fix the core first, and then worry about the API.
Dan, it might not have been totally clear in the description, but the moment I was going to rebuild ACT inside Dancer2, it would also imply that the more difficult parts like the payment gateway would be redone as well. Once done that, the 'Next Generation' api can be build with the Modern Engines underneath., hope that helps
Okay, lets give it a try to make some 'yard stones':
- Setting Up a ACT server
- Check with DBIx::Class Core developers
- Edit names and relations
- Write tests and run tests
- Add smart shortcuts helpers andÂ Class Methods
- Write more tests
- Write Documentation
- Modify Original ACT Core so it will connect through DBIx::Class
- move mod_perl handlers to Dancer2 routes
- have Dancer2 routes fill in the original templates
- define all useful resource
- write the POST, GET, PUT and DELETE methods
- test, test and test
- write documentation
Theme Based Templates
- Find a proper frontend framework (Foundation)
- Define Layouts
- Define Pages
- Redo the entire ACT with new templates and themes
- Decide which SASS variable will be editable
- Run several default Themes and Colorschemes
- Write a admin/theme-selector
I guess you do not want to be bothered with the rest of the details on how to yada yada yada. I will set course and will het to 'the Final Frontier'. And during this 'Voyage' things will change course here and there. My reports on the progress will keep the community informed. But beside that, I truly hope that some of the people of the ACT Mailing-list are willing to give feedback and I am already looking forward to the ACT-Hackathon to see what can be done there and then.
I had not seen the publication of this until this morning, so I apologize for my tardiness.
I'd like to raise a few general points of considerations in grants:
- Money-wise: we shouldn't be granting according to how long it might take us to do it. We should be granting according to "is investing this money to achieve this goal worth it?"
- Grant sizes: While large grants are a risk, small grants, in a way, are too. What we need is deliverables. Deliverables are not just "done", but "being used". We need something that "goes into production", so to speak. That's the way to judge whether it was successful. Small grants have a major risk of - while finishing them - will not actually be used, because they don't provide *enough* to have usage. I'll mention more of this later.
Specifically about this grant:
- Dancer 1 vs. 2: I don't think you should hold it against Theo for not deciding fully on whether he will use Dancer 1 or 2. Instead of it being an irresponsible "after-thought", it was the responsible approach of making sure he doesn't commit accidentally before researching this. After he spoke to me, I assured him Dancer 2 should be used and will be perfectly suitable. That decision has been made after applying for the grant.
- As stated above under "Grant sizes", I think this is a good example of a grant that would have a hard time being split into multiple ones. Although you could set up a different grant for providing templates (which isn't a bad idea, really), it would be hard to split the schema from the interface, simply because having the schema alone wouldn't be useful. No one would use it unless there's something that works on top of it. While we assume Theo would just the same continue with another grant, it would be harder to approve it, and we're assuming he would. With this grant, he has already committed to seeing the original grant (schema + API) to the end. In other words, if it's split, and the first grant (schema alone) is approved, ends successfully, and then there's no API written, it has effectively failed. This can happen. This *has* happened.
- I do believe splitting the templates can be done without hurting the grant, and making achieving it easier, and making the templates-alone grant easier to accept and accomplish.
I should note one final thing: Theo has mentioned his connections with the different developer sub-communities as a useful resource. He is absolutely right. He has elicited the assistance of the Dancer 2 core dev community. If this grant gets approved, we will provide our full support for achieving the Dancer2-related bits of it. That includes not only making sure the framework can achieve all that is necessary (even though I think it's already fully ready for that), but also provide support and help with implementing the API in the best way possible.
I am very grateful for the commitment from the Dancer2 Core Dev team. This will greatly benefit this project and hopefully some very useful features will be added to the Dancer2 Eco-system as a spin-off.
Also, a very important asset is the support of the DBIx::Class team, by Core Developer Ribasushi. Having discussed things with him in the past, it proves that his insight are of incredible value to het as much out of DBIx::Class as possible. And thus build a rock solid fundament for the 'Next Generation'. --- definitely no dbicdump!
I got an email from 'Maddingue' SÃ©bastien Aperghis-Tramoni. I quote from it: Â«Of course, I will provide all the help I can. Beside answering your questions to the best of my knowledge, I can do the same thing I did for Getty and his Yact project, and setup an instance of your project on the server, to see how it reacts to actual data (and for me, it's useful in order to prepare an actual deployment).Â»
Surrounded with these people, I will make Start-ACT "Voyager" reach it's "Final Frontier"
I am currently traveling, so am not in a position to offer an elaborate yet coherent response to the grant. My TL;DR is: I agree with Sawyer X. It is prudent to look at the grant as a package, "do we want to spend X amount of money in an all-or-nothing fashion for a set of deliverables Y". The answer to this should be a simple yes/no, the currently ensuing haggling is not constructive and what's worse - demoralizing, both for the current grant seeker and for future ones.
Also I would like take a momnt to confirm that Theo did contact me, and he does indeed have my commitment for support as far as DBIx::Class vagaries are concerned.
You should get in touch with whoever did the design for the YAPC::Brasil 2014 site - it's beautiful!
If that could be turned into a reusable template that would be great. It works pretty well on an iPhone too :)
IMHO the REST API should be independent of the framework being used.
Yes, that looks great . . .
so this is what i had in mind for the NLPW::2015 as well . . .
I quickly smashed together that Perl Workshop website in no-time but has not yet been launched (it is based on Foundation)
And as nice those design of YAPC::Brasil or NLPW::2015 might beâ€¦ they miss many key features of the current Act system: no schedule, no login, no payments and no news
Still, it is a nice 'layout' style where you could build nice things into.
Glad you like it and see the importance of responsive web design.
I am not sure how I should interpret your comment...
I know enough about RESTful API's that I'm fully aware that â€” from the client side of view â€” an API MUST not expose neither server, nor framework, nor datamodel dependant information.
But designing an API will still involve a lot of work on what resources should be made available, what methods can be used and what kind of data is transmitted (json, collection+json, hal+json, hal+xml, atompub).
But still, no matter how you design it at the outside, it needs to be deployed somehow. You need some kind of server and using Dancer2 as a framework comes with a load full of nice features you do not have to worry about. You as no other should know what Dancer2 means from the developers side of view.
If, however, you mean that the RESTapi implementation should also be framework independent, I can only think of that you want me to write it as PSGI applications, so they can be plugged into any other framework.
Lucky me, even if that would be a requirement, Dancer2 can be ran as a PSGI application with, for example placket. Problem solved?