archivist website - Githubissues

MarcinKosinski commented 8 years ago

For now the archivist website is held under the link http://pbiecek.github.io/archivist/ . What do you think about moving website to https://archivist.io/ address?
~~What is more I think we could use knitr-jeckyll package to use jeckyll templates for our website https://github.com/yihui/knitr-jekyll~~
We might divide the future website to parts entitled as
- About
- Use Cases (short one-topic posts)
- Tutorials (longer posts)
- Information for Potential Contributors
Also we should check whether current Use Cases are relevant and think about new ones [maybe with such .gif examples : http://brendanrocks.com/images/output2.gif ?]
- chainingUseCase can be updated with new functionalities
- justGetIt can be extended with aread and asearch
- cacheEngine that's still great.
- Maybe we could think about reimplementing dplyr package (under names dplyr.archivist) so that queries to databases send with src_* object's could be cached automatically? If we would manage to do this for small databses like RSQLite, maybe we could reimplement dplyr.spark.hive to cache spark application executions or hive jobs on hdfs/hadoop?
- Do we consider implementing %cache% operator (%a% + cache()) ?
- lazyLoadUseCase It has funny pictures but I do not believe if this is worth mentioning.
- retrieveingPartialResults could be extended with ahistory function and retrieving object's pedigree
We can develop website under gh-pages branch and remove ghPage folder from master branch

MarcinKosinski commented 8 years ago

Also Boruta package has a nice website https://m2.icm.edu.pl/boruta/

pbiecek commented 8 years ago

And I see that there is a pyton package for it. The next intership may be about a python version of archivist.

2016-02-02 16:18 GMT+01:00 Marcin Kosiński notifications@github.com:

Also Boruta package has a nice website https://m2.icm.edu.pl/boruta/

— Reply to this email directly or view it on GitHub https://github.com/pbiecek/archivist/issues/192#issuecomment-178628736.

pozdrawiam serdecznie, Przemysław Biecek

MarcinKosinski commented 8 years ago

That's very popular nowadays :) Spark, MXNet, XGBoost. All popular tools has many implementations and APIs.

pbiecek commented 8 years ago

Yes, but in most cases there have source in one language and wrappers in others. I think that in our case we can share structure and names of functions but communication with SQLite database needs to be reimplemented in python from scatch. Or maybe no, let's find some python skilled intern.

MarcinKosinski commented 8 years ago

I was thinking about the same :)

2016-02-02 16:50 GMT+01:00 Przemysław Biecek notifications@github.com:

Yes, but in most cases there have source in one language and wrappers in others. I think that in our case we can share structure and names of functions but communication with SQLite database needs to be reimplemented in python from scatch. Or maybe no, let's find some python skilled intern.

— Reply to this email directly or view it on GitHub https://github.com/pbiecek/archivist/issues/192#issuecomment-178649581.

MarcinKosinski commented 8 years ago

I think after I'll create the new page, we could add URL: http://pbiecek.github.io/archivist/ to DESCRIPTION so that on CRAN there would be a link to use cases

MarcinKosinski commented 8 years ago

@pbiecek do you have any special proposition for jekyll theme of archivist website? http://jekyllthemes.org/

I've made a POC for jekyll-knitr http://rtcga.github.io/RTCGA/about.html and it looks like it is learnable in less than 3 hours :)

pbiecek commented 8 years ago

Looks great!

I do not have any special wishes, just let's make it simple and readable. The RTCGA scheme is nice. We can use same layout with slightly different colors (e.g. silver instead of orange).

MarcinKosinski commented 8 years ago

For RTCGA it is Hyde format for jekyll. It supports 16 different color schemes that can be choosed from here bit.ly/1FkOuoU

We can prepare archivist website as a blog website with few main pages. We could rewrite/refresh each existing use-case ase a new post for this website and share new posts on R-bloggers. We could share 1 post per week? And we would have all archivist marketing in one website.

I can provide a few easy steps on how to upload a new post using knitr-jekyll (yoo just write in markdown, but you specify different YAML).

pbiecek commented 8 years ago

Good idea, I am not sure if we are able to prepare 1 blog per week, we may try even 1 per month sounds like a useful thing.

MarcinKosinski commented 8 years ago

I am talking about refreshing old use-cases that need to be design anyway. So the text is already there + I'll prepare short post for archivist.github.

2016-02-24 14:50 GMT+01:00 Przemysław Biecek notifications@github.com:

Good idea, I am not sure if we are able to prepare 1 blog per week, we may try even 1 per month sounds like a useful thing.

— Reply to this email directly or view it on GitHub https://github.com/pbiecek/archivist/issues/192#issuecomment-188263418.

MarcinKosinski commented 8 years ago

Due to #254 archivist website is held under jekyll. The tutorial about how to work with this website can be found so far at our main page http://pbiecek.github.io/archivist/

Talking about this comment: https://github.com/pbiecek/archivist/issues/192#issue-130512252

would we like to have static website with pages (every use case could be transferred and rewritten to one page) or do we want to have 1/2 main pages and blog-posts? Each use case could be changed to a post, after a grand check of relevance, and after every addition we could post this post on r-bloggers. Doing so, we could have 4/5 posts over 4/5 weeks.

Which strategy do you prefer?

pbiecek commented 8 years ago

Ok, so maybe let's figure out how many use-cases/blog post we can create.

If there will be not more than, let say, 10 use cases / blog posts then I think it's easier to have static pages (and the content can be posted on a blog anyway) If we predict some continuos generation of content then blog is a better solution.

So, I see relatively small number of use cases that I can generate (let say 3-5). Do you see much greater number of examples that you can generate?

MarcinKosinski commented 8 years ago

I don't so I'll vote for static page with disquis

2016-02-24 20:22 GMT+01:00 Przemysław Biecek notifications@github.com:

Ok, so maybe let's figure out how many use-cases/blog post we can create.

If there will be not more than, let say, 10 use cases / blog posts then I think it's easier to have static pages (and the content can be posted on a blog anyway) If we predict some continuos generation of content then blog is a better solution.

So, I see relatively small number of use cases that I can generate (let say 3-5). Do you see much greater number of examples that you can generate?

— Reply to this email directly or view it on GitHub https://github.com/pbiecek/archivist/issues/192#issuecomment-188416090.

MarcinKosinski commented 8 years ago

I have removed ghPage directory. All valid use-cases are now in gh-pages branch in _source directory. If you would like to fix webpage, you should chnage .md files od index.html file in the root directory of gh-pages branch.

The site is now in jekyll-hyde theme http://pbiecek.github.io/archivist/

pbiecek commented 8 years ago

Looks good!

2016-03-06 23:33 GMT+01:00 Marcin Kosiński notifications@github.com:

I have removed ghPage directory. All valid use-cases are now in gh-pages branch in _source directory. If you would like to fix webpage, you should chnage .md files od index.html file in the root directory of gh-pages branch.

The site is now in jekyll-hyde theme http://pbiecek.github.io/archivist/

— Reply to this email directly or view it on GitHub https://github.com/pbiecek/archivist/issues/192#issuecomment-193009105.

pozdrawiam serdecznie, Przemysław Biecek

pbiecek / archivist

archivist website #192