Factories, Services and Controllers

week1gsoc1

So before I start the blog post, it is better if you know more about what sTeam web interface is and what are the capabilites of sTeam. Click here.

So what is a Controller ?

It is simply a a constructor function which is instantiated by AngularJS when it encounters ng-controller directive in HTML.

So what is a Factory ?

In Angular Js a factory is an injectable type which helps us in encapsulating repetitive logic.

How are they helpful for sTeam web interface ?

So as my first week of work started of for GSOC, the core concentration has been on primarily working with the controllers of the workarea and integrating them with the respective views. In an attempt i started of with adding a :

commentsCtrl

: Used for adding comments to the web interface

workspaceeditorCtrl

: Used for integrating textAngular to the web interface

Things apart, in a broader aspect here what should be understood is about how things should be implemented using controllers, factories and services. Let me illustrate how it should be properly done in angular js.

To start off

How are controllers really helpful in Angular and how should they be used ?

Generally we should understand that controllers responsible for augmenting the scope which is done by attaching models and functions to it that are subsequently accessed in the view. There are some things which are to be understood while writing controllers. Lets go one by one,

  • A Straight “No” for all the DOM manipulation. This must be achieved only with directives
  • If you are having a situation where you are about to write repeatable code, then don’t do it with controllers, instead encapsulate them in services.
  • If you are trying to expose the whole controller instance then it isn’t a good idea. In fact the scope object exists in order to clear separation of concern between controller and view .

So what about Factories ?

“Services, factories, and providers are all injectable types. We must understand that Factories in angular Js are just another example for an injectable type. It looks almost the same as Service but when it comes to implementation you can decide and determine what to instantiate and return from the factory”

scribes by hector | Akhil Pandey

Let me give you a small example before i wrap up, Have a look at the below image,

week1gsoc2

Observe broadcastItem, prepForBroadcast. If you look keenly essentially what i am doing there is creating an injectable type which enables me to change the message that which has to be printed depending on the broadcast item.

One more key thing about factories is that a factory can also depend on other services or factories. Also there is one more point to grab which is we are returning an object from the factory function, so we absolutely have the freedom to determine what should be the object which is to be returned, going further we can base it on certain parameters as well.

Thats it folks,
Happy Hacking !!

Google Summer of Code: A new beginning

I am working on sTeam under FOSSASIA for GSoC 2016. sTeam is collaboration platform. It allows users to form groups and share various kinds of documents. It provides a virtual knowledge space where users can meet and interact. These spaces are called rooms, these can contain various containers to store documents in an organized manner. The rooms are connected by gates to allow the movement of users and documents from one room to another. The most interesting thing about the project is that it is in pike programming language. This is not very commonly used and I will get to learn new things and myriad of experiences.



Now moving into the technical details of my project I will be talking about the first step in my project that is implementing TLS (Transfer Layer Security) Protocol, also known as SSL. Currently all the communication between the server and the command line client is over COAL protocol. COAL is a home grown protocol developed by the original developers of sTeam. Currently COAL does not use any kind of encryption. My first task will be to integrate SSL into COAL, so just like http becomes https COAL will become COALS. After this I will be working on the improving the client interface, which I will talk about in the coming weeks.


For now in the community bonding period I have been actively participating in the discussions on the IRC and working on stash, discovering bugs in the project and getting used to the interface and the code. Recently we received the guidelines for the summer from our mentors Martin and Trilok. The guidelines include clearly mentioned milestones and the tasks we need to complete. We will also be having a team meeting everyday discussing our day’s work and issues.



I would like to thank FOSSASIA for giving me this wonderful oppurtunity to show my skills. All the discussion during this period is just making me feel more professional and getting me excited for the summers. In programmers term

printf(“let the fun begin !”);

Dockerizing sTeam

I am currently working with sTeam collaboration platform as a GSoC dev under FOSSASIA umbrella.

sTeam has a lot of depencencies. A lot! One major issue faced by developers was version conflict between dependencies. Docker seemed to solve this issue. Docker is a great image distribution model for server templates. It uses btrfs (a copy-on-write filesystem) to keep track of filesystem diff’s which can be committed and collaborated on with other users (like git). It also has a central repository of disk images that allow you to easily run different operating systems and shares the host kernel.

