Project Planning & Design

[indiv0]

First we should plan this whole project out.

I am going to write out some general information on how we get started, so that as people join in on the project, we can subdivide these tasks.
The below is just a general introduction, so feel free to comment/correct what I write below.

Who will be working on this?

Currently, @reem, @rbrs, @TyOverby, @bvssvni and myself have been participating in this discussion so I assume that's who wants to work on this.

First Steps

The first thing to do (coding, not planning-wise) is to just get a basic page rendering in Iron.
This will involve setting up the bare Rust project, getting the Cargo.toml ready, setting up Travis-CI as well as the actual DigitalOcean server for non-local testing.

Development Process

The actual development process, as for most applications, will likely be done locally, with iterative builds being pushed to the production server (or at least some kind of testing server).
This will allow us to ensure that as we go along, the project works both locally and remotely.
For now however, just getting the basics working locally should be the priority.

Overview

The project itself will have several main components:

• Design
  • HTML page layout
  • CSS styling
• Structure
  • Overall website navigation
    • Signup process
    • Login process
    • Account information/settings pages
    • Game project pages
      • Ability to post blog posts and project information
      • Ability to distribute builds of the game
      • Ability to rate the games, provide user feedback
    • Author pages
      • Overviews of the author's game projects
      • Information about the author
• etc.

If we plan out the entire proces from signup to actual competition submission, we'll be able to decide which models we'll need for the database, what the API will look like, and how the navigation of the site itself will be designed.

Technologies

We'll be using all Rust technologies to build the website.
The preliminary stack is listed here.

[indiv0]

I'll close the previous issue in favour of this one.

[bvssvni]

This looks OK. I would prefer breaking the plan up into further issues. If there are more than one alternative, it is best to discuss them in separate issues, and use new issues to compare them.

[rolandasb]

I agree with @bvssvni. We should discuss every single aspect of the project to avoid redoing stuff in the future.

[indiv0]

Alright, so lets decide on the site's backend right now.
Feel free to pile on suggestions and ideas.
Expand on what I've written above please.

Will we use a REST API to perform actions (e.g. POST /api/author/new), and build the front-end on top of that?

What models do we expect to have (e.g. User, Game, etc.)?
What would they look like?

Will we have the ability to write blog posts on the site to detail game progess (similarly to ludum dare) or will that be a responsibility of the author (i.e. self-hosting)?

My Thoughts

• We should use a REST API.
• I expect to have at least these models:
  • User
    • Game authors will just be Users
  • Game
    • represents an actual Game project in the database and all related information (e.g. current version, project status, project description, etc.)
• I think that we should have some way to distribute binaries for users who don't want to compile from source
• We should not handle blog posts on the site (at least not to start).

[indiv0]

Additionally, will we use templating for the HTML?

I am personally for using templating, as I find it makes the website modular and decreases the chance of markup/styling inconsitencies throughout the site.

[reem]

We need to decide if we are going to do mostly server-side rendering or if we are going to use js and do work on the client. This has major implications for the server architecture.

[indiv0]

@reem you're right. I think maybe server-side rendering would be best. The site should be able to work without JS; and with Iron, I think server-side rendering makes more sense.

[reem]

I guess. Iron is certainly not a Rails-like framework - templating, database integration, MVC and such is largely the domain of middleware and other downstream packages.

@zzmp you interested?

[TyOverby]

What are some rust templating solutions? If there aren't any that are viable, does anyone want to start a project for it? I'd be happy to contribute.

I'm thinking of ways that we could use rust Encodable to get a really clean API.

[reem]

There are two that I know of, both of mustache templating:

• rustache
• rust-mustache

[reem]

Personally I'd really want templating implemented as a syntax extension that gets us strong typing for rendering data into templates, but nothing of the sort exists yet. I've been thinking about starting one, but it would be a rather significant project.

[zzmp]

I'm interested in joining this as well. I'd love to help a project get off the ground using Iron and Hyper - I think it's necessary for continued development and maturation.

---

I think server-side rendering would be a much better showpiece for rust/iron.

@indiv0 why the aversion to JS? I think it just needs a minimal framework (if at all) to keep readability high and make it easier to focus on the pieces written in rust, and not the HTML/CSS/JS.

I'd be glad to work on the front-end aspects, too, as well as make sure it complements existing Rust styles (guides/documentation).

---

EDIT: To clarify, I think the JS used should mirror rust conventions, as the target audience for this code is the rustic. What this means, I'm not exactly sure, but it'd be interesting to tailor a micro-framework around that tenet (and if you've got ideas, drop me a line to talk about them).

[indiv0]

@zzmp I'm JS averse when the site doesn't work without it. I much prefer sites which can work in limited compatibility environments and without modifying traditionally browser-handled operations.

I'm not opposed to JS for standardization (e. g. Modernize.js) or optional features, but I'm a firm believer in the camp that a site should be functional without JS.

[reem]

Using js typically speeds development of the client side of the application, but I think we can get away with limited use and more server-side rendering in this case since this is not going to be a highly reactive site.

[bvssvni]

Shall we use the same theme as in the piston.rs site?

[indiv0]

@bvssvni I think that keeping the theme consistent is in the best interests of the Piston project.

[rolandasb]

@bvssvni Because it's not piston-only competition, I think we should make separate theme for this. I'll look into that.