This post will take you through some interesting work that I have been doing for my project under FOSSASIA. This project is being done under the google summer of code platform. I have been working on various code scripts as my project is all about improving the tools of the sTeam collaboration platform. But this particular script is a command line interface that I am thrilled to work on.
If you are not familiar with what sTeam is, you can look it up here, sTeam
Let me start with how sTeam originally works for any user. This picture will give you a clear view about it.
If you are new to the sTeam platform, this script will take you through the sTeam commands and the interface, also making sure, you have fun in the process. It lets the user play with sTeam and get to know more about how it works. One other interesting concept that we have tried to integrate here is that of MUDs(Multi user dungeons/dimensions). Some of you may already be familiar with the concept of MUDs( others, please look it up here MUD). We have tried to bring the MUD kind of experience to this sTeam interface (like I said, thrilling!).
I have seen people go through a lot of tutorials on git, and the commands(sometimes complex) through which it operates, and yet, people have difficulty learning it. What if it had a MUD type of interaction, which would just let you type “create file” “commit file” “get commit content” “upload file” “rename file” “goto repo”, etc. Wouldnt it be much easier that way? Well, sTeam is going through all the extensive tool development so that it can make a user-friendly interaction. Here are some screenshots of this interface,
This interface is under heavy development and plans to make sTeam more and more interesting for its users. If you have any questions on sTeam, please feel free to contact me, or join us on our daily scrum meetings on IRC (#steam-devel) or join #fossasia and ping us with a question.
If you are looking for a open source project and want to contribute to FOSSASIA, Please have a look at FOSSASIA labs.
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
So, while I was browsing through various developments in Pharo, I came across a very eye-catching paper on Bootstrapping Reflective Systems: The case of Pharo .
For beginners, Bootstrapping is basically the process of writing a compiler or an assembler in the source programming language in which it is intended to compile. Applying this technique leads to self-hosting compiler that proceeds without external input.
Though, I am still a newbie and in the process of grasping all this ingenious stuff.
But I am sure that this paper ( Poli12-BootstrappingSmalltalk-SCP ) by G. Polito , S. Ducasse , L. Fabresse , N. Bouraqadi , B. van Ryseghem would make for an interesting read.
Do scan through it and post below your ideas and queries !
According to the same-origin security policy, web page can freely share images, stylesheets, scripts… but web fonts and AJAX requests are only accessible from the same domain.
Sometimes this is not desired behaviour, such as when getting a json / xml file from a different domain, using AJAX. In such cases, it all comes down to two solutions :
1- The source sets its header to allow specific domain cross-origin resource sharing (CORS). In PHP, this is done with header function :
2- Use JSONP.
JSONP is short for JSON padding, a well-known “workaround” to solve CORS. It only works with GET.
To send AJAX requests using JSONP, the server must first knows how to respond to JSONP requests. It usually detects JSONP requests using callback parameter.
<?php// compute result
[...]// output result
JsonpHelper::outputXML($result);// json helper class - credits : @andibraeu
classJsonpHelper{privatestaticfunctionis_valid_callback($subject){$identifier_syntax='/^[$_\p{L}][$_\p{L}\p{Mn}\p{Mc}\p{Nd}\p{Pc}\x{200C}\x{200D}]*+$/u';$reserved_words=array('break','do','instanceof','typeof','case','else','new','var','catch','finally','return','void','continue','for','switch','while','debugger','function','this','with','default','if','throw','delete','in','try','class','enum','extends','super','const','export','import','implements','let','private','public','yield','interface','package','protected','static','null','true','false');returnpreg_match($identifier_syntax,$subject)&&!in_array(mb_strtolower($subject,'UTF-8'),$reserved_words);}publicstaticfunctionoutputXML($string){# JSON if no callback
if(!isset($_GET['callback']))exit($string);$string=str_replace("\n"," ",str_replace("'",'"',$string));# JSONP if valid callback
if(JsonpHelper::is_valid_callback($_GET['callback']))exit("{$_GET['callback']}('$string')");
# Otherwise, bad request
header('status: 400 Bad Request', true, 400);
}
}
Line 29 is dedicated to replace all single-quote characters to double-quote, and new lines to simple space. This is to be able to pass xml document as valid javasript string parameter.
Then, the client can use jQuery to get the document from a different domain (it works on same domain as well, which is convenient for testing & development) :
1
2
3
4
5
6
7
8
9
$.ajax({url:source_url,dataType:'jsonp',// if dataType is set to 'jsonp' // a 'callback' parameter will be appended to the request urlsuccess:function(data){$data=$($.parseXML(data));items=$data.find('item');}});
Something worth noticing on the client side is on line 5 : the data needs to be converted to xml first, with $.parseXMLbefore converting to jQuery object. Converting the result string directly to jQuery won’t work : $data = $(data);.
This post aims to provide a basic overview of what PharoLauncher is and give a step-by-step approach on how to use this application of great advantage.
Overview
Pharo is an open source implementation of the programming language and environment Smalltalk. Pharo is not Smalltalk. Pharo is Smalltalk-inspired.
Pharo offers strong live programming features such as immediate object manipulation, live update, and hot recompilation. Live programming environment is in the heart of the system. Pharo also supports advanced web development with frameworks such as Seaside and more recently Tide.
The official Pharo website defines it as: ”Pharo is a pure object-oriented programming language and a powerful environment, focused on simplicity and immediate feedback (think IDE and OS rolled into one). ”
Pharo relies on a virtual machine that is written almost entirely in Smalltalk itself. Pharo environment is its own little world, designed around a conception of a computer with a minimal operating system and populated with living objects. A Smalltalk implementation is composed of an image (binary code), a major source file and a ‘changes’ file. The image is called Virtual Image (VI) because is independent of the platform you use for running Smalltalk. Smalltalk systems store the entire program state (including both Class and non-Class objects) in an image file. The image can then be loaded by the Smalltalk virtual machine to restore a Smalltalk-like system to a prior state.
As Pharo is open source, it growing rapidly owing to the contributions of people all around the world. Each day we have a new update of the image of Pharo which makes it cumbersome to keep track of updates. It becomes quite a task when one has to download a new image seperately each he/she plans to work on something having the latest issues fixed, new features added etc. That’s where the PharoLauncher comes in the picture. Pharo Launcher, a cross-platform application that
lets you manage your Pharo images (launch, rename, copy and delete);
lets you download image templates (i.e., zip archives) from many different sources (Jenkins, files.pharo.org, and your local cache) and create new images from any template.
The idea behind the Pharo Launcher is that you should be able to access it very rapidly from your OS application launcher. As a result launching any image is never more than 3 clicks away. “PharoLauncher” is useful to a user who develops and needs to constantly switch between images. PharoLauncher is also a very handy tool to download specific image update versions if you want to reproduce or fix Pharo bugs.Pharo Launcher is a Pharo-based application allowing you to manage a list of images (download, rename, delete) and switch between them without aditional tools.
Downloading/Installing PharoLauncher
As discussed earlier about the rapid evolvement of Pharo , kindly check out http://www.pharo.org/download to get the latest download/install instructions for Pharo Launcher.
If you don’t have the add-apt-repository command, install the software-properties-common package and try again. If you are on a server (no GUI), you can get a Pharo Virtual Machine by installing pharo-vm-core.
On Ubuntu, the Launcher is installed as /usr/bin/pharo, so you can type the following command on the terminal to start the Pharo Launcher.
Launch the Pharo launcher image using the platform-specific VM. The image below depicts how a PharoLauncher looks like when it is opened.
The screen displayed initially has been divided into two parts.
The left part ‘Existing Images’ displays the images already created by the user. Initially after the installation the left side with local images is empty. Whereas the the right side is the ‘Templates’ section which displays the image templates from various resources available for download from the internet. The ‘Existing Images’ section has 3 buttons : Launch, Delete and Refresh. The ‘Templates’ section has 2 buttons : Create Image and Refresh.
At the bottom of the launcher we have the buttons for quit and settings.
Select the image you wish to work on from the list and the sources provided in the ‘Templates’ section and download it. For instance you can download “Pharo4.0 (beta)” from the options provided which is the latest image as of today. By clicking on the ‘Create Image’ button at the top right corner.
Note that also the images from contribution CI are available. So you can easily download “Artefact”, “Moose”, … images according to your choice.
It will download the image into a specific directory somewhere in your users home directory. Each image gets an own folder. Use the “Show in folder” menu item to open this location.
The location of the images can be changed through the ‘Settings Browser’ option located at the bottom-right corner. Go to the ‘Open Settings’ > ‘Location of your images’. Now enter the desired path in the place provided as shown in the figure.
After ‘Creating an image’ , a dialog box appears which asks you to give a name to the image as shown in figure below.
After entering the suitable name , the image is displayed in the ‘Existing Images’ section.
To launch the image, simply select your option and click on the ‘Launch’ button located at the top right corner of the ‘Existing Images’ section and voila ! You have the pharo image of your choice running with the name of your choice.
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.
The intended “searchQuick” (sQuick) is an application to enable a user to search a set of books or texts, like an encyclopedia, or some other topical book collection offline built in the open source platform Pharo 4.0.
After indexing the content and the next task that was covered was searching for the user input string. The #queryString: does a fantastic job as of now.
The search results were printed in a scroll-able pane by iterating through a loop so as to cover each and every existence of the desired string. The search results window also enables the user to view the content of the chosen file.
Search Results Display
Acting on the suggestion of my mentor, I have also loaded the Pharo image with text versions of large books (Thank You Project Gutenberg 🙂 ) to test the working of the search function.
UPCOMING
GUI Modification
Integrated Exhaustive Testing
Addition of help/tutorial
PS: The GUI of the application is under constant evolvement, Kindly ignore the poorly structured window 😛
Stay tuned for more… Post any queries , will be happy to help 🙂
Hello, during the last weeks we have been working on Knitlib and Knitpat, a knitting machine control library and a standardized format that allows for exchange and storage of patterns.
In order to achieve a common platform for knitting machine development we have the need to abstract away implementation details that can difficult the generic usage of the lib, while keeping extensible and powerful control features. Among the most important abstractions developed for Knitlib is the Knitting Machine Finite State Machine, an abstract representation of the procedures needed to operate a knitting machine.
The architecture of Knitlib allows for easy integration of different knitting machine plugins for varied use cases, hardware, and software protocols. All functions of the plugin are non blocking except for .knit(), which is blocking due to the physical interaction needed in order to execute this command. To ease usage and to enable more versatile behaviour from the .knit() function, without limiting the interaction facilities needed for operation, the callback infrastructure allows for blocking and non-blocking callbacks from the Plugin to the machine operator (the Knitlib client), such as Information, Warnings, Error Notifications or Mechanical Required Actions (moving spools, switches, needles, etc). Callbacks abstract away the notification and interaction paradigms from the plugin, allowing for simpler behaviour, a more elegant design and ease of testing. Callbacks also allow for future plugins to not take care into implementing user interfaces, but to focus on functionality.
The pending remaining challenge is to standardize configuration options, flags and settings in order to allow for UI that respond to each plugin requirements and options, and to specify which features are supported on each machine plugin. Insofar, most of the standardization has been done on Knitpat, but some specifications such as physical resource assignation (Serial Ports, input streams, etc) are still to be implemented soon.
Thank you, and I hope this article helps you to understand the software architecture and design patterns of the implementation of Knitlib.
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, ..
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
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.
My FOSSASIA project is taking a big transitioning step from the starting plan. In milestone 3 and 4, rather than focusing on statistical retrieval and API documentation wepapp, my mentors – Mario (@mario) and Andreas (@andibraeu) are guiding me towards integrating fossasia api data in other services. The main goal remains the same though : getting more people to use and to know about the API.
Integrating our set of data into external services can be tricky, but this is also what makes the task so exciting. Currently, we’re already started the integration process into loklak, a distributed searching & harvesting server. You can find out more about loklak via their well detailed about page. But the plan doesn’t stop there. We’re targeting popular web platforms : WordPress, Drupal, Github Pages.. so that users can access our data with ease, and use our services / plugins in their websites within simple steps. That would be a big win for us, so I’m very impatient to get going with the code to brings these ideas to life.
You must be logged in to post a comment.