In this post, I will explain the workflow of containerizing sTeam with Docker.

Prepend sudo

  • Install docker on host system, start & enable the docker.service
dnf install docker
systemctl start docker
systemctl enable docker
  • Pull a base image from docker hub

Note: It is upto you which image to use. I am using Ubuntu as base image.

docker pull ubuntu:latest
  • List the images to verify the pull
docker images

.. should display ubuntu latest xxxxxxxxxxxx x months ago x MB

  • Build your own image
docker build -t="dolftax/steam"
  • Lets run bash to install sTeam itself and its dependencies
docker run -t -i dolftax/steam /bin/bash
  • Install the packages and its dependencies.

In my case, sTeam server. Installation steps –https://github.com/societyserver/sTeam/wiki/Installation-steps#manual

  • Grab latest container ID. The first one would be the recently closed container.
docker ps -a
docker commit [container-id] dolftax/steam:v1

You should get a long hash as the success message

Note: v1 is a tag Don’t use latest tag. Don’t be tempted by it.
  • Create a docker hub account and login
docker login

.. which is self explanatory.

  • Push the image to docker hub (Before that, create a docker hub account anddocker login)
docker push dolftax/steam

Done!

.. after containerizing with docker, sTeam installation is as easy as

docker pull dolftax/steam:v1

Try containerizing your project and you would love it.

Improve the command line tools of the sTeam collaboration platform

First of all, I really thank Google for organizing such an event for students in the summer and I am fortunate to be a part of such a program. I would also like to thank FOSSASIA for accepting my proposal for the project and for providing me with the experience of working with them.

When you see your name on the list

Name on the list? Google’s server being stacked up with lots and lots of request, Students impatiently clicking the refresh button to see whether their names are present in the list, a lot of students, a lot of projects, and suddenly, that one refresh, when the list loads with the projects matching the student names. (CTRL+F) ”Trilok Tourani” and there it was,

  • Organization : FOSSASIA
  • Project : Improve the command line tools of the sTeam collaboration platform
  • Student : Trilok Tourani
  • Mentors : Martin Bahr(Working mentor) , Chris Angelico, Aruna Herath, Markus(Backup mentors)
  • Status : Accepted

Dumbstruck for a minute, but when it hit me, that I got selected, the happiness was beyond what I had expected. I went on the IRC and thanked my mentors. All I knew was I had a project in hand and a long way ahead to perform beyond their expectations.


About the project

What is sTeam?

sTeam is a collaboration platform which helps people to share their documents, chat with them, have a look at their virtual workarea, and ease the sharing/developing in big groups. You can also look at the current development on the sTeam web interface here. It is still in the development phase, so please feel free to provide us with any ideas to improve. To know more about sTeam, please visit societyserver.

sTeam is completely built on pike programming language. To know more about pike programming, please visit Pike. If you already know about pike, and are good at it, please visit Fossasia’s IRC channel #fossasia and ask for tasks/bugs on this project to solve right away. If you are looking for something other than sTeam, FOSSASIA has a wide range of projects in various fields, and also welcomes any new project ideas.


My part of the project

I would like people to know the kind of work that I am doing currently for sTeam and show them how interesting it is to develop for it.

My project is to develop the command line tools to ease the work for the developers, and people who choose to work with command line, over a web interface.

These tools include,

  • Exporting your documents to your Github repository with just a command.
  • Importing document from Github right into sTeam for people to see.
  • A easy to use debug client that helps you while developing for this platform, or to see the various documents/containers you have in which room, move them, copy them, use them, all with commands similar to the Linux command line.
  • A way of to edit your documents directly with command line editors, without having to go to the web, type in the url, clicking on a document, and then finally editing it.
  • Chat with your friends/group members over the IRC.
  • and more being added to the list….(Please contact us if you have any)

These tools are already built up, but with more development, they will be very efficient and easy to use commands which a normal user can type in and get things done, and this is where my part comes in.

