Fantasy Ultimate: Let's make this happen!

[Louis Abramowski]

Hi everyone -

I'm Lou.  You might know that I founded The Ultimate Page on Facebook.  I put a call out to software engineers yesterday who have free time to pursue a Fantasy Ultimate project built on the Leaguevine platform.

I've invited about a dozen folks who have expressed interest and availability to work on it over the next 5 weeks to get something simple ready quickly.

I think we need to assign a few roles to get something going:

1. General direction of the project (I'll do that)

2. Some general project management (anyone especially good at this or enjoy it?)

3. UX design/Wireframes (I can do paper prototypes)

4. Design (anyone have a resource?)

5. Leaguevine API integration (anyone good with APIs?)

6. Data model for fantasy: owners, teams, leagues, etc. (anyone good with DBs?)

7. Backend: putting it all together (anyone like this challenge?)

My thought is just web for now (maybe a mobile-responsive ready design), but I'm open to ideas.

Anybody crazy and ambitious enough to push code out live in 4.5 weeks? :) Kickoff two 2 week sprints on Sunday :)

Any thoughts?

Lou

[Chad Stewart]

I do a little bit of 2 (project management), 5 (working with APIs), and 6 (database design) at work. I would be comfortable doing anything that people don't want to do.

[Ben Demboski]

I'm quite experienced with API integrations, so I'd probably be up for taking that on. However, I'm slightly nervous volunteering before we've decided (or before I've learned) a few high-level things. The big ones that come to mind are:

1. Do we need a stateful server (depends on the feature set)?
2. Will the API integration happen on the backend, on the front-end, or both?
3. What technologies will we use?

Obviously kicking off everything at once precludes having detailed answers to all of these, but if we had a rough idea of the feature set and very high-level design, we could probably answer (1), have a good guess at (2), and then start answering (3).

And I guess I may have just volunteered to help out with project management, although I prefer to primarily be a developer :)

B

--
You received this message because you are subscribed to the Google Groups "Leaguevine Developers" group.
To post to this group, send email to leaguevine...@googlegroups.com.
To unsubscribe from this group, send email to leaguevine-devel...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/leaguevine-developers?hl=en.

[Dominick]

Hi,

My experience is primarily in custom DBs so would be up for working on that.  MySQL is DB of choice.  Open to guidance from project management as most of my work was on solo projects.

Real curious to see how this all works out.

--

You received this message because you are subscribed to the Google Groups "Leaguevine Developers" group.
To post to this group, send email to leaguevine...@googlegroups.com.
To unsubscribe from this group, send email to leaguevine-devel...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/leaguevine-developers?hl=en.

--

With regards,

Dominick Smyth,

Dublin Youth Ultimate

facebook.com/DublinYouthUltimate
domi...@irishultimate.com

086 150 73 33 

[Kyle Lapatin]

I would like to suggest a task list being developed (possibly divided into these categories). It would be useful and allow everyone to fully utilize their free time. They could just go to the list, sign up for the task and begin working rather than coordinate with other people. I also agree with Ben Demboski, where we need a high level design at this point (preferably documented).

-Kyle

[Chad Stewart]

Okay, here's what I'm reading.

1) We have Ben who would like to tackle integrating the LeagueVine API.

2) Dominick would prefer to do the database design and would prefer MySQL. (Which is fine, in my opinion.)

3) We need a high level design.

4) We need something better than the Google Group.

I would like to suggest two products I've used successfully in the past: Unfuddle or Kona. 

Unfuddle is a full-on suite with messages, project management, source control, but it would cost us money to have unique users.

Kona is simply a workspace with Notes, Tasks, Events, and the ability to attach Files.

We could also host something like trac. If anyone has any other suggestions, throw 'em out there.

I think the other questions we need to answer are: What language should we use on the front end? (PHP, HTML5, CSS3?) What is our complete-by-Nats feature set? 

- Chad "Ocho" Stewart

[Ben Demboski]

