I download the code and try to run it. It is giving me Error: connect ECONNREFUSED while requesting the feed URL.

The current planet CDOT is long and arduous to read every post. I'm thinking of implementing a pagination in JS to use for the web-page. Feel free to add more suggestions with regards to this.

Add instruction npm test, npm run eslint, npm run eslint-fix to CONTRIBUTING.md. See #55 for more information about the testing infrastructure.

While we are working in such a mid-size project with a large number of contributors, one thing that could be helpful and could let us act more efficiently would be project management consideration. Moreover, it is an opportunity for us as a student to get used to the best practices.
We can use the Github project management feature or any other similar technologies for the following concerns :

Project scope and project implementation plan:
Right now we don't have a clear scope for the project, but as we go we will elaborate one. More importantly, in the first few days, we might better make some common pictures/points of view about our project. Currently, we have started some discussions that their topics could be seen as our project work packages. As we discuss, the outcomes of our discussions can be summarized as deliverable tasks in a TODO like list.

Project realization:
Once the above list is partially made, we can:

• Assign tasks to ourselves, or maybe each other (with some considerations)
• See which tasks are available or are taken more clearly
• Feedback on our progress more effectively all in one place
• Have a final destination to summarize our discussion, issues, pull requests
• Each task can be seen and approved by the project sponsor (Dave) more efficiently
• Tasks can be broken down into smaller tasks (if needed) more clearly
• Tasks can easily be prioritized
• The changes in the project scope (adding/removing new tasks) could be observed (after related discussion) in one place

To have a tangible view/ an example:
Our discussions could be summarized in some project board, for example as such:

To Do:

