Author: Jai Pradeesh

This author has written 4 articles

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 Commit the changes so that you don’t lose the data when container exits 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.

Continue ReadingDockerizing sTeam

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…

Continue ReadingGSoC 2015 with FOSSASIA – Mid-term report

[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 Private Workarea 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 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. 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. Navigation between rooms #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…

Continue Reading[Second Draft] Designing a document based collaboration interface

[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. 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. 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. 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…

Continue Reading[First Draft] Designing a document based collaboration interface