Site!

[ianstormtaylor]

Things to figure out:

• [ ] Putting the site on Heroku would be nice to keep it simple to deploy.
• [ ] @MatthewMueller do we have a domain name for the site already? I could setup a simple repo that has basic stuff so we can start hacking on adding things to it.
• [ ] Have a simple search server would be really nice for making the ecosystem findable. I think we'd need a tiny registry just because we're starting to get into packages not even needing component.jsons (even on GitHub?). With a simple CLI tool like duo index :name/:repo that would just let the registry know to index that package?
• [ ] If we write the docs in pure Markdown, we could use Metalsmith, so that they can be viewed straight on GitHub or on the site itself, in case that helps. Happy to setup the dev environment there to make it super painless to use.
• [ ] We should get this stuff in the proper GitHub organization now?

[dominicbarnes]

Yeah, we're gonna need a registry I imagine. Would be nice to index entire users/organizations too. (although I wouldn't be opposed to running duo publish once for each component I make)

[ianstormtaylor]

Indexing entire user/orgs could be interesting. My only concern is that I think with Duo we end up not needing component.json anymore at all, even for GitHub packages? @yields is that right? If so we won't have really anything to go by to know that a package is a Duo package. I wonder if Go solves this at all.

duo publish is a much better name haha. If there is a component.json would could even make the :name/:repo optional too.

[matthewmueller]

we could probably pull off the git remote -v to make :name/:repo optional if you have a remote set up as well.

Then you could just do:

git create :name # using defunkt/hub
duo publish

[ianstormtaylor]

Ah yeah that is also sweet.

[matthewmueller]

@MatthewMueller do we have a domain name for the site already? I could setup a simple repo that has basic stuff so we can start hacking on adding things to it.

I don't... unfortunately both duojs.com and duojs.io are taken, so I'm a bit stuck with the domain name. We could just use github pages and host it under http://duojs.github.com/duo, but that's kinda lame.

Have a simple search server would be really nice for making the ecosystem findable. I think we'd need a tiny registry just because we're starting to get into packages not even needing component.jsons (even on GitHub?). With a simple CLI tool like duo index :name/:repo that would just let the registry know to index that package?

I'd love a search server, I just know how finicky component's was, so I'm somewhat interested in using existing infrastructure. But if someone wants to take the lead on developing this, that'd be awesome.

If we write the docs in pure Markdown, we could use Metalsmith, so that they can be viewed straight on GitHub or on the site itself, in case that helps. Happy to setup the dev environment there to make it super painless to use.

So you thinking metalsmith would build the static site? I haven't tried metalsmith yet, so I'm not exactly sure how that fits in.

We should get this stuff in the proper GitHub organization now?

Yah, I'm thinking we can start pushing new stuff to the github org. I don't like how Component's org was managed, so I'm probably going to keep the rights pretty conservative.

Ideally, people could create their own repos on the org and push to them, but not mess with other people's repos without explicit permission.

[ianstormtaylor]

I don't... unfortunately both duojs.com and duojs.io are taken, so I'm a bit stuck with the domain name. We could just use github pages and host it under http://duojs.github.com/duo, but that's kinda lame.

Could we get duojs.org to match npm? Not as nice as duo.io or anything :) but workable?

I'd love a search server, I just know how finicky component's was, so I'm somewhat interested in using existing infrastructure. But if someone wants to take the lead on developing this, that'd be awesome.

For the search server, I completely agree, just not sure I see a nice solution with the existing infrastructure since it's going to be so hard to tell what is and isn't a Duo package in a repo? What are you thinking there? Does that GitHub search technique yield good enough results for it to work? or is there another?

So you thinking metalsmith would build the static site? I haven't tried metalsmith yet, so I'm not exactly sure how that fits in.

Metalsmith would just let us have docs that are nice to look at on the site in addition to the pure Markdown ones. But honestly pure Markdown is probably good enough at this stage, so it could just live in a Wiki somewhere potentially.

Yah, I'm thinking we can start pushing new stuff to the github org. I don't like how Component's org was managed, so I'm probably going to keep the rights pretty conservative.

Ideally, people could create their own repos on the org and push to them, but not mess with other people's repos without explicit permission.

Sounds good to me. If you create duojs/duojs.org I can start pushing stuff to it, although gotta go for Outsidelands in a bit so it'll be Monday night when I really can :)

[yields]

@MatthewMueller when did you last check duojs.io, it might be available now ? :D http://www.nic.io/cgi-bin/whois?query=duojs.io

[dominicbarnes]

Yeah, duojs.io looks available from my end too.

[dominicbarnes]

What about using github web hooks? (kinda like how the latest jquery plugin site works) Like, we have an index of component name, description, keywords, version(s) that updates post-push?

I'm not sure how other that would translate for other providers, like Bitbucket, Bower or NPM though.

[matthewmueller]

Could we get duojs.org to match npm? Not as nice as duo.io or anything :) but workable?

Ohh nice! I forgot npm gets away with a .org. Just bought it :-).

Yeah, duojs.io looks available from my end too.

Oh sorry, I must have been looking at duo.io. I actually think duojs.org looks a bit better than duojs.io. Plus it's like 1/5 the price haha.

For the search server, I completely agree, just not sure I see a nice solution with the existing infrastructure since it's going to be so hard to tell what is and isn't a Duo package in a repo? What are you thinking there? Does that GitHub search technique yield good enough results for it to work? or is there another?

Yah, I'm down for setting up a tiny, simple registry at registry.duojs.org. Maybe try using https://github.com/bigeasy/locket for the db to keep things uber simple. We can scale if this becomes a thing.

Metalsmith would just let us have docs that are nice to look at on the site in addition to the pure Markdown ones. But honestly pure Markdown is probably good enough at this stage, so it could just live in a Wiki somewhere potentially.

Oh yah, if we go the website route, I think metalsmith for syntax highlighting and formatting is a great solution.

Sounds good to me. If you create duojs/duojs.org I can start pushing stuff to it, although gotta go for Outsidelands in a bit so it'll be Monday night when I really can :)

Awesome! I wanted to go real bad. I'll create the repo now.

You still at your place in Lower Haight? I'm headed back to SF tonight. Moving in on the 10th. So excited to be settling down. I want to meet up with you guys soon!

[matthewmueller]

What about using github web hooks? (kinda like how the latest jquery plugin site works) Like, we have an index of component name, description, keywords, version(s) that updates post-push?

@dominicbarnes would that work for components without component.json? (maybe we shouldn't be encouraging that, but I'm not sure we could prevent it)

[dominicbarnes]

Hmmm... yeah using web-hooks we would want some sort of manifest file. But if they don't provide one, then perhaps only their "name" (eg: user/repo) would be indexed? Maybe that way they're still in there for searching, it just may be hard to find.

Although it seems to be that we'd have this same problem no matter how we choose to build/index our registry. I guess the main question is how/when data comes in.