Webapp

Read more about the article Update of Python Runtime in Meilix

Update of Python Runtime in Meilix

Meilix Generator is a webapp uses flask with Python, Werkzeug, and Jinja 2. It triggers Travis to release in an ISO. It is deployed on Heroku. An older python version caused the webapp to load very slowly and it also become unsupported so there was a need to update the python version. In this blog post we walk through the update of Python in the project. We can specify an explicit version of Python to be used to run your application. For example, if you require Python 2, add the following to your Pipfile: [requires] Python_version = "2.7"   Then run $ pipnv lock to generate Pipfile.lock and push to Heroku. Another way: If we are using pip, we can supply a runtime.txt file. $ cat runtime.txt python-3.6.1   Building of the webapp (Example) The webapp build in Heroku and provide us a log. The log presents the packages installed and its version. Log also shows if any newer version is present for the package. While building webapp, we get this as a log: -----> Python app detected ! The latest version of Python 3 is python-3.6.5 (you are using python-3.6.1, which is unsupported). ! We recommend upgrading by specifying the latest version (python-3.6.5).   This confirms that we need to update python version and so thus we edited the runtime.txt Now building the same webapp, we get: Python app detected -----> Found python-3.6.1, removing -----> Installing python-3.6.5 -----> Installing pip   It already using older python, so it need first to remove the older version and then it install the latest one. The same implementation can be seen in the history. Reference: Flask - The Microframework Heroku Python Runtime

Continue ReadingUpdate of Python Runtime in Meilix
Read more about the article Adding Features into Meilix Generator Webapp

Adding Features into Meilix Generator Webapp

Meilix Generator is a webapp generated in FOSSASIA which takes input from user and send it to Meilix to trigger a build. Then a release is made whose link is emailed to the user. The webapp contains a form where there are fields for installing a particular packages, etc. In the following we will discuss about the ways to achieve the configurations in Meilix ISO without even touching the Meilix repo. For adding an option in the webapp: Editing the frontend We need to edit this line in the index.html with this line: <input name = "GENERATOR_package_vlc" type = "checkbox" value = "vlc" id = "vlc">   Making the script Then we have to add a script in the script folder. This script is called by Meilix build script. This script contains the variable “GENERATOR_package_vlc”. We name this file vlc-package.sh Content: #!/bin/bash if echo "$GENERATOR_package_vlc" | grep -q vlc; then sudo apt-get install -q -y vlc; fi   Line 2 checks that the vlc is checked in the checkbox or not, if it is checked then the other next line gets executed otherwise not. Calling the script from Meilix (needs to be done only once) We will add a line in the Meililx build script to call those script present in the Meilix Generator repo. SCRIPT_URL=https://www.github.com/fossasia/meilix-generator/archive/master.zip wget -O $scripts.zip $SCRIPT_URL unzip scripts.zip SCRIPTS_FOLDER_IN_ZIP="meilix-generator-master/scripts" ls $SCRIPTS_FOLDER_IN_ZIP; do $SCRIPTS_FOLDER_IN_ZIP/script; done #execute all scripts   Setting the URL via travis build config post to get all the values starting with GENERATOR_ GENERATOR_ = request.form['GENERATOR_']   So overall the abstract of the idea is: Getting the variables from html to travis as environment variable Cloning the meilix repo Executing all the scripts present. References: Request HTTP Python Online Installation media  

Continue ReadingAdding Features into Meilix Generator Webapp
Read more about the article Implementation of Features in Generator UI

Implementation of Features in Generator UI

In the early stage of development, Meilix Generator only has wallpaper and event name customization. But today the webapp has bunch of customization and features list which enables an user to design its own customizable ISO. Iteration in the form Meilix Generator came across several changes in the form throughout the time. At starting we only have an email part where the ISO get mailed, a name for the event so as to distinguish the ISO image and an image upload which will be set as the default desktop wallpaper in the ISO. Then the user gets a link which get activated after 20 minutes. Till then user have to preserve the link to download the ISO. Then we introduced a new field which contains event link and this link will be set as the homepage of the browser. And we change the basic UI of the webapp. At the same we implemented SendGrid to send the user the email link in their mail. This decreases the burden of carrying the downloadable link till the ISO becomes ready. Finally today Meilix Generator looks like this. It got some more customizable fields like providing default search engine, bookmark enabling or disabling and packages to include in the ISO. It has a link on the footer from which the latest pre-build ISO can be downloaded instantly and another link which takes user to the releases page of Meilix. Reference: SendGrid Email Delivery Service SendGrid Email API

Continue ReadingImplementation of Features in Generator UI
Read more about the article Implementing Search Functionality In Calendar Mode On Schedule Page In Open Event Webapp

Implementing Search Functionality In Calendar Mode On Schedule Page In Open Event Webapp