For some of these tools, which are already built, some development is needed. While some other tools, I have to develop by myself and enhance the command line usage for sTeam.

These are few of the commands with their screenshots to help you understand exactly what these tools are meant for,

The sTeam debug client

The editing documents client,

and edit the document in a simple command-line editor (used vim here),

Exporting documents from sTeam to git (version-wise)

Importing documents to sTeam from git (version-wise)

If you really like what I am doing, or are interested in developing for sTeam, please join our IRC channel #fossasia or join fossasia@googlegroups.com .

If you are looking for some other project, FOSSASIA has a lot of projects to be worked on. Please visit FOSSASIA for more info.

GSoC 2015 with FOSSASIA – Mid-term report

TL;DR No Chicken Little, the sky is not falling.

Well. I’ve been selected for GSoC under organization FOSSASIA and I am working on the project sTeam Collaboration platform, mentored by awesome guys Martin and Aruna.

It is mid term already and as planned I am half way through the project. If you haven’t seen my past blogposts, go check them out to get clear idea of the project.sTeam is a document based collaboration platform. There is already an existing web interface for the platform. Interestingly REST APIs are being developed for the same and we planned to rewrite the web interface with AngularJS and make calls to the REST APIs.

Technology stack

  • bower for easy management of external modules. There are a lot of sub modules which are to be loaded and are not part of the angular itself. Though, some of the modules are bloated. The unnecessary files will be removed by using bower prune task with gulp.
  • angular-ui-router for handling deep nested routes. Interesting thing is, angular-ui-router works on state based concept and is very handy to maintain and route to certain state.
  • angular-ui-bootstrap gives us easy to use, clean and responsive UI blocks.
  • angular-local-storage We use it for saving the user’s login credentials and are sent to the API with every REST based call. This would be changed in future and session maintenace should be developed.
  • textAngular is lightweight and two way bound WYSIWYG Text Editor for handling plain text files. It can also handle source code, markdown, etc ..
  • ng-audio and ng-video for viewing audio and video files respectively.

Views

  • login and workarea are two base templates. And the router loads one of these based on the login credential value stored in local storage.
  • With workarea as base template, at this level, two nested views. Groups, which displays the groups which the user is part of and Private, where the user’s private documents are displayed.
  • The options view has various options like, permission management for the current level, copy, link, etc.. and also create room and document modals.
  • comments view fetches the comments for the current path. It is hidden if no permission to comment.

Controllers

  • loginCtrl for passing the credentials to the API, authenticate and parellely store them in localStorage. And all the other calls will use the stored value along with its payload. You know, REST is stateless! Session management is scoped to the API and is planned for future.
  • handler has functions for CRUD operations on the API. The functions do GET, PUT, POST, DELETE, .. on the passed paramater (which is the path to the room/document) and will return the value.
  • router handles the routes. It has base states with views loaded into each states with its own templates and controllers.
  • The run methods load are used for state change control.
  • workareaCtrl handles the scope for options loading and current level display in breadcrumb.
  • workspaceCtrl fetches and controls the main workspace which has the rooms, documents and containers displayed.
  • config has the hostname where the sTeam is deployed and change here is reflected systemwide for easy deployment.

Road ahead

  • Depending on the type (room/document), the appropriate view should be loaded and when document, the viewer/editor wrt to the mime type should be loaded. Follow the issue here – https://github.com/dolftax/sTeam-web-interface/issues/10
  • Implement search, document/room sorting based on Author, Title, document type and date.
  • Setup right sidebar which lists all the rooms (for easy navigation).
  • Settings popup for changes to attributes of the objects.
  • Automate tasks with certain gulp modules – gulp-angular-templatecache, gult-concat, gult-lint, gulp-uglify, ..
  • Write unit tests with mocha and chai.
  • Tidy up and add more documentation, which is already being done here –https://github.com/eMBee/sTeam/wiki/Installation-steps

Apart, we do scrum meet everyday. Check out the logs – http://dpaste.com/2A3J121

Currently, node-static module is used to serve the app and our development server is hosted in azure – http://steam-web.azurewebsites.net/

Note: The project is heavily under development and things might break.

