Feature - setting up development environment

[smishr4]

Explanation About What Code Achieves:

• I came across this interesting idea this morning and wanted to have a go through on my local machine but found out that development environment isn't set up. So I setup everything on my system using a few simple grunt tasks and enable its usage in just one simple command(would be useful to any future contributor).

1. Install grunt packages using node package manager.
2. Wrote grunt tasks to host the app on local server, open it automatically, watch any change in the project files, and automatically livereload upon changes.
3. Updated README.md for usage.

TODOs:

1. We can git-ignore the vendor files and use bower to manage it.
2. We can setup Prod environment if it is to be hosted on a remote server.

[smishr4]

@calvinashmore Let me know if I should improve my approach further or try it with a better alternative.

[calvinashmore]

Thanks for your work on this!
This seems like a reasonable idea, but I want to run it by @galaxykate
I'm not sure what her goal is for running this as a dev environment

[smishr4]

Sure calvin, there definitely exist many ways to do it, I can make some edits to readme to make it more clear.

[schnelleyoga]

wow, that is really interesting

[smishr4]

Oh well, I cloned it from my fork and forgot to put git name when doing npm init thats why it had my name, I think you are right that it should be google and I should fix it. Let me know if you are sure about that.

[Fahad1417f]

Do you make that real?

[calvinashmore]

@galaxykate, can you let me know what you think of this when you have the chance?
It seems reasonable to me, but I want you to sign off before we use Node officially.

[smishr4]

@calvinashmore Did you get a reply on this?

[galaxykate]

Sorry for the slow reply, I was on break last weekend.

I'm only a little familiar with Grunt, what do you think it gains the user in the system in this case?

One of my issues that I want to fix with the repo-as-it-is is that the IDE and the bot-simulator/FSM code are a bit conflated. I agree that the FSM code (ie, state tracking, blackboard management, and response handling) ought to be broken out into a Node file so that Bottery maps can be run in any environment. This was what happened with Tracery's NPM "port" ) which only required a module export and a few lines to wrap it in a closure. Properly turning Bottery into a separate map-running node library is useful (although tricky and I'm gonna have a go at it myself).

But turning the whole IDE requires the user to be running it on a node server. Bottery already loads files asynchronously, which I'm against, because it requires the user to have it running from a local server, at the minimum, which decreases accessibility for very novice users (hard to overstate what a difference it is for a novice running an HTML file vs running a tinyhttpserver or node!)

If this is turning Bottery into a production ready environment, then it might be worth doing a fork, so that I can develop Bottery into a more newb-friendly environment, and developers can have something that works with a modern professional workflow (something that I'm not familiar enough with to support).

I'm quite political on this, and come from a non-professional software background so I expect disagreement :-) Tracery succeeded by getting non-coders involved, and I'm committed to getting Bottery to that point, too, though it has a long way to go. But that's my commitment, not yours, so I'm not sure which way the "main" repo should go.

[noelleleigh]

I agree that minimizing the number of dependencies required to get the IDE up and running is a good goal to have. I think it makes sense for the more technical developers to add on whatever development tools they like to their local repositories, while keeping the main repo as unopinionated as possible.

Having to npm install and all that that entails for a straightforward client-side app feels like a large increase in bootstrap complexity that isn't worth forcing on novice users.

Personally, all my development has been done using npx http-server in the directory for an easy, no-install server, but obviously the same could be accomplished using Python, Ruby, etc, so I wouldn't want it baked into the code itself.

[smishr4]

Sometimes you'd find these tools extremely helpful in optimizing your development workflow, simple http-server doesn't do port forwarding over network so you can't open your app on a different pc connected to same network. Most importantly you manually have to reload the page to reflect the changes you made and for a person like me who makes so many mistakes this adds time. I can suggest you even more simpler solution @noahleigh if you are using atom editor, install atom-live-server package, that provides you these feature and you don't have to run any command, just a keyboard shortcut yo start and stop a server.

[smishr4]

Sorry guys, I only came across this nice sexy package in atom called atom-live-server and I'm sure there would be an alternative available in the editor you guys might be using, so we can ditch our http-server and grunt-contrib-connect for the sake of simplicity. So I suggest closing this :)