The schedule page in the event websites generated by the Open Event Webapp displays all the sessions of an event in a chronological manner. There are two modes on the page: List and the Calendar Mode. The former displays all the sessions in the form of a list while the latter displays them in a graphical grid or a rectangular format.  Below are the screenshots of the modes: List Mode Calendar Mode The list mode of the page already supported the search feature. We needed to implement it in the calendar mode. The corresponding issue for this feature is here. The whole work can be seen here. First, we see the basic structure of the page in the calendar mode. <div class="{{slug}} calendar"> <!-- slug represents the currently selected date --> <!-- This div contains all the sessions scheduled on the selected date --> <div class="rooms"> <!-- This div contains all the rooms of an event --> <!-- Each particular room has a set of sessions associated with it on that particular date --> <div class="room"> <!-- This div contains the list of session happening in a particular room --> <div class="session"> <!-- This div contains all the information about a session --> <div class="session-name"> {{title}} </div> <!-- Title of the session --> <h4 class="text"> {{{description}}} </h4> <!-- Description of the session --> <!-- This div contains the info of the speakers presenting the session --> <div class="session-speakers-list"> <div class="speaker-name"><strong>{{{title}}}</div> <!-- Name of the speaker --> <div class="session-speakers-more"> {{position}} {{organisation}} </div> <!-- Position and organization of speaker--> </div> </div> </div> </div> </div> </div> The user will type the query in the search bar near the top of the page. The search bar has the class fossasia-filter. We set up a keyup event listener on that element so that whenever the user will press and release a key, we will invoke the event handler function which will display only those elements which match the current query entered in the search bar. This way, we are able to change the results of the search dynamically on user input. Whenever a single key is pressed and lifted off, the event is fired which invokes the handler and the session elements are filtered accordingly. Now the important part is how we actually display and hide the session elements. We actually compare few session attributes to the text entered in the search box. The text attributes that we look for are the title of the session, the name, position , and organization of the speaker(s) presenting the session. We check whether the text entered by the user in the search bar appears contiguously in any of the above-mentioned attributes or not. If it appears, then the session element is shown. Otherwise, its display is set to hidden. The checking is case insensitive. We also count the number of the visible sessions on the page and if it is equal to zero, display a message saying that no results were found. For example:- Suppose the user enters the string ‘wel’ in…

Continue ReadingImplementing Search Functionality In Calendar Mode On Schedule Page In Open Event Webapp
Read more about the article Implementing Logging Functionality in Open Event Webapp

Implementing Logging Functionality in Open Event Webapp

