User Story

For: Avoiding duplications
What: Super Components
To: Easier development

Why this would be great

Code duplications are a terrible issue. If there is a code duplication somewhere, it buils danger to create another duplicata somewher. After a while, this piled up to a lot of code, that are difficult to track.

Some duplication can be done with simple refactoring. Importing modules with some functions, and using these functions instead of more code.

But when coming to components, we have the classes to worry. Since inheritance were simplified with ES2015, it's important to use, avoiding duplicate class declarations.

What are we facing?

The code already use some refactoring, but the classes Login and Register seems almost the same. It's important to use inheritance on this case.

Expected result

Just one or two Super Components must resolve on this case.

Overview

I think it would be great to make this seed app, a real project on Github.

What I'm asking it's for defined templates for issues or pull requests, README.md, CONTRIBUTING.md, and many more things.

Make it so that when copying this seed, I won't have the urge to think a lot, on designing these files.

Context - Why this would be great

Lots of Github public repositories, have their documenting files on project. Some of them are nice, others aren't. The good and detailed ones have at least:

• README.md file: for explaining what project it's for. How to use it, versioning, license links and links to other documents.
• CONTRIBUTING.md file: for better orientation on everyone interested on helping at making this project go on.
• Issue templates: to help on issue tracking. Not only makes the process a little faster, but nice and with details. The users don't need to think a lot about this, just use it.
• Pull request templates: they will be needed. Same as issue templates.
• Labels and Milestones defined: Milestones for versioning, and labels to detail everything else.

Current version

It have the CONTRIBUTING files (althougth missing CODE_OF_CONDUCT file), and templates, and labels with milestones. It only misses the README file.

Also, the name of repository it's still Socially.

Expected version

Will have a README file, linking to LICENSE file;
And make CONTRIBUTING link to CODE_OF_CONDUCT file as well.

Also the name will finally change to MEM-Seed.

User Story

For: Party Description
What: Upload Photos
To: Atract more people

Why this would be great

The first thing to attract a people on a party, it's the photos. People expect that on a party advertised with nice photos, they will have more fun. The organization of the party will seems better, the security, etc.

What are we facing?

For now we don't have any support to this. Description on parties rely only on Text and location. That's great, but for users, smells boring.

Expected result

After this feature, User will have option to add a photo on a new party they're creating.

Goal

Make docs on this project, that gonna guide any person on the team, for collaborating, fixing bugs, making code and making issues, pull requests or commits.

• Orient commits
• Orient issues
• Orient pull requests

Overview

To make this a better project, I need to use Travis CI support. So that I can use automatic tests, and
run them at every master update, so I know if the tests are passing on last build or not.

Context - Why would be great

Tests are needed for many things. The main one it's to ensure that new changes won't compromise rest of the code. Then we make automatic tests

Current version

I've tried a lot to make this working with sanjo:jasmine and velocity. But Meteor staff doesn't recommend using it as I discovered at here.

Expected version

I'm gonna use Mocha, following the guide. The jasmine tests are already with the correct positioning, so I think it's gonna be just a matter of changing packages.

Overview

The Material Design Icons package from Google, don't have use on the project anymore. Since the addition of MDIIcons as well the filter to translate them to use on md-icon.

Context - Why this would be great

Simply enough, all of the icons at Material Icons are already on Material Design Icons for Community.

So, nothing better than to use only one service, and less code.

Problem

The actual code make unnecessary and large call to Material Icons here:

// imports\ui\components\socially\socially.js
const googleIconPath = '/packages/planettraining_material-design-icons/.../svg-sprite/';

    $mdIconProvider
        .defaultFontSet('mdi')
        .iconSet('action',
            googleIconPath + 'svg-sprite-action.svg')
        .iconSet('communication',
            googleIconPath + 'svg-sprite-communication.svg')
        .iconSet('content',
            googleIconPath + 'svg-sprite-content.svg')
        .iconSet('toogle',
            googleIconPath + 'svg-sprite-toggle.svg')
        .iconSet('navigation',
            googleIconPath + 'svg-sprite-navigation.svg')
        .iconSet('image',
            googleIconPath + 'svg-sprite-image.svg');

When it could be:

    $mdIconProvider
        .defaultFontSet('mdi');

Overview

After lots of problems. I've managed to get Travis working with spacejam. Great.

Now to make great use of it, I need to keep writing more tests to make the project reliable.

Context - Why this would be great

You understand that tests are needed. But to make extend of TDD it's better to have lots of them.
Testing everything, will increase reliability on the code, and also will make GOOD EXAMPLES to follow when writing new ones.

Current version

We've got tests on the following packages:

• api/parties/methods
• ui/components/partiesList
• ui/components/partiesSort
• ui/components/partyAdd
• ui/components/partyCreator
• ui/components/partyDetails
• ui/components/partyRemove

Expected result

I find it important to write tests on every component that make have a class linked. These are:

• ui/components/auth
• ui/components/login
• ui/components/partyRsvp
• ui/components/partyUninvited
• ui/components/password
• ui/components/register

User Story

For: Developing tests
What: Test Libraries
To: Avoid duplications on test.

Why this would be great

Writing tests can be a pain in the ass. There's many code to ensure that the current test run at the specified scope, with the specified behavior. Because of this, lot of this code can be very extensive and not easy to read.

What are we facing?