I'd like to make a case for using Github to host our code and for our project management. First of all, I'm assuming this is going to be open source, right? If we host it as a public project on Github, then there is very close to zero friction getting other folks to jump on board and help out -- they can see the issue list, fork the repo, fix the issue and submit a pull request (probably a fantasy (pun slightly intended) that anybody will do so in the short term, but at some point). Github projects come with a wiki and a somewhat rudimentary issue list, but it's pretty much become the standard solution for open source projects these days, and I've always found it to be functional enough to get the job done.

So, I am very much in favor of just hosting everything on Github. If/when it ever stops meeting our needs, we could start using a separate project management solution, but it seems to work for the vast majority of the open source community, so I would think it would work for us as well.

As I said, I think open sourcing this project totally makes sense, but if we don't want to for some reason, I still have room for some more private repos in my paid Github account, and would be happy to donate one to hosting this project.

Thoughts?

B

[Mark Liu]

Hey all,

Just wanted to chime in with a few things. First of all, us here at Leaguevine are really excited for this project and we'll do everything we can to make sure the API is good for you to work with. We will leave this project entirely up to you all and our involvement will almost all come from providing you the API features you need to pull this off. We may chip in with a bit of code here and there just for fun. :)

As for the code hosting and project management, I agree with Ben that github is the way to go. If you'd like, I could create this repo under the Leaguevine account so a few more people will see it and so people realize you have full support from us. I'd just add some of you as admins on the project so you can manage it however you want. Let me know and I can make that happen.

Alternatively, if you choose to not use github for whatever reason, we might be able to help you out as well. We use redmine internally and would be happy to host a redmine project for all of you for free. And if you choose to use some other paid solution we may be able to help with those costs as well. We really want to see this project take off and will help however we can.

Mark

[Louis Abramowski]

Hi All -

Github sounds great.  I will say, I've got a paid account to Basecamp and happy to put together a Fantasy Ultimate project there.  

Generally speaking, I'd like to keep this project under the umbrella of The Ultimate Page.  The page for me is mostly a passion project, not a business or anything that makes money.  My loosely stated mission is to have the most awesome place on the web for Ultimate stuff.  I think Fantasy Ultimate aligns extremely well with that mission.  I'll also take on any of the nominal expenses that come along (hosting, etc.) … unless uncle Mark wants to subsidize it through Leaguevine :)

I'm not an open source guy, so I'm not very familiar with the pros and cons.  Can someone fill me in on some advantages or reasons why we might want to make this open source?

If this all fits with Github, let's run with that.  Thoughts?

Ocho's summary was excellent.  I'll take on the wireframes (and find someone to do design).  I'll try to have something in place by Monday.  Is that fast enough for everyone?

Thanks everyone!  This is off to a great start!

Thanks,

Lou

[Ben Demboski]

Let me quickly fill you in on how Github forks and pull requests work. Imagine we go with the public Github project, and are down the road a little ways and have released something. If somebody out in the community is excited about it and wants to help out by, say, fixing a couple of bugs, then they can find our public project and fork the repository. This basically means that they have their own copy of the source code and can make whatever changes to it they want without affecting the original. So they can fork the repo and check in a bug fix. Then they can submit a pull request back to the original project. We would be notified, would be able to review their changes, have some dialog if we want any further tweaks, and when it's all set, accept the pull request, propagating their changes back into the master repository. If a particular developer is involved enough that we want to give them direct access to the original master repository (like we will all have), we can do that. This is how pretty much everybody these days maintains ownership of their code base, but also allows the community to contribute with minimal friction.

That, in my mind, is the key benefit to making this project open source. Another benefit is that, if publicly available, our project could serve as reference code for people wanting to implement their own apps against the Leaguevine APIs, which I think is also in line with the mission of this project, and would make Uncle Mark happy :)

The drawbacks to making it open source are, obviously, that it's not secret, so somebody could take the code and use it to make their own competing app, or deploy it to their own servers as a carbon copy or something. But really, who would do that?