Sign-up API is not implemented yet. Find some of the working screenshots below

Login

Private workarea

Groups

Create room

Create document

Future plans

The REST APIs are under development and a lot of features are yet to be developed. I have a brief listing of the yet to be developed APIs and the list grows eventually as we figure out something is missing.

Thats all for now. Will get back soon!

[Second Draft] Designing a document based collaboration interface

.. this post is the continuation of my first draft which you could find it here –http://dolftax.com/2015/04/Designing-a-document-based-collaboration-interface/. I would ask you to go through the first draft before proceeding here, because here I’ve explained only the wireframes which are modified/tweaked, based on the comments on the first draft. This post is structured as /me resolving the comments on my first draft, with the new wireframes and explaining the reasons for modification.

Rooms could be nested

#1 : We could not enforce a topic/subtopic structure because rooms can be deeply nested. Topics and subtopics are all rooms. The users are free to organize the rooms as they wish. They could be topics, they could be something else. At every level, there may be documents and more rooms.

=> Removed topic/subtopic structure. As the rooms are completely nested, a room could contain any number of sub-rooms. Rooms and documents are analogous to folders and files. But wait, there are containers which are multi-part documents. To get the clear idea of what we mean by containers- refer to the discussion we had IRC log –https://tr.im/UOZpT

Shared and Private workarea

#2: The basic elements in sTeam are users, groups, rooms and documents. Each group has a workarea connected to it, and each user has a private workroom. Each user is a member of at least one group. So when a user enters the server, there are at least two rooms: the users private workarea, and the workarea of the group, that the user is a member of.

=> Workarea implemented. Under shared workarea, the user will get list of all rooms and documents which he got access to. Under private workarea he would get list of his private documents and rooms, which when shared will move to the shared workarea.

Shared Workarea

Shared Workarea - admin

Private Workarea

Private Workarea -admin

If you notice, you could create a room or document only in your private workarea. When you change permissions for a room/document in your private workarea, it would be pushed to shared workarea automatically.

Permissions are inherited

If a room has rw permissions, then everything inside the room also has rw permissions.

Room view – Level two

Room View - Level two

Notice the settings icon? Except for the first level, (levels are tracked by the level/stage bar) a user could change room/document attributes with the help ofsettings icon which pops up a window with following options.

Settings pop

The settings option appears only in the levels inner to level 1, because obviously, if the user is in the first level, he is not into any room.

#3: The user can move from room to room. The server keeps track of where the user is, and actions taken (such as creating a document) are relative to the users location. Users can pick up documents (the document is moved from the room, to the user itself), move to another room and drop the documents there.

=> When a document is selected, the copy and paste buttons (look at the above wireframe. buttons next to sort options) are activated. Clicking copy would copy the selected document, and allows you to paste it in any room (where you got access to) until the end of the session. Navigation between rooms could be done by clicking << button. It would popup the navigation sidebar on the right.

Sidebar Right

Also, if you wish to join any room, use the search bar. It would fetch you the list of rooms. Some rooms will not allow you to access the documents. Click on the user request icon next to room name, which would notify the room admin. When he gives you access, the room/document would be displayed in your shared workarea.

Search Results view

Search Results

Permission table

#4: A user should be able to insert objects without read and write permissions. One example where this is needed is to send your homework to your teacher. You get permission to insert into the teachers room, but once it’s in there, you can’t read it or write it anymore. It allows far more fine grained permissions than a unix system.

=> A permission button has been added to the ‘onClick of a Room’ view which will be available for the room admin and you.

In room view - Admin

For an admin, the permission table pop-up would look like the below wireframe (which is self-explanatory)

Permission table popup

Minor tweaks

Room sidebar removed

The room attached sidebar options has been moved to the settings popup. A detailed view of a room in any level would look like,

Room Detailed

Document View

In document level view, the following options are added,

  • Workarea bar
  • Delete document option (If access permits)
  • Permissions button

Document View

Guest view

A guest (who is not logged in) could view the rooms/documents. The view for a guest would look like,

Guest room view

PS: No changes have been made to Create room and Create document pop-ups.

Let me know what you think!