Look at this code below.

if (!user.create) {
    Accounts.createUser({
         username: user.username,
         password: user.password
    }, function(error) {
        user.create = true;
        if (!Meteor.userId()) {
            Meteor.loginWithPassword(user.username, user.password, function() {
               user._id = Meteor.userId();
               done();
            });
        } else {
            user._id = Meteor.userId();
            done();
        }
    });
} else {
    done();
}

This code it's necessary to ensures that a fake user it's logged on some part of the test. It creates if the user doesn't exists. And set user._id.

This code it's really complicated to understand if mixed with many others.

Then the necessity to make a library.

Expected result

I need a package on imports/modules folder. It doesn't need to be in a test folder.

User Story

For: Collaboration on project
What: Guides
To: Avoid creating problems when collaborating

Why this would be great

Working with many people it's great. If all of them have good relationship with everyone, soon all of them will follow some common rules. And then, the project work faster.

But when a new person comes on project, comes the adaptation phase. The new colleague will need to learn all the common rules, common patterns used by everyone, so no one gets angry with strage changes.

Then comes the need of a remainder with all orientation for newcomers.

What are we facing?

The project it's changing a lot. So the docs that are already there, soon needs some updates until it gets perfect for newcomers to understand a very lot of the project.

Expected result

Please update CONTRIBUTING.md file, so we can orient new people to work on this project.

User Story

For: Registering issues or pull requests
What: Templates
To: Remember everything I need to put on them

Why this would be great

Making Issues are complicated. A lot of patterns must be followed, so the people can understand the description of issues or pull requests.

A template would make this a lot easier.

What are we facing?

The project it's changing a lot. So the templates that are already there, soon needs some updates until it gets perfect for newcomers to code faster.

Expected result

Please update ISSUE_TEMPLATE.md and PULL_REQUEST_TEMPALTE.md file, so we can register issues or PRs more faster.

Overview

This issue it's a security problem. I've needed to load the Google API key, for Google Maps, but the only method that worked out were loading the API Key on a script call.

Since the script it's called on HTML, anyone can see. And that's not safe.

I've tried to solve this issue using a provider from Angular Google Maps, but it didn't work. This uiGmapGoogleMapApiProvider don't resolve NoAPIKeys warning.

Issue environment

Context - Why this became an issue

I was using the Angular Google Maps directive for a while, on the purpose of showing markers on a map. Then I notice that the warning NoAPIKeys were displayed.

I've needed to use a bad solution to make the warning disappear.

Issue description - What are we facing?

It's bizarre how this warning don't make any harm. It's just a warning. It doesn't blocks Maps from showing, nothing.

I've tried to solve this, by using the uiGmapGoogleMapApiProvider that the team advice to, using this:

export function ConfigGoogleMap(uiGmapGoogleMapApiProvider) {
    'ngInject';

    Meteor.call('getGoogleAPIBrowserConfiguration', (error, result) => {
        if (error) {
            console.error('Oops, unable to get API Key!');
        } else {
            uiGmapGoogleMapApiProvider.configure(result);
        }
    });
}

But after lots of work to make the provider work on a config file for 2 components, the Warning still shows.

Since this Issue didn't seem to be solved by other people, I've tried to search for other methods. Then I use a tutorial from Google Maps Javascript API, to export the Key using:

 <script src="https://maps.googleapis.com/maps/api/js?key=YOUR_API_KEY"
  type="text/javascript"></script>

Which is a bad solution, since it exposes the Key on the HTML.

Expected result

I leave the config function to solve this problem, unharmed. It will wait until the team from Angular Google Maps to solve the issue first.

Goal

Allow user to upload files.

We plan to add these features to project:

• User can upload photos to descrive parties.

What are we facing?

A lots of Web applications uses something to handle uploads of files. It's on so many sites, that's a site without it loses clients very fast. So we need a system like this.

Expected result

It's without saying that photo upload will be required, for better details on users profile, and parties description.

User Story

• For: Writing new Tests
• What: Better names
• To: Understand better old tests.

Why this would be great

Making or transforming tests are a delicate issue. You need to know if something were tested before to avoid creating dumb tests. This create performance problems when running everyone.

For this, understanding of each test it's crucial. And problematic names create many problems on reading code.

What are we facing?

Since some new tests were just made. Some names weren't really goods. Including variables, strings, functions, etc.

Expected result

I've need a review on all tests. Making changes on every bad name found. The bad names are names that make code ugly, or contribute for misunderstanding of code.

Sprint Goal - This sprint will make the project have good documentation, automatic testing and reviewing for better pratices, and better organization.

• Use Codicy
• Use ReviewNinja
• Use ZenHub
• Use Travis CI
• Update README, and lots of documentation from Github.
• Good design at tests
• Good design at code (using better pratices)
• Good design at visula (using Angular Material)

User Story

For: Understand this Project
What: UML Models
To: Improve undestand of code

Why this would be great

This project it's planned to be used later, by more people to build new projects. Understanding of this project structure it's essential. For this, we're already planning on makin a Wiki. For illustrations, UML would be perfect.

What are we facing?

0 UML Models. That's because it wasn't the focus on this project, since we were focusing on making this a SCRUM project.

Expected result

The idea would be to have some main core models. To understand components, arquitecture, and some complicated comunication between components, and core packages.

Also, it would be great for refactoring purposes.