The other wrinkle here is that we would not want to publicly expose our client secret for accessing the Leaguevine APIs, but there are a few ways to solve that, depending on the architecture of our app and our deployment. Getting technical here for a second, so if you don't care about this level of detail, please just take my word that it's totally solvable :) If it is only the client (Javascript, mobile app, etc.) that accesses the API, then it's all user-driver authentication and we don't need to store a client secret anywhere and there's no problem. If we need to access the API server-side, then we can either inject the client secret "manually" at deployment time (keep it in deployment scripts that we don't check in, or require that it be set in the environment, etc.) and not have the client secret checked in anywhere, or we can create a separate configuration repository that is private and contains any sensitive secrets like the client secret, and have the deployment process pull it down at the same time as it pull down the main project repo and inject it that way. Or I suppose we could create a private repo that just contains our deployment scripts along with the sensitive secrets and do it that way.

Anyway, bottom line is that I don't think there are any significant drawbacks to open sourcing it, unless you are worried about people "stealing" the code, and there are a couple of pretty substantial benefits.

B

[Louis Abramowski]

Got it.  Thanks for the explanation Ben. 

If the only downside is "a competitor stealing code", then there are really no drawbacks.  We have a good opportunity not because of the code itself, but because of the Leaguevine platform integration and The Utlimate Page audience.

So I like this, but it's got me thinking.  Is there another open source fantasy app that we can branch off of?  Or is that an open-source cultural faux-pas?

Thanks!

Lou

[Ben Demboski]

A quick search on Github didn't reveal anything that looks very promising. Plus, since anything out there wouldn't be using the Leaguevine APIs, there might not be that much reusable code. Certainly finding a good app out there just to use for feature set and UI/UX ideas would make sense. I don't really have much experience here, but a friend of mine says that ESPN's fantasy football app is a good one...

B

[Louis Abramowski]

Yeah, I'll probably mimic the UI/UX from either ESPN or Yahoo's mobile app (which is very good).  I also wrote a fantasy league management system in 1999 (ColdFusion represent!!) … so I've been down this road before :)

Thanks for the legwork Ben!

Lou

[Ben Murphy]

You might check on google code. I believe it has some of the code that yahoo uses for their fantasy applications.

On Thursday, September 20, 2012, Ben Demboski wrote:

A quick search on Github didn't reveal anything that looks very promising. Plus, since anything out there wouldn't be using the Leaguevine APIs, there might not be that much reusable code. Certainly finding a good app out there just to use for feature set and UI/UX ideas would make sense. I don't really have much experience here, but a friend of mine says that ESPN's fantasy football app is a good one...

B

On Thu, Sep 20, 2012 at 12:33 PM, Louis Abramowski <hot...@gmail.com> wrote:

Got it.  Thanks for the explanation Ben. 

If the only downside is "a competitor stealing code", then there are really no drawbacks.  We have a good opportunity not because of the code itself, but because of the Leaguevine platform integration and The Utlimate Page audience.

So I like this, but it's got me thinking.  Is there another open source fantasy app that we can branch off of?  Or is that an open-source cultural faux-pas?

Thanks!

Lou

On Thu, Sep 20, 2012 at 2:18 PM, Ben Demboski <bende...@gmail.com> wrote:

Let me quickly fill you in on how Github forks and pull requests work. Imagine we go with the public Github project, and are down the road a little ways and have released something. If somebody out in the community is excited about it and wants to help out by, say, fixing a couple of bugs, then they can find our public project and fork the repository. This basically means that they have their own copy of the source code and can make whatever changes to it they want without affecting the original. So they can fork the repo and check in a bug fix. Then they can submit a pull request back to the original project. We would be notified, would be able to review their changes, have some dialog if we want any further tweaks, and when it's all set, accept the pull request, propagating their changes back into the master repository. If a particular developer is involved enough that we want to give them direct access to the original master repository (like we will all have), we can do that. This is how pretty much everybody these days maintains ownership of their code base, but also allows the community to contribute with minimal friction.

