Grant Proposal: Start ACT - Voyager

Wed, 16-Jul-2014 by Makoto Nozaki  edit post

Category: Grants

Comments (17)

[ 1374 ] | Wed, 16-Jul-2014 by perlpilot

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.

[ 1375 ] | Wed, 16-Jul-2014 by barbie

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.

[ 1376 ] | Thu, 17-Jul-2014 by timbunce

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.

[ 1377 ] | Thu, 17-Jul-2014 by theo

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.


[ 1378 ] | Fri, 18-Jul-2014 by theo

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.

[ 1379 ] | Wed, 23-Jul-2014 by perlpilot

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.

[ 1380 ] | Wed, 23-Jul-2014 by lestrrat

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

[ 1381 ] | Sat, 26-Jul-2014 by danwright

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.

[ 1382 ] | Sat, 26-Jul-2014 by theo

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

[ 1383 ] | Sat, 26-Jul-2014 by theo

Okay, lets give it a try to make some 'yard stones':

DBIx::Class Schema


  1. Setting Up a ACT server

  2. Check with DBIx::Class Core developers

  3. Edit names and relations

  4. Write tests and run tests

  5. Add smart shortcuts helpers and Class Methods

  6. Write more tests

  7. Write Documentation

  8. Modify Original ACT Core so it will connect through DBIx::Class


Dancer2 implementation

  1. move mod_perl handlers to Dancer2 routes

  2. have Dancer2 routes fill in the original templates



RESTapi

  1. define all useful resource

  2. write the POST, GET, PUT and DELETE methods

  3. test, test and test

  4. write documentation



Theme Based Templates

  1. Find a proper frontend framework (Foundation)

  2. Define Layouts

  3. Define Pages

  4. Redo the entire ACT with new templates and themes

  5. Decide which SASS variable will be editable

  6. Run several default Themes and Colorschemes

  7. 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.

[ 1384 ] | Sat, 26-Jul-2014 by sawyerx

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.

[ 1385 ] | Sat, 26-Jul-2014 by theo

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"

[ 1386 ] | Sat, 26-Jul-2014 by peterrabbitson

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.

Cheers

[ 1387 ] | Mon, 28-Jul-2014 by alexbalhatchet

You should get in touch with whoever did the design for the YAPC::Brasil 2014 site - it's beautiful!

http://2014.yapcbrasil.org.br/en

If that could be turned into a reusable template that would be great. It works pretty well on an iPhone too :)

[ 1388 ] | Tue, 29-Jul-2014 by stefanhornburg_racke_

IMHO the REST API should be independent of the framework being used.

[ 1389 ] | Tue, 29-Jul-2014 by theo

Yes, that looks great . . .

so this is what i had in mind for the NLPW::2015 as well . . .

http://theovanhoesel.com/nlpw2015

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.

Theo

[ 1390 ] | Wed, 30-Jul-2014 by theo

Hallo Stefan,

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?

Theo

Sign in to add comment



About TPF

The Perl Foundation - supporting the Perl community since 2000. Find out more at www.perlfoundation.org.

Categories

  1. Grants (973)
  2. Conferences (153)
  3. Perl 5 Development (112)
  4. Perl Foundation (100)
  5. Perl 6 Development (60)
  6. Raku Development (32)
  7. Marketing (30)
  8. Parrot development (20)
  9. Projects (19)
  10. Outreachy (16)
  11. GSoC (15)
  12. Hackathons (14)
  13. Meetings (13)
  14. Awards (11)
  15. Raku Foundation (10)
    16. ... see all [19]

Popular Tags

  1. p5p (28)
  2. grants (17)
  3. perl (14)
  4. yapc (13)
  5. perl6 (11)
  6. tpcislc (9)
  7. tpcih (8)
  8. tprcic (7)
    9. ... see all [142]

Recent Tags

  1. hackathons2023 (1)
  2. yapcjapan (1)
  3. tprchouston (1)
  4. tpf-cat (2)
  5. raku (1)
  6. cic-helpdesk (1)
    7. ... see all [142]

Get Perl

  1. Perl 5
  2. Raku

Links

  1. The Perl Foundation
  2. blogs.perl.org
  3. perl.org
  4. perl.com
  5. MetaCPAN