search

andkov / ShinyEFA

experimental visual interface to decisions in Exploratory Factor Analysis based the interactive features of R Shiny and D3
3 stars 2 forks source link

Shiny apps conversion #30

Closed wibeasley closed 10 years ago

wibeasley commented 10 years ago

@andkov, I had to make some changes so it would run on http://wibeasley.shinyapps.io/ShinyEFA/. The main change moving the files and updating the relative directories. This location seems to be the new best practice recommendations.

Notice this issue is independent of your decision about https://github.com/andkov/ShinyEFA/issues/29.

wibeasley commented 10 years ago

Also, I realize I can click 'Merge pull request' as easily as you. But I didn't want to commit a big change like this to your master branch without your input.

andkov commented 10 years ago

yes, this is great, thanks for moving, adapting, and notifying me. I'll takes this as a new good practice.

wibeasley commented 10 years ago

Cool. And I just deleted the branch (locally and remotely) to reduce clutter.

andkov commented 10 years ago

great, thanks! clutter has becoming a bane. deleting something may have also as bad consequences as keeping it.

On Sun, Aug 10, 2014 at 9:08 PM, Will Beasley notifications@github.com wrote:

Cool. And I just deleted the branch (locally and remotely) to reduce clutter.

Reply to this email directly or view it on GitHub https://github.com/andkov/ShinyEFA/pull/30#issuecomment-51740408.

wibeasley commented 10 years ago

As long as you're still interested in using git in practice...

Nothing was really deleted. When you approved the pull request (ie, merged the dev branch into the master branch), all of the changes were incorporated into the master. And you can refer to commits made to that dev branch; but it's not easy to keep adding new commits to the branch.

Sometimes it makes sense to have a perpetual dev branch (like this) and sometimes it makes sense to have short-lived branches (like the current one was). I like short-lived branches when there's a very focused purpose, and it introduces changes that would break the existing code (eg, changing the relative paths). It's easier for me to compartmentalize in my head.

Now, there is a bunch of crap, err I mean vestigial, code in ShinyEFA repository that could be cleaned up or deleted altogether. But for my debugging purposes, it doesn't matter at all. Hoard away.

andkov commented 10 years ago

i've spoken to one of Sasha's coworker, who tries to organize something similar (git based research microcommunity), he also favored short-lived branches. From his description, you create a branch, experiment with the innovation, merge it back to the master and then delete the branch immediately. I'm not sure whether he knows what he's talking about - he seemed fresh to it, but just report for whatever validation.

the branching is something i am still wrapping my head around. I'm sure doing would advance knowing.

On Mon, Aug 11, 2014 at 12:03 PM, Will Beasley notifications@github.com wrote:

As long as you're still interested in using git in practice...

Nothing was really deleted. When you approved the pull request (ie, merged the dev branch into the master branch), all of the changes were incorporated into the master. And you can refer to commits https://github.com/andkov/ShinyEFA/commit/6ffbf958fc35250826efebcca02569bce6113935 made to that dev branch; but it's not easy to keep adding new commits to the branch.

Sometimes it makes sense to have a perpetual dev branch (like this https://github.com/OuhscBbmc/REDCapR/network) and sometimes it makes sense to have short-lived branches (like the current one was). I like short-lived branches when there's a very focused purpose, and it introduces changes that would break the existing code (eg, changing the relative paths). It's easier for me to compartmentalize in my head.

Now, there is a bunch of crap, err I mean vestigial, code in ShinyEFA repository that could be cleaned up or deleted altogether. But for my debugging purposes, it doesn't matter at all. Hoard away.

Reply to this email directly or view it on GitHub https://github.com/andkov/ShinyEFA/pull/30#issuecomment-51825167.