As discussed in my last blog about ticket ordering and positioning, in this blog we are gonna talk about how we implement the front-end part of re-arranging the tickets. We essentially do it using compute and methods of Vue.js. The functionality that is expected in the front-end is, the event organizer should be able to move the tickets Up or Down the order and save that position so that it gets displayed later in that very particular order.
Like I said above we use two main things of Vue.JS for this purpose – Compute and Methods.
Compute
We use this to get the sorted list of tickets based on the position key of the tickets and use this sorted list to display the tickets in the event editing wizard. Whenever you change the value of the position for a ticket, it automatically updates the list to sorted list again and hence the order of ticket in the front-end also updates. To add a compute function in Vue.JS, inside the new Vue() object creation, we add an attribute computed and inside that we put all the functions that we are gonna use. So in our case the function is sortedTickets . We make use of the sort function of lodash to sort the tickets array based on it’s position attribute.
Now while showing or looping over the tickets, we loop over sortedTickets rather than the original ticket array.
Method
This method is called when the button is clicked to move it up or down. This makes the calculations to determine the values of the position of the two tickets which are being re-ordered in a single click. To add a method, we do it in a similar way like computed but using methods attribute instead. The methods we have written to move tickets up or down is moveTicket.
It has 3 parameters – ticket, index and direction. So when this function call is emitted, depending on the button, the direction is either “up” or “down” while the other two parameters are the ticket properties of the particular ticket. So in this function we check the direction and accordingly update the value of position for the tickets involved in the arranging. As we update the position here, because of the compute, the UI automatically updates to show the tickets in the new order.
Finally after all arrangement is done, the position is always saved in a hidden input field which is then passed as form data and is saved in the database so that the position value can be used in other pages for showing the ticket in order.
Show Ordered Ticket
In other pages, while showing ordered ticket, we already receive the ticket array in sorted format based on the position key. Hence, we don’t need to worry about it in the front-end and it automatically is shown in the sorted order.
In an event management system there is a need for organizers to get speakers data from the system and be able to use and process it elsewhere. Organizers might need a list of emails, phone numbers or other information. An “export” of speakers and sessions in a CSV file that can be opened in any spreadsheet application is a good way to obtain this data. Therefore we implemented an export as CSV funtion in the Open Event Server.
Now the Open Event Orga Server allows event organizers to export a list of speakers and details about their sessions such as Session status, Session title, Session speaker, Session track.
The speaker csv includes details about the speaker such as Name, Sessions, Email, Status, Mobile, Organisation, and Position.
How did we implement it:
When clicking on the Export As CSV button on either of the pages it calls the download_speakers_as_csv / download_sessions_as_csv from speakers / sessions tab .
The Speaker’s Tab
Session’s Tab
The functions are defined in sessions.py file.
First we get data from the sessions table by event_id and the event details from event table :
sessions = DataGetter.get_sessions_by_event_id(event_id)# This is for getting event name to put as the filenameevent = DataGetter.get_event(event_id)
Then we go on with creating the csv file.
We iterate through all the sessions and find the speaker associated with each. We save each row in a new list named data and after each iteration add it to a main list .
main = [["Session Title", "Session Speakers", \
"Session Track", "Session Abstract", "Email Sent"]]
for session in sessions:
if not session.deleted_at:
data = [session.title + " (" + session.state + ")" if session.title else '']
if session.speakers:
inSession = ''
for speaker in session.speakers:
if speaker.name:
inSession += (speaker.name + ', ')
data.append(inSession[:-2])
data.append(session.track.name if session.track.name else '')
data.append(strip_tags(session.short_abstract) if session.short_abstract else '')
data.append('Yes' if session.state_email_sent else 'No')
main.append(data)
In the last part of the code python’s csv module is used to create a csv file out of the nested lists. The csv module takes care of properly escaping the characters such as punctuation marks ( like comma ) and appending a newline character in the end of each list .
Snippet of Code from sessions.py file
In the last few lines of this code section , you can see the headers being added , necessary for downloading the file on the user’s end.
The make_response function is imported from flask package.
make_response: Converts the return value from a view function to a real response object ( as documented here).
Open-event orga server provides the ability to the organizer to create a complete export of the event they created. Currently, when an organizer triggers the export in orga server, A celery job is set to complete the export task resulting asynchronous completion of the job. Organizer gets the download button enabled once export is ready.
Till now the main issue was related to storage of those export zip files. All exported zip files were stored directly in local storage and that even not by using storage module created under orga server.
On a mission to solve this, I made three simple steps that I followed to solve this issue.
These three steps were:
Wait for shutil.make_archive to complete archive and store it in local storage.
Copy the created archive to storage ( specified by user )
Delete local archive created.
The easiest part here was to make these files upload to different storage ( s3, gs, local) as we already have storage helper
From above snippet, it is clear that we are extending the process of creating the zip. Once the zip is created we will make storage path for cloud storage and upload it. Only one thing will take the time to understand here is the last second and third line of above snippet.
if get_settings()['storage_place'] != "s3" or get_settings()['storage_place'] != 'gs':
storage_url = app.config['BASE_DIR'] + storage_url.replace("/serve_","/")
Initial the plan was simple to serve the files through “serve_static” but then the test cases were expecting a file at this location thus I had to remove “serve_” part for local storage and then it works fine on those three steps.
Next thing on this storage process need to be discussed is the feature to delete old exports. I believe one reason to keep them would be an old backup of your event will be always there with us at our cloud storage.
One of the many feature requests that we got for our open event organizer server or the eventyay website is ticket ordering. The event organizers wanted to show the tickets in a particular order in the website and wanted to control the ordering of the ticket. This was a common request by many and also an important enhancement. There were two main things to deal with when ticket ordering was concerned. Firstly, how do we store the position of the ticket in the set of tickets. Secondly, we needed to give an UI in the event creation/edit wizard to control the order or position of a ticket. In this blog, I will talk about how we store the position of the tickets in the backend and use it to show in our public page of the event.
This post contains data collected and compiled from various sources that include (but not limited to) project readme files, my presentation from FOSSASIA 17, Wikipedia, my head.
This aims to be a place for any new contributor to know the basics about the entire Open Event Project.
This could also help newcomers choose an Open Event sub-project of their liking and start contributing .
The Open Event Project offers event managers a platform to organise all kinds of events including concerts, conferences, summits and regular meet-ups. The components support organisers in all stages from event planning to publishing, marketing and ticket sales. Automated web and mobile apps help attendees to get information easily.
There are seven components of the project:
Open Event Universal Format – A standard JSON Schema specification for data sharing/transfer/import/export between various components of Open Event.
Open Event Frontend – The primary frontend for the Open Event API Server where organisers, speakers and attendees can sign-up and perform various functions.
Open Event Organiser App – A cross-platform mobile application for Organisers with ticketing, checking and quick management capabilities.
Open Event Android application generator – An android application generator that allows event organisers to generate customised android applications for their events.
Open Event Web application generator – A web application generator that allows event organisers to generate customised static easily-hostable web pages for their events.
Open Event Data scrappers – A scrapper that allows users to scrape events from popular websites such as eventbrite into the Open Event Universal Format for it to be imported into Open Event.
Open Event Universal Format
A standard JSON Schema specification for data sharing/transfer/import/export between various components of Open Event.
The system exposes a RESTful API to fetch and modify data. It also provides endpoints that allow organisers to import and export event data in a standard compressed file format that includes the event data in JSON (Open Event Universal Format) and binary media files like images and audio.
The Open Event API Server comprises of:
Flask web framework – Flask is a microframework for python to create web applications. Flask also provided us with a Jinja2 templating engine.
PostgreSQL – Our database. PostgreSQL is an open-sourced Object-relational database management system (ORDBMS). We use SQLAlchemy ORM to communicate with the database and perform database operations.
Celery – Celery is a Distributed Task Queue. It allows us to run time consuming and/or resource intensive tasks in the background (or) on a separate worker server. We use celery to process event import/export tasks to process email send requests.
Redis – Redis is an in-memory data structure store. It’s generally used for caching and for message brokering b/w different services due it’s insanely fast read-write speeds (since it’s an in-memory data store). We use it for caching results of time-consuming less volatile database calls and also for brokering jobs and their statuses b/w the web server and Celery task queue.
In the near future, we plan to implement more additional components too.
Elasticsearch – a distributed, RESTful search and analytics engine. To start with, we’ll be using it to index our events and provide much fast search results to the user.
Kibana – data visualization and analytics plugin for elasticsearch. It will allow us to better understand search trends, user demographics and help us provide a better user experience.
We’re now in the process of slowly phasing out the Open Event Server’s existing UI and keep it only as an API Server since we’re moving towards an API-Centric approach with a Fresh new Open Event Frontend.
The Open Event server’s repository contains multiple branches each serving a specific purpose.
development – All development goes on in this branch. If you’re making a contribution, please make a pull request to development. PRs to must pass a build check and a unit-test check on Travis (https://open-event-dev.herokuapp.com – Is running off the development branch. It is hosted on Heroku.). This is probably the most unstable branch of all.
master – This contains shipped code. After significant features/bug-fixes are accumulated on development, we make a version update, and make a release. (https://eventyay.com – Is running off the master branch. (whichever is the latest release.) Hosted on Google Cloud Platform (Google Container Engine + Kubernetes).
staging – This branch is mainly for testing eventyay server configurations on a staging server without affecting the production environment. Push access is restricted to the devops team.
gh-pages – This contains the documentation website on http://dev.eventyay.com. The site is build automatically on each commit in the development branch through a script and using travis. It includes the md files of the Readme and /docs folder.
The Open Event Server has Unit tests to ensure each part of the server works as expected. This is also part of our workflow. So, every PR made to the repository, is tested by running the Unit tests and the code coverage is reported on the PR itself. (We use travis and codecov for continuous integration and code coverage reporting respectively).
Open Event Frontend
The primary frontend for the Open Event API Server where organisers, speakers and attendees can sign-up and perform various functions.
Open Event frontend is built on Ember.js – A javascript web application framework. Ember.js uses Ember data – its data persistence module to communicate with the Open Event API Server via the exposed RESTful endpoints.
The frontend is built upon components that are re-usable across various parts of the application. This reduces code duplication and increases maintainability.
The frontend also has various services to share data and functionality b/w components/routes/controllers.
Each merge into the Open Event frontend repository triggers two deployments:
Currently, both the staging and development use the development branch since the frontend is still under active development. Once we reach the release stage, staging & production deployments will start using the master branch just like the Open Event API Server.
As a part of the development workflow, to ensure proper code-styles throughout the project, and to prevent regressions, the project has Acceptance tests, Integration tests, Unit tests and lint checks on both javascript (*.js) and handlebar files (*.hbs). These tests are run for every PR made to the repository. (We use travis and codecov for continuous integration and code coverage reporting respectively).
Open Event Organizer App
A cross-platform mobile application for Organiser with ticketing, checking and quick management capabilities.
The organiser application is a mobile application that can run on Android, iOS and Windows Phone. It is built using Ionic Framework – cross-platform app development framework. The app uses the RESTful APIs exposed by the Open Event API Server to get data and perform operations.
The core features of this application are
Scan a QR code from an attendee’s ticket to view information about the attendee and to check him/her in.
Check-in attendees (Attendees can be searched for using name and/or email)
Continuous data sync with the Open Event Organiser Server
Other planned feature include:
Overview of sales – The organisers can see how their event is performing with just a few taps
Overview of tracks and sessions – They can see what sessions are next and can use that information to (for example) get everything ready for that session.
Quick session re-scheduling – They can re-schedule sessions if required. This should also trigger notification to participant that have registered for that event.
Push notifications for certain triggers – (for example) Organisers can get notifications if any session proposal is received.
This project has only one development branch (master). Each commit to that branch triggers an apk deployment to the apk branch via Travis.
Open Event Android Application Generator
An android application generator that allows event organisers to generate customised android applications for their events.
The App Generator – A web application that is hosted on a server and generates an event Android app from a zip with JSON and binary files (examples here) or through an API.
A generic Android app – the output of the app generator. The mobile app can be installed on any Android device for browsing information about the event. Updates can be made automatically through API endpoint connections from an online source (e.g. server), which needs to defined in the provided event zip with the JSON files. The Android app has a standard configuration file, that sets the details of the app (e.g. color scheme, logo of event, link to JSON app data).
Flask web framework – Flask is a microframework for python to create web applications. Flask also provided us with a Jinja2 templating engine.
Celery – Celery is a Distributed Task Queue. It allows us to run time consuming and/or resource intensive tasks in the background (or) on a separate worker server. The android application compile and build process is run as a celery job. This also allows multiple users to simultaneously use the generator.
Redis – Redis is an in-memory data structure store. It’s generally used for caching and for message brokering b/w different services due it’s insanely fast read-write speeds (since it’s an in-memory data store). We use it for brokering jobs and their statuses b/w the web server and Celery task queue.
Java Development Kit (JDK) – Java Development Kit provides us with a set of tools consisting of (but not limited to) a compiler, runtime environment, loader which enables us to compiler, build and run java based applications.
Android SDK Tools – The Android SDK Toolset provides us with Android API libraries, debugging tools, emulation capabilities and other tools that are needed to develop, build and run java based android applications.
Gradle Build Tool – Gradle is an open source build automation system. It allows developers to define a build process as a set of tasks that can be easily executed on any machine with predictable outputs as long as the gradle files are available.
As with other projects, this also has multiple branches each serving a different purpose
development – All development goes on in this branch. If you’re making a contribution, you are supposed to make a pull request to development. PRs to master must pass a build check and a unit-test (app/src/test) check on Travis.
master – This contains shipped code. After significant features/bugfixes are accumulated on development, we make a version update, and make a release. All tagged commits on master branch will automatically generate a release on Github with a copy of fDroid-debug and GooglePlay-debug apks.
apk – This branch contains two apk’s, that are automatically generated on merged pull request a) from the dev branch and b) from the master branch using the Open Event sample of the FOSSASIA Summit. This branch also assists in deploying the generator to http://droidgen.eventyay.com by triggering a travis build every time an apk is pushed to this branch. The reason this type of a round-about way was implemented is that, travis doesn’t allow android and docker builds on the same branch. So, we’re forced to use the apk branch to do the docker build for us.
Open Event Web application generator
A web application generator that allows event organisers to generate customised static easily-hostable web pages for their events.
The Open Event Web App project has two components :
An event website generator – A web application that generates the event website based on event data provided by the user either in the form of an archive as per the Open Event Universal Format or an API Endpoint to an Open Event API Server instance
A generic web application – This will be customised and additional pages will be generated from a set of templates by the generator based on the provided event data. The generated website bundle can be hosted on any static hosting provider (Github pages, any simple web hosting service, or any web server that can serve HTML files etc).
The generator also gives you the ability to directly upload the generated files to any server (via FTP) or to the gh-pages branch of any repository on GitHub.
Express.js – A web application framework for Node.js. The web application generator’s user-facing frontend runs on Express.js framework.
Socket.IO – A javascript library for real-time web applications. It allows a client and a server to communicate with each other simultaneously in a real-time manner. (Confusing ? If you wanna build something like a chat-room … you’d need something like Socket.IO). The web application generator uses Socket.IO to handle multiple clients and also to show the correct progress of the website generation to each of those clients in a real-time manner.
The web generator also uses SASS – which adds awesome features (Superpowers as their site says) to good-old CS, and Handlebars – which is a templating engine that let’s you easily generate HTML output based on a templates from a given javascript object.
The branches are similar to other projects under Open Event.
development – All development goes on in this branch. If you’re making a contribution, you are supposed to make a pull request to development. PRs to master must pass a build check and a unit-test (test/serverTest.js) check on Travis. Gets deployed automatically to https://opev-webgen-dev.herokuapp.com .
master – This contains shipped code. After significant features/bugfixes are accumulated on development, we make a version update, and make a release.
Open Event Data Scrappers
A scrapper that allows users to scrape events from popular websites such as eventbrite into the Open Event Universal Format for it to be imported into Open Event.
As of now, only eventbrite is supported for data scrapping. This allows new users of Open Event to import their events from other ticketing/event management websites very easily. The scrapper accepts a query from the user, and gets the event page for that query on eventbrite, parses the HTML DOM to get the required data and compiles everything into the Open Event Universal Format so that it could be imported into Open Event.
Future plans include combining fossasia/query-server, Open Event server and event collect to enable automatic import of events from other websites based on user searches on eventyay.
The Open Event Ecosystem is vast and has plenty of contribution opportunities to both beginners and experts alike. Starting with contributions is as easy as picking a project, choosing an issue and submitting a PR. No strings attached. (Oh wait. there is just one string attached. Ensure you read & follow the “Best Practices at FOSSASIA Guide”)
I would request you to please guide me as to how can I collaborate with you and also how can I contribute effectively to the organization.
At times I might get up to 20 private mails per day about “How to contribute to Open Source”. Usually I will direct developers to our mailing list or chat channels if they are asking about a specific project. But, how do contributions work at FOSSASIA? How can new developers join projects effectively? We have tried many different ways and spent a lot of time communicating with newcomers, many of them new to Git and Open Source development.
Over the years we have gotten better at helping new developers, designers and other contributors to join up. We have more than 1300 registered developers in our GitHub organization today. Not all of them can contribute every day, but we do have thousands of commits every year.
So, how are we able to scale up? I believe one reason are our Best Practices. We didn’t have a document “FOSSASIA Best Practices” yet, but in our daily work we have established excellent (mostly unwritten) best practices, that I would like to share in a concise form here now as a reference for new developers.
Happy to get your feedback and comments.
Development Best Practices at FOSSASIA
Culture and Communication
Please adapt your language to non-native English speakers and be super friendly. Remember we are an international community with contributors mainly from Asia and Europe. We are not used to swearing and will mostly understand words literally. At all times ensure your tone stays appropriate and friendly in the FOSSASIA community.
Stay modest. Sometimes newcomers already have an amazing knowledge in some areas. Still remember, it is no reason to be arrogant. Even the best developer does not know everything.
Be nice and welcoming. Why not add “please” in an issue or a comment “Thank you” in a pull request if someone did a good job? Show your appreciation for the good work of your co-developers.
If you are involved in a topic you don’t understand yet, try to learn yourself as much as possible from public channels (wikipedia, stackoverflow) but also do not hesitate to ask questions to other developers.
Communication Channels
Every project at FOSSASIA has its own channels. Many projects use Gitter, some Slack or IRC. Usually you will find information of the main communication channels of a project in the Readme.md.
While we are a community of Open Source and Free Software developers we still reserve our right to use whatever tools we deem necessary to help us to achieve our goal of developing the best possible Open Technologies – software and hardware. It is one step at a time 🙂
Private and Public Chat or Issue Tracker
Chat is a great way to connect with other contributors, but not all contributors are there all the time (consider time difference and personal schedules) and they are not always available to chat. Chat tends to be unstructured and with lots of people in a room there are often a number of threads. Therefore chat is great for help on setup issues and things where you got stuck.
Do not use chat for feature requests and detailed discussions on issues. These things are best for the issue tracker, where people from different timezones can join and where a focused conversation on one specific topic can happen.
Some people try to overcome the unstructured chats by switching to private communication. This shuts out other contributors who might have similar issues. A result I often observed is also, that contributors will bring up arguments in discussions like “I have discussed this already with xyz privately and he agrees”. Other contributors have not seen this discussion if it has not been taken place in public and we haven’t seen the arguments. We don’t know if xyz really agrees or if it was misunderstood. Private conversations are not transparent. Surely, there are cases where private chat is needed, e.g. for specific deployment questions of projects, but whenever you talk about development, please switch to public chat or open an issue.
Feature Requests and Bug Reports
Some newcomers are not accustomed to issue trackers and might try to inform developers on the mailing list, chat or even write private emails about bugs and features, but the right place to do this is: The issue tracker of a project.
Any bug or feature, please open an issue in the issue tracker right away and indicate if you want to work on it yourself.
Please include all relevant information when you submit an issue and wherever possible a link, information about the code that has issues and a screenshot.
When you file a bug report on the issue tracker, make sure you add steps to reproduce it. Especially if that bug is some weird/rare one.
Join Development
Before you join development, please set up the project on your local machine, run it and go through the application completely. Press on any button you can find and see where it leads to. Explore. (Don’t worry. Nothing will happen to the app or to you due to the exploring. Only thing that will happen is, you’ll be more familiar with what is where and might even get some cool ideas on how to improve various aspects of the app.).
If you would like to work on an issue, drop in a comment at the issue. If it is already assigned to someone, but there is no sign of any work being done, please free to drop in a comment so that the issue can be assigned to you if the previous assignee has dropped it entirely.
Commits/Pull Requests
All pull requests need to be associated to an issue.
All PRs need to be assigned to the person working on it.
If an issue cannot be completed in less than a day, it should be broken up into multiple issues.
Make pull requests from your own forks (even if you have write rights to the repository, do not create new branches, develop on your own branches).
State the actual change or enhancement in the commit message of PRs (do not just state “Fixes issue #123”).
Add the issue number into the description (this helps to speed up reviews as reviewers can simply click to get more info in the issue itself).
Match pull requests with issues and make sure your pull requests description contains GitHub’s special keyword references that automatically close the related issue when the pull request is merged. (More info at https://github.com/blog/1506-closing-issues-via-pull-requests).
When you make very minor changes to a pull request of yours (like for example fixing a failing travis build or some small style corrections or minor changes requested by reviewers) make sure you squash your commits afterwards so that you don’t have an absurd number of commits for a very small fix (Learn how to squash at https://davidwalsh.name/squash-commits-git).
Add a screenshot if you changed anything in the UI of a project. When you’re submitting a pull request for a UI-related issue, please add a screenshot of your change or a link to a deployment where it can be tested out along with your pull request. It makes it much easier for the reviewers and helps to speed up the process. You’ll also get reviews quicker.
Add a link to your deployment of the project, where reviewers can check out what you have changed (especially for smaller changes this is very helpful as the reviewer might not even need to set up the system itself and test it. Again this speeds up the review process a lot).
Always ensure CI and tests are successful.
Help to resolve merge conflicts (especially if there are several PRs at the same time, merge conflicts are common. Help the reviewers and solve merge conflicts to speed up the process.).
Merging Pull Requests should only happen if at least two contributors reviewed the PR and approved it.
Scope of Issues and Commits
Stay focused on the issue and its specifics: Sometimes it is tempting to do more changes in a pull request and simply add a nice little feature after mentioning it in the issue tracker. Please do not do this. Contributors will look at the title of issues usually to check if it is relevant for them. For example, if an issue is about changing a font, do not also change the color even if this seems like small change to you. Many projects have a design template and standard colors etc. that they want to achieve. So your changes might need to be discussed in a bigger setting even if they seem small to you. Same applies to many other areas.
Do only the changes in a pull request that are mentioned in the issue. Do not change anything else without ever mentioning it (remember match issues with pull requests).
Branch Policies
Most FOSSASIA Projects have:
a development branch (which is the working branch. Please commit to this branch.) and
a master branch (which is the stable branch).
Some projects also keep additional branches e.g.:
gh-pages for documentation purposes (often autogenerated from md-files in docs folder)
apk branches for Android apps (often autogenerated with travis).
Getting Started
Newcomers are sometimes afraid to make a pull request. Don’t be! It is the responsibility of reviewers to review them. And Git is a beautiful tool when it comes to reverting pull requests with errors.
In simple issues keep it simple and “simply” contribute, e.g. in an issue “change the color of the button from green to red”, there is no need to mention and ask “here is a screenshot where I changed the color to red. Should I make a PR now?”. Just make the pull request and wait for the feedback of the reviewer.
Take on responsibility early and help to review other contributions. Even though you do not have write access in a repository you can already help to review other commits.
Documentation
Please ensure you provide information about your code and the functioning of your app as part of every code contribution.
Add information on technologies and the code into the code itself and into documentation files e.g. into the Readme.md or /docs folder. Documentation is not a thing that should be done at the end after a few weeks or months of coding! Documentation is a continuous effort at every step of software development.
If you add new libraries or technologies add information about them into the Readme file.
If you implement a different design or change the css in a web project, please add information to the design specifications/template. If there are not any design specifications in the project yet, why not start them and add a section into the Readme.md to start with?
Always help to keep documentation up to date and make it easy for new contributors to join the project.
Thank you for helping to define many of the practices while working on the Open Event project to the developer team and for additional input and links to Niranjan Rajendran.
The FOSSASIA Summit 2017 was an unforgettable event thanks to everyone who helped to make it possible! We would like to thank our co-organiser the Science Centre Singapore and all sponsors, supporters, speakers and volunteers. Below are interesting numbers and facts of 2017 and information on highlights of the event.
FOSSASIA Summit 2017 Numbers & Facts
3,145 people attended the event over 3 days including 229 speakers and 60 volunteers.
41 nationalities participated in the summit: 70.8% from Singapore, followed by India, Indonesia, Germany, China, Japan, Vietnam and many others
Talks are already available as videos. Hundreds of photos have been uploaded to social networks. 2000+ tweets[tw] with the FOSSASIA hashtag were posted during the event.
FOSSASIA Summit 2017 Highlights
The three-day program with nearly 20 parallel tracks made FOSSASIA Summit the biggest open tech event in the region. One very interesting fact was the entire conference was fully managed by FOSSASIA built open source event management system, EventYay. All the technical setting was also done in-house by the FOSSASIA Team. In the effort of making the event the best experience for visitors, FOSSASIA team organized a series of extracurricular activities including pre-event meet&greet, pub crawl, culture walk, social event, see you again cocktails, and a lucky draw.
Day 1 Opening Day with Keynotes
Chan Cheow Hoe, GovTech’s Chief Information Officer, emphasized how the Singapore Government’s central information technology systems and infrastructure drive the development and delivery of innovative public services for citizens and businesses.
Chan Cheow Hoe, GovTech’s CIO, photo by Nguyen Thi Tra My
Follow-up by an interesting story by Øyvind Roti who currently leads Google’s international team of Cloud Architects. He spoke about how to get involved and contribute to the Google CloudOpen Source products and related projects, including machine learning, systems, client-side libraries and data analytics tools.
Øyvind Roti, photo by Gabriel Lee
Andrey Terekhov brought Microsoft into the Open Source picture with some insights that many were not aware of. MS actually are the top contributors to Github and they are hosting many Open Source projects themselves. Andrey explained in details Microsoft’s open source strategy and developing business in Asia Pacific region, with a particular focus on scaling up open source workloads on Microsoft Azure cloud platform.
Andrey Terekhov, Open Source Sales & Marketing Lead at Microsoft, photo by Kai En Mui
The final keynote of the day was conducted by a German privacy activist – Frank Karlitschek the founder of ownCloud and later Nextcloud, an open source and fully federated and distributed network for files and communication. As the topic of the privacy and personal data on the internet are under attack by hackers and international espionage programs, Frank shared with the audience how the Internet can be used as a free and democratic medium again.
Open Source AI Topics
The highlight of the day was the introduction of SUSI AI – FOSSAISA’s Open Source Personal Assistant. Michael Christen, founder and also core developer talked about SUSI’s current development stage as well as project’s ambition and the plan for the future. He demonstrated some amazing things you can do with SUSI such as searching for locations, finding translations in over 100 languages, asking SUSI travel information, weather etc. One of the exciting features is the auto-improvement ability: the more you interact with SUSI, the better and accurate its answers become. Michael also showed the audience how they can actually contribute and create the largest corpus of knowledge for SUSI AI Assistant.
Michael Christen about SUSI AI, OpenAI and the role of Elon Musk, photo by Michael Cannon
Liling Tan, a data scientist from Rakuten, spoke about Natural Language Processing (NLP) which is the task of the computationally understanding and production of human languages, often using a mix of hand-crafted rules and machine learning techniques. Konrad Willi Döring brought AI to next level when he presented the Brainduino Project including a brief introduction to EEG-based brain-computer interfaces as well as a look into the future of BCI technology.
Konrad Willi Döring Brainduino Project, photo by Michael Cannon
FOSSASIA’s favorite speaker, Andrew “bunnie” Huang, came back with “Let’s Make Technology more Inclusive”. Bunnie and his team examined some of the cultural and technological barriers that have stymied inclusiveness, using gender imbalance as a case study. They later on, proposed a solution called “Love to Code”, which attempts to address the issue of inclusiveness in technology.
The day finished with a panel discussion on The Future of AI with a diverse group of five panelists: Andrew Selle (Google Brain Team, US), Steffen Braun (KI Group), Michael Christen (SUSI AI), Harish Pillay (Internet Society), Bunnie Huang (Chibitronics PTE LTD)
It was a very interactive session between speakers and attendees, discussing the possibilities and implications of AI.
From September 2016 to February 2017, FOSSASIA held a CodeHeat contest to encourage more developers to get involved and contribute to the FOSSASIA open source projects, namely Open Events Orga Server, AskSUSI project, and LokLak. 442 developers had joined the contest, over a thousand pull requests were made during over this 6 months period of CodeHeat. Three winners and two finalists from the top 10 contributors who have contributed awesome code were chosen to fly to Singapore for the FOSSASIA Summit 2017 to share what they’ve done, and meet the open source community gathered here.
CodeHeat Award Ceremony, photo by Michael Cannon
PubCrawl
A get-together at Pubcrawl has become a tradition of every FOSSASIA Summit. At the end of the first day, speakers and participants met at Chinatown and started a fun evening strolling around various pubs, tasting local beverages and specialties. The hang-out has always been a great opportunity for speakers to carry on their unfinished conversations during the day as well as to enhance the friendship among visitors and residents.
Pub Crawl, photo by Ben SadeghiAndrew “bunnie” Huang, Brady Forrest and Sean “Xobs” Cross at the Pub Crawl, photo by Ben Sadeghi
Day 2 Extensive Day of Workshops and Presentations
FOSSASIA Summit Day 2 is always the busiest day with an extensive program starting from 9 am until 6:30 pm. Dedicated tracks included Startup and Business Development – Database PGDay – Open Tech Google Track – Python – Hardware & Making DevOps – Security and Privacy – Science – Android – Debian Mini-Debconf – Tech Kids – Open Source Software – Health Tech – Web & Mobile – Kernel & Platform – AI & Machine Learning
Open Tech – Google Open Source Track
Stephanie Taylor, the Program Manager at Google Open Source Outreach team gave an educational talk about Google Code-in program as an early opening of the Google’s Open Tech Track. This introduction was favored by local students as well as young international developers. In the following topic about Future of the Web, Anuvrat Rao introduced the latest open technology to address critical user needs on the open web.
Stephanie Taylor and GCI 2016 Students
Andrew Selle from Google Brain Team carried on the session with an overview of the open source software library TensorFlow and discussed how the open source community has shaped its development and success. Devan Mitchem introduced The Chromebook, a new, faster computer that offers thousands of apps. He also showed the audience how to integrate and experience Android apps on this machine for greater productivity and flexibility. Denis Nek wrapped up Google’s Tracks by a talk about Model–view–viewmodel (MVVM), a software architectural pattern. In this last topic, he explained why and how he could solve many common problems of android developers using this approach.
Tech Kids Track
Followed up the success of 2016’s summit, FOSSASIA 2017 extended Tech Kids Track throughout its 3-day event. Many parents brought their kids along to attend the talks and workshops. Most importantly, these young attendees showed their great interest in Open Technology. The kids’ voluntary participation in the tracks completed the aim of FOSSASIA in fostering education at a young age. With the power of open knowledge, we believe the bright future of world leaders start from today’s education.
Elda Webb and Creativity workshop, photo by Ka Ho Ying
Kids workshops covered topics such as Git for beginners, software translation with WebLate, PyGame 101 Codelab, how to developer your first mobile app, make a DIY paper spectrometer, create a promotion video with open source tools etc.
Kids and guardians learn how to work with Git, photo by Ka Ho Ying
This fun and educational workshop was organized by Microsoft Open Source Team. In this rescue mission, attendees learned to create a bot using an open source framework and tools. They were given access to MS code repositories and other technical resources. Workshop participants had to complete 3 missions and 2 code challenges in order to bring the Mars mission back on track. It was pretty challenging but at the same time super exciting.
Mission Mars’ Winner and Mentors
Python Track
Python Track has always attracted good audience’s response since 2015. In this year summit, the track covered very informative topics ranging from metaclasses in Python 2 and 3, computing using Cython to Go-lang (a new open source programming language), Pygame 101, the effective use of python in Science and Maths with live demos of successful experiments etc.
PyGame 101 Codelab Workshop
A 2-hour workshop was conducted by Kushal Das giving the audience the overview of MicroPython, how to update NodeMCU devices with MicroPython firmware and using sensors with NodeMCU for their first IoT device.
MicroPython workshop using NodeMCUPython Mentors, photo by Ka Ho Ying
Database Track – PostgreSQL Day
This was the second year FOSSASIA hosted PGDay. We were delighted to welcome amazing speakers like Dr. Michael Meskes (founder and CEO of credativ Group), Maksym Boguk (co-founder of PostgreSQL consulting), and many other PostgreSQL developers and consultants across the globe.
It was very interesting to learn how an open source database, PostgreSQL, has rapidly extended its application into the enterprise sector, one of the examples was how PostGIS is being by agricultural producer in Australia.
PGDay at FOSSASIA Summit 2017
Day 3 More sessions and the final keynote by Daimler’s Representatives
Day 3 Dedicated Tracks consisted of Hardware & Making – Tech Kids – Science – Android – Blockchain – Open Tech – AI & Machine Learning – Internet, Society & Politics – Web & Mobile – Security and Privacy – DevOps – Database MySQL Day – Design, Art, Community – Open Source Software.
It was wonderful to have two special guests from Daimler headquarter in Stuttgart – Jan Michael Graef (CFO of CASE) and Vlado Koljibabic (leads IT for the new CASE business and COO of the Digital and IT organization). The presence of Daimler, a traditional corporate business in the open source world was not only well received by the audience but also triggered an excitement and the curiosity of the crowd: What is the background of the growing involvement and support of Open Source by Daimler?
Daimler in the house: Danial, Vlado, Hong Phuc, Jan and Mario, photo by Michael Cannon
Daimler AG is known for one of the world’s most successful automotive companies. With its Mercedes-Benz Cars, Daimler Trucks, Mercedes-Benz Vans, Daimler Buses, and Daimler Financial Services divisions. The Group is one of the leading global suppliers of premium cars and is the world’s largest manufacturer of commercial vehicles. At FOSSASIA Summit 2017, Jan and Vlado made an introduction to CASE – these letters will shape the future of Mercedes-Benz Cars. They stand for the strategic pillars of connectivity (Connected), autonomous driving (Autonomous), flexible use (Shared & Services) and electric drive systems (Electric), which will be intelligently combined with one another by the company.
Jan Michael Graef and Vlado Koljibabic from Daimler, photo by Ka Ho Ying
In their talk Vlado and Jan outlined how Daimler recognizes the power of Open Source development and we had the chance to get insights into some very exciting ideas how Daimler is planning to shape the logistics sector with services based on Open Source technologies. The company is even considering cryptocurrency payments for services in the future and is already working on using Blockchain technologies for its automobile services for logistics companies.
Web & Mobile Track – featured OpenEvent (EventYay) System
Finally, there is an Open Source event management system said Mario Behling, founder of open-event (eventyay) and the summit’s co-organiser. During the last two years, the FOSSASIA team has been working on a complete functional open source solution for event organisers. More than 5,000 commits have been made from more than 100 developers worldwide. The hosted solution of the application is available at EventYay.com and ready to be tested as an Alpha product.
The system enables organizers to manage events from concerts to conferences and meet-ups. It offers features for events with several tracks and venues. Event managers can create invitation forms for speakers, build schedules in a drag and drop interface, implement ticketing system and much more. The event information is stored in a database. The system also provides API endpoints to fetch the data, and to modify and update it. Organizers can import and export event data in a standard compressed file format that includes the event data in JSON and binary media files like images and audio.
OpenEvent Scheduler – Drag & Drop interface
The Open-event core team of 7 senior developers came together at the FOSSASIA summit to showcase the latest development, make live demos, conduct deployment workshops and discuss future applications.
Featured Open Event presentations and workshops:
Better Events with Open Event | Mario Behling
Deploy Open Event Organizer Server | Saptak Sengupta
Scaling Open Event Server with Kubernetes | Niranjan Rajendran
Open Event API | Avi Aryan
Open Event Web App | Aayush Arora
An Introduction to the Open Event Android Project and it’s capabilities| Manan Wason
Agile Workflow and Best Practices in the Open Event Android App Generator Project | Harshit Dwivedi
This year FOSSASIA proudly hosted MySQL Day within the database track. 12 senior developers/speakers from Oracle around the world got together at the summit. 14 scheduled talks and workshop were conducted. Beginning with Sanjay Manwani, MySQL Director from India, he talked about ‘the State of the Dolphin’, sharing an overview of the recent changes in MySQL and the direction for MySQL 8 as well as an introduction to Oracle cloud. The day continued with selective topics from MySQL optimizer features to in-depth workshops such as MySQL operations in Docker – workshop or MySQL Performance Tuning.
Additionally, Ricky Setyawan organized an unconference session or a MySQL Community Meetup Space where he invited the community members to meet and to start a direct conversation with MySQL’s developers.
See you again Cock-Tails
After the closing session, FOSSASIA attendees were invited by Daimler to join an after-event cocktail party. People were happy for the chance to finish up their discussions while enjoying the nice view of the city from a spacious balcony with finger food, drinks and good music from the local band.
Engineers.SG Team, photo by Ka Ho YingPhoto by Nguyen Thi Tra MyFOSSASIA regular friends Felix Dahmen, Joerg Henning & Emin Aksehirli, photo by GunessMusic performance by a local band
Exhibition and Networking Space at FOSSASIA Summit
The biggest goal of the FOSSASIA Summit is to bring people across borders together at a physical space where they can freely share, showcase, discuss and collaborate on existing projects or new ideas. We are happy to see many open source communities across Asia at this year’s gathering. What could be better than a face-to-face discussion over coffee with people who shared the same vision and belief: ‘With open technologies, we can make the world a better place’
Google Cloud Team at FOSSASIADietrich Ayala from Mozilla sharing details about A-frame with attendeesOpen Hardware corner with Dan and Kiwi, FOSSASIA organizersSindhu Chengad explained Open Source at MicrosoftOpenSUSE BoothMichael Meskes (right) and Engineer from Credativ GermanyMatthew Snell from xltech.io, SingaporeMySQL Team, photo by Michael CannonThomas Kuiper from gandi.net, Taiwan, photo by Michael CannonMen gathering at Pyladies Pune tableWan Leung Wong from TinyBoy 3D printer project, HongkongFresh coffee in the house
FOSSASIA What’s Next?
Mark your calendar for the next FOSSASIA Summit, which will take place in March 2018. We are looking forward to seeing you again in Singapore. If you are meetup organizers, community leaders, we would like to invite you to host a track at the next FOSSASIA Summit, please write to us about your experience and contribution in the open source world via office@fossasia.org
As always thanks to Michael Cheng and Engineers.SG team for all the videos, thanks to our photographers Michael Cannon, Ka Ho Ying and the team for capturing some of the very best moment of us. You can search for more photos by typing #fossasia on loklak (or alternatively on Twitter) or Flickr. If you also want to share photos you took during the summit, please add them to the group pool.
The FOSSASIA Summit 2017 takes place from Friday March 17 – Sunday March 19 at the Science Centre Singapore. We are now inviting Open Source contributors to apply for a free stay in a Singapore hostel and a free ticket to the event. All you have to do is convince us, that you are an awesome Open Source contributor!
The details
Developers from all over the world are joining the FOSSASIA Summit. We want to connect established and new Open Tech contributors alike. Therefore FOSSASIA is supporting the Open Source community to join the event by offering 100 free nights stay at a hostel in the centre of Singapore and a free ticket to the event. All you have to do is to fill in the form with information that convinces us that you are an awesome contributor in the Open Source community.
Step 2: We will get back to you at latest within 3 days after the deadline if you are selected. But, also we are choosing very convincing applicants on an ongoing basis. So, the earlier you apply the higher your chances to get a free stay might be.
Step 3: The selected applicants will need to confirm their itinerary and tickets before March 1st to re-assure their free stay in Singapore.
Expectations of Participants – Share what you learn
1. Please support volunteers, speakers and participants at the event. Let’s bring all this good spirit of sharing Open Technologies and learning together!
2. Help to reach out to participants who cannot join us at the event. For example make some tweets, share what you learn on social media, publish photos and put up blog posts about the summit.
The iCalendar data format (RFC5545) is a widely deployed interchange format for calendaring and scheduling data.
A Sample xCal document
<?xml version="1.0" encoding="utf-8"?>
<iCalendar xmlns:xCal="urn:ietf:params:xml:ns:xcal"><vcalendar><version>2.0</version><prodid>-//Pentabarf//Schedule 1.0//EN</prodid><x-wr-caldesc>FOSDEM 2016</x-wr-caldesc><x-wr-calname>Schedule for events at FOSDEM 2016</x-wr-calname><vevent><method>PUBLISH</method><uid>123e4567-e89b-12d3-a456-426655440000</uid><dtstart>20160131T090000</dtstart><dtend>20160131T091000</dtend><duration>00:10:00:00</duration><summary>Introduction to the SDR Track- Speakers, Topics, Algorithm</summary><description><p>The opening talk for the SDR devroom at FOSDEM 2016.</p></description><class>PUBLIC</class><status>CONFIRMED</status><categories>Software Defined Radio</categories><url>https:/fosdem.org/2016/schedule/event/sdrintro/</url><location>AW1.125</location><attendee>Martin Braun</attendee></vevent></vcalendar></iCalendar>
Each event/session will be in a seperate vevent block. Each speaker/attendee of an event/session will be in an attendee block inside a vevent block.
Some important elements are:
version – Has the version of the iCalendar data
prodid – Contains the name of the application/generator that generated this document
x-wr-caldesc – A descriptive name for this calendar
x-wr-calname – A description of the calendar
The structure and keywords used in xCal are the same as those used in the iCal format. To generate the XML document, we’ll be using python’s ElementTreeXML API that is part of the Python standard library.
We’ll be using two main classes of the ElementTree API:
Element – used to create a standard node. (Used for the root node)
SubElement – used to create a sub element and attache the new node to a parent
Let’s start with the root iCalendar node and set the required attributes.
from xml.etree.ElementTree import Element, SubElement, tostring
i_calendar_node = Element('iCalendar')
i_calendar_node.set('xmlns:xCal','urn:ietf:params:xml:ns:xcal')
Now, to add the vcalendar node to the iCalendar node.
Now, we have added information about our calendar. Now to add the actual events to the calendar. Each event would be a vevent node, a child of vcalendar node. We can loop through all our available event/sessions and add them to the calendar.
Please note that all the timings in the XML Document must comply with ISO 8601 and must have the date+time+timezone. Example:2007-04-05T12:30-02:00.
We’re still not done yet. We now have the XML document as an Element object. But we’ll be needing it as a string to either store it somewhere or display it.
The document can be converted to a string by using the ElementTree API’s tostring helper method and passing the root node.
xml_as_string = tostring(i_calendar_node)
And that’s it. You now have a proper XML document representing your events.
The Open Event Android App generator runs on a DigitalOcean. The deployment runs on a USD 10 box, that has 1 GB of RAM, but for testing I often use a USD 5 box, that has only 512mb of RAM.
When trying to build an android app using gradle and Java 8, there could be an issue where you run out of RAM (especially if it’s 512 only).
What we can do to remedy this problem is creating a swapfile. On an SSD based system, Swap spaces work almost as fast as RAM, because SSDs have very high R/W speeds.
The steps to create a swap file and allocating it as swap are
sudo fallocate -l 1G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
We can verify using
sudo swapon --show
NAME TYPE SIZE USED PRIO
/swapfile file 1024M 0B -1
And now if we see RAM usage using free -h , we’ll see
total used free shared buff/cache available
Mem: 488M 37M 96M 652K 354M 425M
Swap: 1.0G 0B 1.0G
Do not use this as a permanent measure for any SSD based filesystem. It can corrupt your SSD if used as swap for long. We use this only for short periods of time to help us build android apks on low ram systems.
You must be logged in to post a comment.