Open Event Webapp allows event organizers to generate an event website by providing JSON data in the form of a zip file or an API endpoint. The generation of event website is a multi step process and takes some time to complete. In order to see the ongoing progress of the process and catch any errors, logging feature is a must. The challenging part was to send the log messages in real time about the tasks being performed in the generator instead of sending it after some time when the task is already finished. To enable real time communication between the web server and the client, we use the Socket IO library. But before using that library for sending log messages from server to client, we have to design the architecture of the logging feature. The log statements can be of several types. It could be about the inception of a task, the successful completion of it or some error which occurred while performing the task. The log message object contains a field named type to show the type of the statements. We define three categories of logs messages:- INFO: Info statements give information about the task currently being performed by the webapp SUCCESS: Success statements give the information of a task being successfully completed ERROR: Error statements give information about a task failing to complete. These statements also contain a detailed error log Along with the type of the statement, the object also contains information about the task. For all types of statements, there is a field called smallMessage containing short information about the task. For the ERROR statements where more information is required to see what went wrong, the message object has an additional field called largeMessage which holds detailed information about the event. We also create a new file called buildlogger.js and define a function for creating log statements about the tasks being performed by generator and export it. The function creates a message object from the arguments received and then return it to the client under the buildLog event via the socket IO. exports.addLog = function(type, smallMessage, socket, largeMessage) { var obj = {'type' : type, 'smallMessage' : smallMessage, 'largeMessage': largeMessage}; var emit = false; if (socket.constructor.name === 'Socket') { emit = true; } if (emit) { socket.emit('buildLog', obj); } }; Most of the steps of the generation process are defined in the generator.js file. So, we include the logging file there and call the addLog function for sending logs messages to the client. All the different steps like cleaning temporary folders, copying assets, fetching JSONs, creating the website directory, resizing images etc have multiple log statements for their inception and successful/erroneous completion. Below is an excerpt from the cleaning step. var logger = require('./buildlogger.js'); async.series([ (done) => { console.log('CLEANING TEMPORARY FOLDERS\n'); logger.addLog('Info', 'Cleaning up the previously existing temporary folders', socket); fs.remove(distHelper.distPath + '/' + appFolder, (err) => { if(err !== null) { // Sending Error Message when the remove process failed logger.addLog('Error', 'Failed to clean up the previously existing temporary folders', socket, err); } // Success message denoting the completion of the…

Continue ReadingImplementing Logging Functionality in Open Event Webapp
Read more about the article Building a showcase site to display sample events and auto deploying them on each PR merge in Open Event Webapp

Building a showcase site to display sample events and auto deploying them on each PR merge in Open Event Webapp

Open Event Webapp generates static websites of the event fed to it in the form of JSON data. Earlier, we used to automatically deploy the FOSSASIA Summit event website on the Github pages of the repository on every merge of a pull request.  The presence of it helped in showcasing and testing purposes. But a single event was not enough. Events are diverse, taking place in a large number of rooms, h a variety of sessions and extending over several days. So, having multiple events on the showcase site and continuously showcasing and testing them was a really great idea. Here is the feature request for it. I will be explaining the major portions of it. The whole code can be found here First of all, we need to build the main index page which we will showcase our sample events. It will contain the small images of the event and on clicking them, the selected event will be opened. For displaying features and capability of the generator,  we have two separate sections of events: one having the single session page and the other having the expandable sessions page. There will be links to the other components of the Open Event Ecosystem like Android App generator,  Web App generator, Organizer App, and Eventyay. The contents of that page are kept in the overviewSite folder. It contains the event background images of the events and the main index file. The basic structure of the file is shown below. The whole file can be viewed here <div class="container-fluid bg-3 text-center"> <div class="row margin"> <div class="col-md-6 col-sm-12 col-xs-12"> <div class="row"> <h2 class="margin"> Apps with expandable sessions page </h2> <div class="col-md-6 col-sm-6 col-xs-12 margin"> <p><strong>Open Tech Summit 2017</strong></p> <a href='./OpenTechSummit/index.html' target='_blank'> <img src="./otssmall.jpg" class="" alt="Image"> </a> </div> </div> </div> <div class="col-md-6 col-sm-12 col-xs-12"> <div class="row"> <h2 class="margin"> Apps with single sessions page </h2> <div class="col-md-6 col-sm-6 col-xs-12 margin"> <p><strong>Mozilla All Hands 2017</strong></p> <a href='./MozillaAllHands2017/index.html' target='_blank'> <img src="./mozilla_banner.jpg" class="" alt="Image"> </a> </div> </div> </div> </div> </div> But, this is just the front end of the page. We haven’t generated the sample events yet and neither have we made any changes to make them auto deploy on each PR merge. The test script of the app which contains unit, acceptance and selenium tests runs on each PR made against the repo when Travis CI build is triggered. So, it makes sense to write code for generating the event there itself. When the test script has finished executing, all of the events would have been generated and present inside a single folder named a@a.com (We needed something short and easy to remember and the name doesn’t really matter). We then copy the contents of the overviewSite folder into the above folder. It already contains the folder of different sample events. Here is the related code. The full test script file can be found here describe('generate', function() { describe('.create different event sites and copy assets of overview site', function() { // Sample events are generated inside the a@a.com folder it('should generate the Mozilla All Hands 2017', function(done) { var data = {}; //…

Continue ReadingBuilding a showcase site to display sample events and auto deploying them on each PR merge in Open Event Webapp
Read more about the article Implementing Single Session Pages in Open Event Webapp

Implementing Single Session Pages in Open Event Webapp

Recently, we implemented a feature request in the Open Event Webapp which allows the organizers of an event to choose the style of the sessions displayed on the event web site. Before this feature of individual session pages was implemented, we had a single default style of displaying collapsible session elements on the page. A small preview of the session containing its title, type, name, position, and picture of the speaker(s) presenting it would be shown on the different pages. When the user will click on this session element, it would collapse showing detailed information about it. Before Clicking After Clicking on the first session element While this default behavior of collapse of session element on click (shown above) works well in most of the cases, it might not be apt in situations where the session contains a large amount of detail and a higher number of speakers presenting it. Single session pages would work better in that case. So, we provided an option to select it on the generator form itself. We provided an input field asking which session style does the organizer want? Is it the single session style or the expandable session? The organizer can then select one of them and the site will be generated according to that!! The whole work was huge and you can view all of it here. I will only be describing the major parts of it here. The first challenge was to make a template (handlebars) file for the individual sessions. This template would take a single session object as an input. The object would contain all the details about the session and after compilation during generation, a unique individual page for that session would be created. Here is the basic structure of the template. You can view the whole file here <div class="container session-container"> <!-- Contains all the information about the session --> <div class="row single-session" id="{{session_id}}"> <!-- Displaying the date, start and end time of the session --> <h3> {{startDay}} </h3> <div class = "eventtime"><span class="time-track">{{start}} - {{end}}</span></div> <div class="session-content"> <div class="sizeevent event" id="event-title"> <!-- Display the title, type and the track of the session --> </div> <div> <!-- Short abstract of the session --> {{{description}}} <div class="session-speakers-list"> <!-- Contains detailed information about the speakers of the session. Display their picture, show their position, short biography and social links links like Github, Twitter and LinkedIn --> </div> </div> </div> </div> </div> But the work is not completed yet. We have to check the style of the session selected by the organizer and if he/she has selected the single session option, then we have to pass all the sessions to this template file during the generation process and create the pages. If the mode selected is expandable, then we carry out the normal generation procedure. Else, we extract every session from the JSON data and feed into to the above template. Since the number of sessions can be quite large, we don’t generate them alongside the other pages like tracks, schedule, rooms, speakers and so on. Instead, we create…

Continue ReadingImplementing Single Session Pages in Open Event Webapp