That, in my mind, is the key benefit to making this project open source. Another benefit is that, if publicly available, our project could serve as reference code for people wanting to implement their own apps against the Leaguevine APIs, which I think is also in line with the mission of this project, and would make Uncle Mark happy :)

The drawbacks to making it open source are, obviously, that it's not secret, so somebody could take the code and use it to make their own competing app, or deploy it to their own servers as a carbon copy or something. But really, who would do that?

The other wrinkle here is that we would not want to publicly expose our client secret for accessing the Leaguevine APIs, but there are a few ways to solve that, depending on the architecture of our app and our deployment. Getting technical here for a second, so if you don't care about this level of detail, please just take my word that it's totally solvable :) If it is only the client (Javascript, mobile app, etc.) that accesses the API, then it's all user-driver authentication and we don't need to store a client secret anywhere and there's no problem. If we need to access the API server-side, then we can either inject the client secret "manually" at deployment time (keep it in deployment scripts that we don't check in, or require that it be set in the environment, etc.) and not have the client secret checked in anywhere, or we can create a separate configuration repository that is private and contains any sensitive secrets like the client secret, and have the deployment process pull it down at the same time as it pull down the main project repo and inject it that way. Or I suppose we could create a private repo that just contains our deployment scripts along with the sensitive secrets and do it that way.

Anyway, bottom line is that I don't think there are any significant drawbacks to open sourcing it, unless you are worried about people "stealing" the code, and there are a couple of pretty substantial benefits.

B

On Thu, Sep 20, 2012 at 11:57 AM, Louis Abramowski <hot...@gmail.com> wrote:

Hi All -

Github sounds great.  I will say, I've got a

--

[Chad Stewart]

I like github and it sounds like it's everything we need. I haven't used it since they added issue tracking. Dang, it's been a while.

An initial search shows some potential (https://github.com/rideron89/fantasy), but I'm not sure how great it is without anything to see. 

If we're willing to get a public repo and some basic design by Monday, I think we can certainly crack out something minimal. We can at least do a basic layout similar to ESPN or Yahoo! I think we have enough to do here that we can split out the front-end implementation. We need matchups, drafts, etc, right?

Obviously, we can't host this on the facebook page. We should probably also get some hosting lined up as well.

[Louis Abramowski]

Hi Chad -

Though we can't host it on a Facebook Page, I do have a few features in mind for Facebook integration that are on the wish list:

1. Require users to LIKE Ultimate on Facebook to sign up

2. Post the complete team to Facebook when a user completes his/her draft

3. Post the final score of a team after a tournament 

4. Use Facebook to sign up & auth the users

For framework, I think we need:

Leagues (many leagues, 2 to n owners per league, 2 types of leagues: 1 big public one that anyone can join & leagues by invite-only)

Rosters (I think anyone can have any player on their roster for v1 … this eliminates the need for draft software)

No need for match ups.  Everyone in a league is against each other and there's just one set of standings.  Match ups can come later when we focus on more than one tournament (other than USAU CC's).  I think match ups might make less sense with the irregularity of scheduled games with ultimate.  Maybe a "league" is just a "tournament" that exists for that one weekend and that's it.  Perhaps owners should score points based on finishes per tournament (like NASCAR) rather than like head-to-head games.  Thoughts?

Lou

[Ben Demboski]

Hosting in the Amazon cloud? It's easy and reasonably cheap and has some nice perks like an e-mail service (although SES kind of sucks)...

Have we thought about a domain name? fantasyultimate.com is unavailable -- does one of us own it? fantasyultimate.net is available -- maybe we should buy it?

I think those Facebook integration features should be pretty straightforward. We should probably also make sure the web site design can live in 760px of horizontal space, as I assume we'll want to be (primarily?) a Facebook canvas page, and while not a strict requirement, being able to live in 760px makes things much simpler.

