-
I'm QA (typically functional).
I guess I can be across handling/reviewing the backlog, defects, immediate task items, priority, general coordination? (If you would like.)Could potentially automate the generation of a number of forums, but would be pre-hackday so I can use work's auto-test tools.
Would need walk-through, understanding of scope and core functionality of system, obv... :)
-
Would need walk-through, understanding of scope and core functionality of system, obv... :)
I'd be happy to host an evening in advance of the hack weekend to describe core concepts, API interfaces, API flow, error handling and stuff.
Sure I'll be documenting this, but it will be done between alpha finish and the hack weekend... so I won't have it to share in advance and will need to talk you through it and demonstrate instead.
This is an open invite... happy to do 1 evening for everyone, in advance of the hack weekend.
-
Title - Release day Guinness Puddings
Priority - CRITICAL
Due date - TBA
Assigned to - mands
Components - cake
Environment - http://studiothirtynine.com/ -
Risk: Deliciousness
Test iterations: Manyok i'll stop now...
#slavetothejira -
I haven't seen much Android-love above so whatever API info and ER diagrams I could use to get the app moving? I can check that into whatever the chosen source control solution is once I've got a working prototype.
I've already had one idea for an App-only feature but you might prefer it remain unimplemented. I'll write something up next weekend if I remember.
-
Docs are located here by the way: http://microcosm-cc.github.com/
Still work-in-progress of course, but they're looking good.
-
By the way, those docs are actually open source, and if anyone notices any errors, then pull requests are welcome:
https://github.com/microcosm-cc/microcosm-cc.github.comYou can also log issues with the docs through that.
-
Finished doing samples for the /microcosms API:
http://microcosm-cc.github.com/#SingleResource19Basically is the reference for all actions on a collection of Microcosms or a single Microcosm.
The content is largely fine, but the format.... hmmm. If anyone has constructive criticism I'd love to hear it.
-
The more eagle-eyed will notice that Github changed how they host pages, and the docs are now at:
http://microcosm-cc.github.io/Though the source for that will continue to be hosted here: https://github.com/microcosm-cc/microcosm-cc.github.com for the time being.
-
I have a question to developers about creating a Poll via an API.
There are two concepts/resources involved: The poll itself, and the collection of choices within a poll that people then would vote on.
What do you think you would prefer:
1) A single call to create the poll and poll choices, so that you have to construct the poll choice array and deal with whatever the interface issues of that are.
/polls/{id} would therefore return the poll and choices, and to add a choice you'd have to construct the entirety of the poll and PUT it to that address, likewise to remove a choice would also mean re-sending the whole poll.
2) 2 calls, 1 to create a poll and 1 to create the set of choices.
/polls/{id} would return a summary of the choices, but you'd only POST the poll question.
/polls/{id}/choices would be where you POST the array of choices, but you could individually POST new choices or DELETE an existing single choice by touching the choices at /polls/{id}/choices/{choiceId}.
3) Many calls, 1 to create a poll and 1 call for each choice you want to create/
/polls/{id} would return a summary of the choices, but you'd only POST the poll question.
/polls/{id}/choices would be where you POST the single new choice, and you could still individually POST new choices or DELETE an existing single choice by touching the choices at /polls/{id}/choices/{choiceId}.
We drafted the first version in the style of #1, but it created a few issues for UIs such as having to screw around with Django formsets and requiring the application to deal with the whole poll and all choices even if you only wanted to update or add a single choice. It also doesn't feel RESTful at all, it's clearly a mixed idea.
#3 seems like the purely RESTful way, but also feels like it's quite chatty and non-transactional (what if one fails, you have to figure that out and repeat that one call).
#2 feels like #3 but as it allows dealing with the choices in a RESTful way, but at the same time it allows you to deal with 2 transactional calls to create the poll... one for the poll, one for the choices.
So #1 we have... but it doesn't feel great. In the alpha #1 is likely to stay, but beyond that I'm curious as to what people would find easier to work with... #2? #3?
Emyr
mands
branwen
Howard
motter
skydancer
Kirth-
Post a reply
About
2013-04-27/28 - Microcosm Alpha Hack Weekend
Posted by
@Velocio
We'll be launching an alpha of Microcosm mid-April.
Features for the alpha are:
The alpha isn't feature complete. There are many more types of content to come (Q&A, wiki, classifieds, galleries, etc) and basic features are missing (attachments, private messaging, etc) as well as advanced features missing (advanced permissions and user groups).
The purpose of the alpha is to:
With that in mind, we're throwing the doors of our studio open for the weekend of Saturday April 27th through to Sunday April 28th, 9am through 9pm-ish each day.
We'll provide a space for up to 8 people to be resident for the weekend, with us nearby making changes and fixing stuff quickly.
We'll also provide pizzas, drinks, and other snacks to those hacking away, and a safe place to lock bikes.
This will all happen at http://studiothirtynine.com/ unless demand is so great that we need to find a larger venue.
What can you do during the hack weekend? Pretty much what you wish, though we're keen to see people build against the API, so as suggestions:
If more than one person wants to work on, say, the Android app... then we'd encourage you to pair up into a team to move faster.
Anyone interested?