On 30 Jan 2015 at 13:53, Antony Polukhin wrote:
I'd be glad to mentor the Boost.Document project from last year: https://svn.boost.org/trac/boost/wiki/SoC2014#Boost.Document
Great news.
Niall, would be the following "Programming competency test" OK: {{{ Implement a generic wrapper around one of the existing Office suits. Wrapper must have the following methods:
struct format { enum type { PDF, }; };
*class* enum type ...
void open(const filesystem::path& path); // opens a document void export(const filesystem::path& filename, format::type format = format::PDF); // exports a document in specified format
`export` function must be able to export in PDF format at least. Other formats support is welcomed. Prototypes that are able to work with different Office suits will be highly appreciated.
You need to link to the relevant programming API documentation for at least Microsoft Office. I'd also verify that Office can export in PDF format, that may not be guaranteed for older Offices. I'd also link to some tutorial document on programming Office with C++ rather than .NET. I also think asking them to program portable C++ against raw COM is a big ask for GSoC. If you can allow them only the VS2015 compiler which has the await keyword already, that ought to hugely simplify their task. They can use C++ lambdas as resumable functions as event handlers (I make the big assumption that that works in VS2015 with Office COM).
Prototype must be submitted with unit tests and build notes.
Submission of the programming test should be via copying and pasting the parts you wrote into the end of the proposal you submit to Google Melange.
I might add a little bit about what unit testing you want. Perhaps "testing of at least three different input file types e.g. doc, ppt, xls". Under the Office COM API that actually would triple their workload, so maybe just doc, docx, odt. Think of the programming competency test as very similar to student tutorial coursework. It needs to be spelled out in detail with links to documents telling them how to do it. Lots of hand holding. Also, for a brand new library I would strongly consider implementing the problem yourself beforehand to test its suitability for students. You might find it a lot harder than expected, or weird gotchas appear which might make students be scared off from your project idea. If you know about those you can frame the task better. Most students mainly lack confidence, even small road blocks can put them off completely. Niall --- Boost C++ Libraries Google Summer of Code 2015 admin https://svn.boost.org/trac/boost/wiki/SoC2015