Any of the back-end folks have thoughts about what technology to use on top of the database? I definitely think we should use something ORM-y -- my far and away favorite web framework is django, although I've never used rails. I barely know ruby, so going with django/python would make it easier for me to get off to a running start if server-side API integration is needed, but I'm sure I can pick up ruby quickly if somebody is really big on rails.

B

[Kyle Lapatin]

I am 100% for django/python over ruby/rails. I have heard (and seen) some amazing things about python and django, and python was next on my to-learn list. I have also heard not so great things from people learning ruby after learning common languages like Java, C etc. Of course those people that learn ruby first seem to like it; I am much more towards the python type of developer (and from what it looks like from the bios, a lot of others here seem like they would pick up python easy if they don't already know it).

-Kyle

[Louis Abramowski]

Some of the most talented software guys I know are recently converted python/django zealots … so I feel great about python/Django.

I'm working through a few domain ideas.  A .com is a must.  If anyone has any ideas, I'm open to them.  I will likely lock this down sometime this weekend.

Amazon cloud sounds great.  I will mention that heroku is pretty slick in that you can stub out your fully-configured FB app directly from within Facebook with it and it's practically free until/if you need to scale (although I will say that the last time I did this, the stub wasn't ideal). But if FB integration/config is simple, that's not much of an advantage.  Plus, email service will be up in the air.

FYI … just an update, we're going to start searching for volunteers to take stats at USAU's Club Championships at the end of October to run this for the first weekend :) So if you know anybody … :)

Thanks!

Lou

[Ben Demboski]