[First Draft] Designing a document based collaboration interface

This post is about my way of approach to develop User Interface for a document based collaboration platform. The Ideation is based on Martin’s thoughts, which you can find it here – http://societyserver.org/Topics/sTeam/Interface-elements-for-Document-Management . I would ask you to read the post and be back here.

The structure lives and evolves. and so do the documents. – Martin

Alright, You’re back! The primary goal was not to develop a separate admin panel. Rather the interface adds up extra admin options based on the permissions given to the logged-in user (Maybe, admin).

When I say admin, it means the authorized user who has Read/Write permissions and guest stands for non-authorized user who has only Read permissions.

As quoted, everything here would be documents, of any type (images, plain text, source code, ..) They should be structured into hierarchies. The admin/authorized user should be able to add new room, able to sort by Title/Author/Date, able to Re-arrange the documents, implemented as drag and drop.

![Home Admin && User ](https://raw.githubusercontent.com/dolftax/dolftax.github.io/master/sTeam/wireframes/1.png)

Each room should have

  • Topic
  • Description
  • Keywords

and good to have various other attributes which might explain the room well. The admin has a sidebar which options to perform CRUD (Create/Read/Update/Delete) operations on a room. The sidebar is hidden for guest user. The wireframe below is detailed/zoomed view of a room in the above image.

![Room – Detailed View Admin](https://raw.githubusercontent.com/dolftax/dolftax.github.io/master/sTeam/wireframes/2.png)

Creating a room asks for Room specific information. If you look at the wireframe below, they are self-explanatory. Permission would be set at this level whether it could be Shared/Private.

Create room

On click of a Room/Topic opens up the sub-topics under the room. The listing could be sorted and searched. Communication, being one of the major element for collaboration would be of comments. The admin gets to moderate (Approve/Delete) the comments. At this level, the comments are room-specific.

![onClick of Room Admin](https://raw.githubusercontent.com/dolftax/dolftax.github.io/master/sTeam/wireframes/4.png)

You should have noted the >> on the right. It opens up a sidebar with Room/Topic listing which then nests into Sub-topic listing. These are the doors which helps the user for hassle-free navigation between rooms.

Sidebar navigation - Right

The sub-topic ( as same as Topic) has description, keywords and various other attributes. The sidebar of options and Add Sub-topic for admins to perform CRUD operations on them. The Sub-topic sidebar would be hidden for guest user.

Sub-topic Detailed View

Considering the hierarchy as a tree, the leaf node be the document. A document could be of any type,

  • markup-text (markdown, html, others)
  • xml, json, csv
  • source-code
  • image
  • audio
  • video
  • binary
  • object (instance of a script)

Displaying the content of a document in the browser would be based on the type of the document. Anything text based, images and videos are displayed. For other binary files or objects, only metadata is displayed (owner, date of creation etc). And binaries would have a download link. Comments at this level is document specific.

At any level, one should be able to navigate to any room/topic (or) sub-topic with the help of the right sidebar drawer.

The admin has the following options for each document,

  • Link
  • Copy
  • Edit
  • Curate (based on document type)

.. whereas guest would have everything else other than Edit.

Link icon pops up a list of Rooms (where the present logged in user has access to) which on click results in adding a link of the document to the respective room. Edit icon opens up the editor only if the document type is of something which could be edited in a browser. A complete document could also be deleted. The interesting part is to distinguish the documents based on the document-type, visually. TheCurate icon pops up the list of documents in the specific room which are of the same document type as the currently viewed one.

Document View - Admin

A document would be displayed like the below wireframe for a guest user.

![Document View User](https://raw.githubusercontent.com/dolftax/dolftax.github.io/master/sTeam/wireframes/10.png)

Creating a document asks for document specific information and feature for uploading the document. I assumed MIME-Type would be automatically detected. Else, an option could be added. Permission could also be set at document level.

Create Document

With that said, if you have any suggestions (or) if I’m missing something here, please start the discussion below. Note that these are bare minimum wireframes and therefore would be slightly modified during implementation.

UPDATE: Uh oh! I missed containers. Expect a bit of restructure in my next draft.

Cheers!