anirudh-eka/dashtag

dashtag's Issues

Move all env variables to db

When loading posts async slowly posts come out in the same color

break TWITTER_BEARER_CREDENTIALS into two env variables

right now
TWITTER_BEARER_CREDENTIALS=your_twitter_key:your_twitter_secret
Let's make it so the user doesn't have to put the key and secret together

Remember me feature with User login

Allow user to stay logged in after browser is closed

Core validation for settings inputs

Basic UI to settings page

• should show current settings
• should update settings

Simple UI Enhancements

• Disable the horizontal scroll

Remove Environment References in Spec Helper

Remove Environment References in Spec Helper

Stub out the EnvironmentService methods before tests and remove references in tests (except for EnvironmentService)

Unknown configuration section 'librarian_puppet'

I'm having trouble setting up the app with vagrant. I recently pulled it down and followed the directions here. I have vagrant and virtual box downloaded on my machine. This is the output:

$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
There are errors in the configuration of this machine. Please fix
the following errors and try again:

Vagrant:
* Unknown configuration section 'librarian_puppet'.

$ vagrant -v
Vagrant 1.6.3

I'm new to vagrant; so I'm probably missing something simple. Thanks for the help!

Update Read Me

Show how to run locally and update, etc.

Snap Build failing

Snap build failing after making engine

Standardized how the border columns look for each post

The top portion of the border on the post are pointed, and the bottom portion of the post are rounded. We should standardize how they appear on the site.

Update gemspec info

UI for reading and writing settings

Move Twitter Users Environment Variable to DB

use rails partials when loading new posts with ajax

Put icon of social media source on each post (next to date)

Explore other options instead of using singleton in API Service

Reason for using singleton:

The API Service is a singleton that stores the last time it pulls from Social Media in an instance variable. We used a singleton because:
1. We wanted a single instance of the service to interact with external api so that we don't hit any api rate limits.
2. We wanted to avoid storing this information in the db if possible because it would often be updated and we thought it would be cheaper as far as performance to have it simply live in memory

Questions:

1. First of all, do any of the reasons above not make sense?
2. When is it appropriate/not appropriate to use a singleton in a Rails App?
3. What are some alternatives we could use?

Thanks!

@pturley, do you have any advice?

Core User/Admin functionality

Write view tests for feed

Write more view tests for all of the components on the feed. Not all are covered currently.
Investigate: cannot locate links on page by post_id, but works for screen_name

When I change background color of header, the header seems to overlap the first few posts

Support compound hashtag aggregation

Support for pairing hashtags, eg. aggregate posts that have "love" and "peace", but not posts that only have one.

Twitter display requirements

While I really like the visual design, it doesn't follow the twitter display requirements as set out on https://dev.twitter.com/overview/terms/display-requirements

Shut off access to any other port on DB from any other address

We need to be able to encrypt and decrypt them.

@pturley, do you have any suggestions on how to go about doing this? I was looking at ActiveSupport::MessageEncryptor. If I go down this route, it seems like a good idea to store the key and salt somewhere besides the db, like the environment. Am I thinking about this correctly?

Or is there something that is put into a rails environment that I can derive a key and salt for? I'm thinking about the SECRET_KEY_BASE. Is it good practice to use the same string as a salt and to generate the key (when initializing ActiveSupport::KeyGenerator)?

Thanks!

Move read me info to dashtag-solo

dashtag-solo is the new home for a ready to deploy application to heroku, etc. We need to move the read me on dashtag there so it stays relevant

Improve Performance

• Decrease default number of post loaded

Create simple admin login

Example deploy?

Is there any example site running somewhere, as a demo?

"Brand" dashtag feed with link to repo

Move Instagram Users & User Id Environment Variable to DB

When a new post is displayed it appears twice

When a new post is posted it appears twice. When a user refreshes the page the duplicate post disappears.

Deploy to OpenShift

Instructions for settings editing

staging site is down

in the readme, users are recommended to view the staging site but it is not working. i receive an application error. see below.

Replace Puppet with Chef

Refactor helper

Ruby gems

Add Icons for home, settings, and log out icon

Allow for a YAML file configuration for dashtag instances

Question: If we support configuring a dashtag instance by either environment variables or a yaml file, which should take prioritization? EG: if someone sets hashtag as "love" in the env, but "peace" in the config file, which should we go with?

make date of post relative

Make Dashtag into a rails engine

Build plugin to allow embedding in anywhere on page

Move Configuration from environment variables to storing in db

I wanted to record @pturley 's idea here. We can move most of the configuration from env variables to being stored in the db. This way creating a dashtag page would simply mean selecting a name for the heroku app, and maybe a username/password (which would probably live in the env?). Then after the page is deployed a user can visit the site, say:

http://foo.herokuapp.com

The dashtag page would check it's db if any of the configs are set. If not, it redirects the user to:

http://foo.herokuapp.com/config/new

where they will be prompted for the password they set and from their they can set all the configurations like credentials, colors, hashtags, etc. All this will be stored in the apps db. Later on, the user can edit these settings here:

http://foo.herokuapp.com/config/edit

This kind of logic would overlap with what's being done in the Dashtag Factory.

Improve HASHTAGS Environment variable entries

Currently this Hashtags env variable expects the following as the value:

love|peace|happiness

It is more intuitive to be something like this:

#love, #peace, #happiness

Move Hashtag from env var to db

Create factory methods for Instagram

Currently we only have FactoryGirl.create which sets the source to twitter. It would be nice to have an equivalent for instagram

Make into Ruby Gem

Setup dummy app configuration so that it will load live tweets in dev

Make Setting 'private'

SettingService is the api to interact with Setting Model and the Settings table in the DB. Therefore, we should limit access to the Setting model to only the Setting Service