• implementing text analysis function1 ( issue #7)
• implementing text analysis function2 ( issue #7)
• implementing text analysis functionN ( issue #7)
• making decision about basic unit test (...)
• test for function1,2 ... N
• Linter automation
• issue tags classification
• Kubernetes research
  ...

"Running on Seneca's Kubernetes container cloud" is listed by our overview document as one of the features required of Telescope to constitute a minimum viable product (MVP).

This issue exists to:

• aggregate research and useful information for those interested in contributing to this MVP feature.
• discuss the directions we may take in implementing this feature.

Importantly, research contributed to this thread will be referenced when we write documentation, which will be used by future contributors to our project. Therefore, by contributing to our research, you are also helping lay the groundwork for our project's documentation!

Questions that have yet to be answered include:

1. As far as our project is concerned: what is Kubernetes, and what role will it play here?
2. How may we gain access to Seneca's Kubernetes container cloud? Who do we need to talk to?
3. Will the use of Kubernetes potentially affect other MVP features?
4. Are there any security concerns that may come up when dealing with this feature?
5. Are there any standards or best practices that we should adhere to?
6. Should we create a 'Kubernetes' channel on the seneca-open-source Slack (e.g. to help facilitate open conversations), or should we keep all discussion on Kubernetes centralized within this GitHub issue?

Currently, we have these tasks to do:

• Update documentation -------> (we have self documented files, but should make issue to have them on Documents)
• Add docker files to project
• Adding Helm charts -------> (changd to raw YAML files)
• Deploy on Kubernetes
• Adding Health checks

This counts the lines of code added and deleted and gives a result (added-deleted), for each blog post that links a Github PR..

We should create a .gitignore file in order to eliminate any unwanted files to appear in the repository.

Sentiment analysis can be helpful in determining how negative or positive a blog post is. It will be also helpful to flag blogs which use contain negative wording.

I would like to work on this feature.

Duplicate due to Github error. Should be deleted

We need to create a web server for telescope. We should add what has been mentioned in #62 to this.

After extracting URLs from a blog post (issue #53), use the Github API (if it's a Github URL) to fetch related data like author, description, date of creation, avatars, labels, assignees, projects...

Library that could be used for this: github-url-parser.

At the moment we're using a hack to read feed URLs from a text file. This is fine for our initial efforts, but we should really be pulling those feed URLs from https://wiki.cdot.senecacollege.ca/wiki/Planet_CDOT_Feed_List.

Looking at the markup in that page, we need to grab the contents of the single pre element on the page:

<pre>
################# Failing Feeds Commented Out [Start] #################

#Feed excluded due to getaddrinfo ENOTFOUND s-aleinikov.blog.ca s-aleinikov.blog.ca:80
#[http://s-aleinikov.blog.ca/feed/atom/posts/]
#name=Sergey Aleinikov
...
</pre>

We then need to lightly process this:

• ignore lines beginning with # (comments)
• read URLs out of the [url] format (surrounded in square brackets)
• read the person's name from name=User Name

Later we might decide to store this in a db or something, but let's begin by pulling this down from the cdot wiki.

We're using Bull to manage our work queues, so let's also add a UI so we can see what's happening. https://github.com/vcapretz/bull-board will give us the ability to add a route to a web server to show what's happening in our queues:

Eventually this should be behind an admin login, but for now, we can expose it. It will probably make debugging easier too.

I think it would be interesting to allowing the users to react to each other's blog posts, similar to how facebook lets us react to posts

In #59 we're adding the ability to ingest our current feed list from the wiki. In #63 we're adding a web server. It might be nice to connect both of these and offer a way to get the feed list out of our app as an OPML file. OPML seems to be the standard way of sharing a feed list these days.

What I envision is adding a route that allows for obtaining an XML file in OMPL format with all our student feeds included. We might be able to use something like https://www.npmjs.com/package/@kohlmannj/opml-generator to do it.

The MVP needs to have a CI/CD pipeline set up with automatic tests and deployments.
We need to decide between the following options:

• Github Actions
• Travis CI
• Circle CI

I suggest going for github actions because other options would require setting up external accounts while for github actions, its all here on github only.
On the other side, github actions is still in beta but fairly stable stage.

Most projects that I found throughout Hacktoberfest had some sort of documentation that helped developers to set up their environment faster. As we add code to the project, we should have a centralized place to contain everything we need to get working on the project. It could also be used to track the progress of the project (what people are working on and where to look), according to the MVP Features.

As pull requests are merged, someone should be tracking and updating the CONTRIBUTING.md as needed. It could be a specific person, or a requirement that each pull request must update the CONTRIBUTING.md file if needed. This could also be tracked or linked to in the README or the overview.md doc as well.

A good start would be adding the Redis requirements and setup from #24 .

Part of the MVP features is to determine what technologies to use. This is a discussion on what technologies to use for the backend. We should be able to create a poll so everyone can voice their opinion.

I would like to add a catch after this function so that any errors can be dealt with

It would be nice to make editor settings predefined in the repo like VSCode does with EditorConfig. You can see their setup at https://github.com/microsoft/vscode/blob/master/.editorconfig.

For us, I'd suggest:

• 2 or 4 space indent
• Unix LF end of line
  etc

The windows install notes are missing for Redis in CONTRIBUTING.md

Where are we hosting this application?

• seneca zenit/matrix server?
• heroku?
• others

Also, are we hosting it behind a web server?

• nginx
• apache tomcat
• others
  this is for useful functionalities such as ip-whitelisting, firewall, load-balancing, https, etc.

We need to talk how we’re going to manage our git workflow. What branches will our repo have?
I propose feature branches, that lead to develop which finally builds to master.

We're starting to get some code in the repo, and it's time to think about how we'll test all the features we add.

I'd like to see us get an initial test in place, so we can figure out our infrastructure, and let others add more tests in future PRs.

Let's use Mocha or Jest to automate our tests. At first, we need a simple npm test run that runs one test against something like the feed parser function, or something else really basic: call into a function and it expects to get back a given result.

Extract all URLs from a blog post for further enhancement as well as statistic analysis, extracting data from external API ( as mentioned in #23 ) etc.

Is anyone good at drawing logos? We could use one, so we can put it in our README.

In keeping with the 12 Factor App approach, we need to move toward using environment variables so we can have a proper config.

Let's use dotenv for this. Here's a good discussion on how to set this up: https://www.twilio.com/blog/2017/08/working-with-environment-variables-in-node-js.html

Once we have the env system in place, we can start enabling/disabling parts of the system or features based on flags in our environment. It will also make it easier to configure things like Redis in dev, CI, or deployment environments.

The first part of this should be to get an initial config file in place that we can add to over time.

Set up the base pipeline as per comment on Travis

There is a long list of bloggers but a lot of them do not blog anymore. We should have a way to show currently active bloggers and hide the ghosts.

We should create a worker that would implement the following features:

• Get contents from particular blog post url
• Parse the contents into the JSON format
• Pass the generated JSON file over

Receives: url
Returns: JSON file

I've noticed that in many other GitHub projects, a code of conduct is created to provide standards as to how contributors should behave and how they can participate in the project.

In this file, we can pretty much define what we consider is acceptable behavior and unacceptable behavior. We can also provide information as to how someone can report something that violates the code of conduct. This idea doesn't really have to be enforced but I believe it would be a good idea to have something like this in the future.

We could also just make use of the Seneca code of conduct and just add a link to it somewhere in the overview documentation instead of creating an entire new file

Let's do proper logging for everything in the back-end using Pino. Ideally, I'd like to see us logging things for regular operations, errors, but also offer debug logs to help developers see what's going on.

We can roll this out in stages, but it would be good to add initial logging support with at least INFO or ERROR levels.

Currently ESLint and Jest is run by using different commands:
npm run eslint
npm run eslint-fix
npm run jest

Would be nice that have something like a prescript as @UltimaBGD suggested to run these commands.

More information/options:

@humphd :
the && operator won't work on all shells (e.g., many Windows shells). There are few work arounds for this:

1. we can use pre and post scripts to run things before/after other steps, https://docs.npmjs.com/misc/scripts
2. we could use https://www.npmjs.com/package/npm-run-all to allow for a set of steps

In general, we have to be careful that our scripts work on Windows, since so many common tricks like this will fail :(

Using suggestions and mock ups in issue #12 I'll be making a static HTML page to start, once that's done we can continue adding more features or even containerizing it using Angular/React

I was able to download the planet cdot code from the overview.md using wget
#28

As stated in the overview document, we would like to implement some form of text analysis.

Simple text analysis: Word Length, Reading Time, Writing level, etc

Would be the focus for this issue. This can most likely be developed as a stand alone feature before being integrated into the project. In essence, it can be developed to work on some text, and when the project is advanced enough to support the integration of this feature, easily integrated.

This train of thought could also work for checking the zero content posts, but that may be better to leave for another issue.

I would like to work on this, are there any ideas or ways to improve it that anyone has in mind?

Part of the MVP features is to determine what technologies to use. This is a discussion on what technologies to use for the front-end. We should be able to create a poll so everyone can voice their opinion.

This issue is a part of the MVP Features.

It should send an email to an admin or the user if:

• A post is deemed inappropriate
• Any major errors are logged (ex. issues downloading feeds)
• If it crashed

If there any other times an email should be sent out please suggest them as well.

Set up the base pipeline as per comment (#6 (comment)) at Github actions.

Sanitizer should clean any HTML code found in the blog post to eliminate possibility of running some else's script in our system.

We have discussed in issue #3 about our frontend technology. But how our final frontend looks like? This is important that we think about it for the number of reasons:

• Knowing how our UI looks like helps us to identify our app's features and our project's scope.
• Having a UI design gives us an idea about who can work on what in terms of our front-end development (We can modularize our front-end development)
• The design itself could be somebody's task if they are interested in and if it is acceptable for the purpose of this project.

I would like to get this project started by doing the following:

• copy the existing template/css files (just the simple one from the basic folder) from zenit and paste it into this repo
• activate github pages for this repo
• check it out at the github page

If people are okay with this, I can get it going by tomorrow (provided that I have sufficient privilege to activate github pages)

Set up a base pipeline as per comment at Circle CI.

In the feed-worker.js file, the urls are read from the textfile and just outputed to the console. I think it would be better if it was presented on a web page, which could serve as the basis for a view that contains the list of blogs

We should really have a proper automated linting step using ESLint. You can see good docs on how to do this at https://eslint.org/docs/user-guide/getting-started, and look at how lots of other projects do their linting by reading their .eslintrc file(s).

Until we get automated tests written, this can serve as our npm test step, and let us start automating CI in other bugs.

Update documentation to include instructions for using the .editorconfig file in the following IDE/environments:

the main one:

• visual studio code

optional ones:

• notepad++
• sublime text
• atom
• eclipse
• others

reference link: https://editorconfig.org/