Perhaps we should set up the Github project so that we can start posting things on the wiki as they come together? I think it makes sense to have it under the Leaguevine account -- any objections, Lou? If not, then Mark can you set it up and make me (https://github.com/bendemboski) and whoever else an admin? Maybe just call it fantasy-ultimate or something for now -- we can rename it later once we have a better project name.

B

[Mark Liu]

On Fri, Sep 21, 2012 at 6:38 PM, Ben Demboski <bende...@gmail.com> wrote:

Perhaps we should set up the Github project so that we can start posting things on the wiki as they come together? I think it makes sense to have it under the Leaguevine account -- any objections, Lou? If not, then Mark can you set it up and make me (https://github.com/bendemboski) and whoever else an admin? Maybe just call it fantasy-ultimate or something for now -- we can rename it later once we have a better project name.

B

Sure thing. I've set up a fantasy-ultimate repo and added you (Ben) as an admin. Here it is:

https://github.com/leaguevine/fantasy-ultimate

Everyone else, let me know your github account names if you'd like to be added as an admin.

On the topic of the web framework of choice, I'd like to also say I am a huge fan of Django and believe this is a great decision. Leaguevine is built in Python/Django and we love working with it. 

On the topic of storing confidential authentication information in an open source app, Ben nailed the explanation and this is definitely the way to go. This is how leaguevine-ultistats works.

On the topic of hosting, AWS and Heroku are both great options. If you use AWS, Leaguevine can cover all costs. If you use Heroku, we can likely cover the costs, but that will depend on the configuration because a Heroku app can get expensive really quickly. We know first hand since Leaguevine lives on Heroku. :P

Keep up the good work everyone,

Mark

[Louis Abramowski]

Perfect. 

AWS, Django, and Github it is!

Next you hear from me, I better have a project name and wireframes. 

--

Sent from my Sprint iPhone4S. 

RIP my Palm Pre, 2009-2011

[Ben Demboski]

I created and checked in a very basic Django project. It's really just a bunch of boilerplate stuff and a landing page, but more importantly I added instructions for setting up a dev environment to the project's README.md. They are 100% guaranteed to work on everybody's machine without any issues whatsoever. Heh, yeah.

Seriously, though, the setup instructions for Ubuntu should be pretty complete, but my Ubuntu install was already set up to run Django, so I couldn't really test the instructions from end-to-end. MacOS is a bit sketchier -- I have run Django using the general setup described for our project, but I don't quite remember all the bits that had to come together before setting up the python virtualenv, although I don't think it was that much. I'm sure it's possible to get this all going on Windows, although I don't know if you can do it in a virtualenv and I've never tried.

I think this is all pretty standard boilerplate stuff, but if anybody has any suggestions for how to do things differently, please speak up. I'm just trying to help things move quickly, not be The Decider :)

I named the Django project lfvu (LeagueVine Fantasy Ultimate), which obviously leaves quite a bit to be desired. When we come up with a name for the overall project, we can change the name of the Django project.

If anybody has a chance to run through the setup instructions and let me know if there are issues, I'd definitely appreciate it. I'm pretty reachable during the day at this address via e-mail or google talk.

I think the next obvious thing to work on is the login flow -- putting together some code to manage the Facebook connect authorization and then verify that users have liked the Ultimate Facebook page before letting them in. I already have some code that I can port from another project that uses django-social-auth to manage account creation/login through Facebook connect, so I'm happy to pull this login flow together with some placeholder pages on top of it. Lou -- are you cool with making this just a first-login-time check so that theoretically users could like the page, log in, then un-like the page and continue using the site, or do you want us to be more aggressive about verifying their page-liking? I think just doing account-creation-time verification will simplify the login flow, and I doubt this will be an issue, but if we wanted to, down the road we could always manually run a check to see how many users *still* like the page, and if enough people are un-liking it for us to be concerned, put in more aggressive checking then.

B

[Alex Grin]

Just throwing this out there: why are people required to like (and possibly continue liking) the Ultimate page before they can play in a fantasy ultimate league? The two feel almost unrelated. As a user, I would feel that I'm being forced to jump through hoops. As a developer, I would be interested in reducing the friction between users and the app to an absolute minimum. Am I missing something here? What do we gain from people liking ultimate?

[Louis Abramowski]

Good question Alex. 

The reasoning behind it is not directly user-centric. The idea is that this is "a project of the ultimate page". 

Our strategy toward traction will generally trend toward a network effect (more users = more value for each user). 

We will use the Ultimate Page to drive sign ups, sign ups will drive growth on the page, the virtuous cycle grows, and a network effect is achieved on the app. and the network effect should benefit the user ... So this like-gating is very indirect potential benefit.  

That's the plan. I'm open to allowing a bypass ("continue to app"), but I do feel this will help the user more than it appears on the surface. 

On that note, the best domain idea I had was a shortened version of Fantasy Ultimate HQ ... Or "FUHQ" ... Which I didn't think was very inviting :)

With that, I think we will use a sub domain of a domain I already have: http://fantasy.ultimatepagehq.com

I'll work on the Wordpress theme there that will better reflect what it represents and promotes the hell out of he fantasy app. 

Wireframes are almost complete and I've got a resource who is world class at front end dev for the web that I've just gotta convince this is worth some of his time :)

Any thoughts on all this?

Lou

--

Sent from my Sprint iPhone4S. 

RIP my Palm Pre, 2009-2011

[Sean Parker]

Hey all,

I have some database experience and know a little python. I've never touched Django but I'm familiar enough with MVC and have played around with rails so hopefully I can pick it up quick.

Ben,

I ran through the README. Thanks for putting that together. I had one issue while installing an item in requirements.txt. I was missing the mysql_config file. Installing libmysqlclient-dev fixed the problem. After that it was all smooth (except connecting to that German site to grab AnyEdit... I might have messed up tabs for a bit.)

-Sean

[Ben Demboski]

Awesome, thanks a lot, Sean! Glad to hear the instructions almost worked :) I added libmysqlclient-dev to the package list in the readme.

B

[Roger Wang]

Was able to get this working on Mac after installing MySQL.  Setup was pretty smooth after that, although i had virtualenv installed already.  I've added instructions for installing MySQL (via homebrew) to the readme.