Hello, everyone!
My name is Robert
I work as a Head of Front-end at OK.ru (top 10 world social network)
Today, for our online and offline viewers
I will present SourceJS engine features
You could also read more about it on SourceJS.com
And specially for todays online demo
I released 0.4 beta release
Because of previous version (0.3.2) from master branch is about half year old
By the way, dev branch with nightly releases is always available on Github, as all tasks, milestones and open issues.
So feel free to leave your feedback and use dev our releases.
Starting from 0.4 version we have stable structure, and next year updates will be fully compatible with previous versions.
This is my first try on Hangouts
So don't be anger if we'll run into some minor issues 
I'm hoping that yesterdays my Hangouts pilot run will be enough for managing todays demo.
Lets turn on screen broadcasting
What I have here already, is few questions from the audience
Which you asked earlier
You can also ask new questions in our chatroom on Gitter https://gitter.im/sourcejs/Source
And of course you can also use twitter for that @operatino_en
But first, we'll go through my prepared questions list
Who missed chat link, you can now see it on the screen
And here's some table of contents of our todays demo
As I mantioned already, today I release 0.4-beta version
Which has some stabilty improvements over our dev branch
Starting from basics, we will install SourceJS from scratch
Previously you needed to check out sources from GitHub by yoursef
Initializing them with Grunt
To make install process easier, we created special yeoman generator https://www.npmjs.org/package/generator-sourcejs
For one command install
From SourceJS homepage you can get to setup documentation page
Where you'll find all information about engine dependencies
That is Git, NodeJS, Grunt and Yeoman, installed on your PC
I wont talk much about Git and NodeJS
I don't suggest to repeat my demo steps right now
But of course, if you're already watching video recording, give it a try right away
Let's check some feedback on online stream
I see that somebody ran into problems with our chat
But, seems like everything is okay now
Returning to our demo, lets start with SourceJS installation with yeoman
I already installed Yeoman and generator-sourcejs on my laptop
Which will help us to automate engine installation
For now, generator-sourcejs can only init new project
but in future, it could also be able to create new spec pages
Today I'm going to mention quite oftern word "Spec", which is documentation page in SourceJS
The same word is also used across SourceJS docs
Having all dependencies installed, all you need is to run `yo sourcejs`
Lets create new directory
for our project, named `source-live`
as we see in starting guide, we'll navigate to new folder right away
and there, we will run sourcejs generator
As I mentioned, sourcejs generator can only do init job right now
But with next updates, you'll also be able to chose from other actions that it will provide
So we'll chose first option
And set an option for immediate start after installation
Yeoman will check out git repo for you
leaving .git folder for leaving connection with remote repo
Then it install all npm dependencies and run init Grunt task
And right after all installation proccess, as we chose earlier, yeoman will start SourceJS engine right away.
For those who often asks for SourceJS demo page, I remind you that SourceJS.com homepage fully runs on own engine
And all the documentation is described using same documentation engine
For more demos, you can check out bootstrap lite documentation demo.
Let see what we got
Now we see that SourceJS in now running in development mode
Which is default node environment 
There's also available production mode
Let's open localhost at 8080 port
Now we're at main Engine homepage
as it is without content right after init
All engine documentation is bundled with every SourceJS instance
and is stored in project repo on Github
right in docs folder https://github.com/sourcejs/Source
With blank SourceJS we already have some kind of landing page with all stub specs and docs
All specs could be arranged in any catalogue (based on file structure)
In this example we already have 2 predefined catalogues — Documantation and Specs
You can generate specs list from any catalogue on any page in the engine
With infinite nesting support
Here you can see basic nested catalogue page
And our stub spec template
So I showed you an initialisation process lets head to next step
Recently I saw some issues about installing SourceJS on Windows
But unfortunately mentioned errors appears not directly in SourceJS code, but occurs with one of our dependencies
As not all familiar tools for front-end developers run smoothly on Windows machines.
Main problems that some users run into happens on JSdom installation stage
Because nested dependency needs to be compiled for specific OS that it will be used on.
And all windows machines has necessary tools for module compilation.
To solve this problem on windows, all you need is to get already compiled dependencies 
from special repo https://github.com/mihaifm/jsdom_binaries
Or you can try installing Visual Studio and compile those during npm dependency resolving
More information about this issues, is listed in corresponding Github issue https://github.com/sourcejs/Source/issues/23
And as I know, this is problem the only problem on Windows with SourceJS.
If you'll find new problems, feel free to ask some help in GitHub or Gitter chat.
We also have Windows user in our team, so every new code change is tested on this OS also.
So we're done with installation steps,
lets proceed further by our table of contents.
Next most important question from newcomers on Sourcejs
Is how to configure local engine run and 'production' state, which your team use for collaboration
As adding new specs, we work with local SourceJS instance
And to share content that is already done, we need to ship it to some common instance
We already spoke about how to run SourceJS locally
Yeoman makes first installation and first engine run, and to run it by ourselves
just run `node app` command from SourceJS folder 
Where Yeoman was first inited
So locally we develop all new specs
And production version could we configured in many ways
We don't force users to follow specific deploy processes, but this flexibility sometimes this makes engine usage little harder
That is why, right after 0.4 stable release, I will post many 'cooking recopies' with configuration recommendations
Maybe also we will provide some preconfigured OS bundles for that
Which you can with Vagrant locally
Or install to new VPS instance on any hosting
Let me show you, how it's configured in our team
As I said, when developing, you run SourceJS locally
And after getting some tasks done
We just commit our spec file changes in seperate spec repo (user folder)
From which, our remote, production server pulls all changes by cron or git hooks
And with this deploy scheme, we can easilly sync local changes with common SourceJS instance
Which is always up on our internal sever
This could also be done with any hosting or any common computer.
Production environment uses the same version SourceJS instance, 
With only difference in NODE_ENV global variable
Of course you can use any alternative to Git pull from remote by cron
such as FTP deploy :)
Now let's see how development in SourceJS looks like
Here you can see engine sources, that yeoman downloaded and inited for us
This is where engine code is placed
And in `user` folder we have own workplace, where your and you team specific content is placed.
`user` folder is in .gitignore by default from SourceJS core
Which means, you could setup there another repo with your specific setting and specs
With this structure, you can work with two repos in same project, or just with own contents repo
SourceJS repo is only needed if you would like to improve some core features and make some new Pull Requests
But in most cases you will only work with your `user` repo
We're trying to organise SourceJS structure in a way
where you don't need to change any core source, as you interact with abstract client-side framework
So all core features are easily configured right from your `user` folder
Developing both specs and engine core, we could test both parts in one instance.
Leaving all specific features far away from core
Main engine architectural feature is to provide configuration possibilities for any part of SourceJS
You can also turn off some core modules, as easy as adding new plugins and your custom features.
In next hour I will show how it works, and will provide some demos with official SourceJS plugins.
Returning to our file structure, here we see our working directory
And here is a specs catalogue, that comes as stub aside to documentation
Urls in engine are the same as file structure starting from `user` folder
So lets create new IDEA (IDE) project
As in any IDE or text editor, I create new worplace
Most of our team is using IDEA or Webstorm IDE for development
As IDEA among many other features provides good tools for working with multiple Git repos
Skipping that, we will just create simple workplace on our `user` folder
Want to remind you that
using SourceJS, you don't need to change it's source code
all you need is to manage your specs in `user` folder.
From which, you won't be able to break something in SourceJS core, except from options.js.
Here's our specs catalogues, and stub page
Lets rename stub spec name to
"button", like we're creating new button spec.
Spec contents is located in special index.src files
Which have basic templating from the start, using EJS
You can define any desired template for any type of index.src files.
You also can use regular index.html files, insted of `.src`, without any templating.
Any spec files could be processed with custom middlewares, as SourceJS plugins
For example, realising markup support, you templating with your custom engine.
What we see here, is basic spec markup
All markup features are described in docs 
At Spec Page documentation section
As you see, SourceJS is bundles with many content elements like warning boxes
some special styled links and etc
So how does SourceJS dev workflow looks like:
Every new developed component, that we need to make
we develop those right in index.src files
placing every spec in desired catalogue on file system.
as we see button spec, placed in Specs catalogue.
All demo code of real component, must be placed in .source_example block
From where it will render the same as in your master app.
Using styles, images and script from that master app.
Let's add some basic HTML for our button
We will use basic bootstrap button for demo
By the way, in nearest future, I will make more demos, based on bootstrap components.
Right after 0.4 stable release.
Lets copy this example HTML from Bootstrap documentation
And let's see what we get in our SourceJS wep app.
One moment till new spec will be synced to our documentation, in locally running Source.
In dev mode, navigation is now synced on entering main engine page.
And in production mode with cron task, integrated in the engine.
Now we see our updated link to newly created `specs/button` path
And here are those Bootstrap button, we used.
Basically, this is how SourceJS dev workflow looks like
All HTML is placed in .source_example blocks
And CSS is connecter from our EJS temples to every spec in the engine.
Here's where `project.css` is linked in our template
From which you could import any CSS files you want, as we have imported Boostrap file for demo.
This `project.css` files is used just for the demonstration purposes.
In your case, you can link any files from spec template.
For example, we're connecting all our OK.ru website styles, so they affect every spec page in SourceJS.
In same way, you can link any script files to all specs, of to specific ones.
As for SourceJS engine styles, they are organised that way, so any of them wont affect .source_example block contents.
So custom link styling and other SourceJS UI elements are strictly styled with specific cascade and custom class names.
In index.src, we could make as many .source_examples blocks we want
We could add as many sections we want, for example, lets take another Bootstrap component
like navigation element with dropdown.
Every code section and examples represents some component modifications and demos.
And test those right the way on a single spec page.
That is how spec page development loos like, whic you create in any number you want.
The best part of it, is that this is simple HTML page, 
on which you could add any custom CSS, JS and HTML for your components.
A bit late, I will also show how this is organised in our team.
In this demo case, we use regular HTML for .source_example's
without any custom templating on it
but it's not very convenient for user in real world.
I just showed you the basic idea of how it works, and suggest you to start from basic stem in learning SourceJS workflow.
In more ideal way of developing components in SourceJS
Among CSS, that is taken from your main project (master app), we also need to use common temples from it.
Recommended final process must look like this
We have SourceJS engine
and master-app, which is your framework or main website.
Where SourceJS is like a helper, and companion app on top of your resources.
SourceJS must only contain description of your Front-end components
without any of your HTML and CSS resources.
They only must be connected directly from master-app.
So lets proceed to the next steps...
Let me first check some questions from the chat.
Great news, some fellow wrote that they solved their Windows problems with Source.
I hope I somehow help with that, during the demo.
And don't forget about Github Issues.
As we don't have any more questions yet, let's proceed further.
So we done with SourceJS dev workflow.
Let's now check the plugins that I mentioned.
We remember that modularity is core feature of the engine.
And adding new plugins is also as simple as is could be
I will now show you released for todays demo official SourceJS plugins.
You can find a list of plugins in docs section at Basic Engine Documentation page.
In the bottom Plugins section
Here we see only two official plugins, that are mentioned for now.
Both of those plugins has installation instructions and feature description in seperate repos.
And with new structure, presented in 0.4, installation is made in few simple commands.
As we see in instructions, we need to `npm install` this plugin in our `sourcejs/user` folder.
In current case, we will install Spec Status plugin
Copy the install command from plugin README, and run it in specified folder.
All plugins will be published to npm with `sourcejs-` prefix
and as with Grunt, Gulp plugins, those modules will be easy to find.
As we se in installation docs, we need to run `grunt update`,
in root SourceJS folder.
I will stop running application,
`grunt update` generates new options for SourceJS client side
And another thing, for installing specific plugin, as it needs CouchDB dep, which doesn't comes pre bundles for now.
As this, and some other plugins might be asking them, we need to do come more configuration on that.
After installing CouchDB on your machine, you'll need to add custom options for it, with path to your couch server.
All options are placed in `user/options.js` file, as we see in instructions.
Lets copy stub config from readme, to our options.js file, located in `user` folder.
After init, we got stub options file.
As we see, we need to configure assets section in options.
I will use our common CouchDB server for config
You also could use some common place, or just serve it from localhost.
