Resolving Internal Error on Badgeyay

Badgeyay is in development stage and is frequently seen to encounter bugs. One such bug is the Internal Server Error in Badgeyay. What was the bug? The bug was with the badge generator’s backend code. The generator was trying to server the zip file that was not present. After going through the log I noticed that it was because a folder was missing from Badgeyay’s directory.   I immediately filed an issue #58 which stated the bug and how could it be resolved. After being assigned to the issue I did my work and created a Pull Request that was merged soon. The Pull Request can be found here. Resolving the bug With the help of extensive error management and proper code and log analysis I was able to figure out a fix for this bug. It was in-fact due to a missing folder that was deleted by a subsequent code during zipfile/pdf generation. It was supposed to be recreated every time it was deleted. I quickly designed a function that solved this error for future usage of Badgeyay.   How was it resolved? First I started by checking if the “BADGES_FOLDER” was not present. And if it was not present then the folder was created using the commands below   if not os.path.exists(BADGES_FOLDER):    os.mkdir(BADGES_FOLDER)   Then, I added docstring to the remaining part of the code. It was used to empty all the files and folder inside the “BADGES_FOLDER”. We could have to delete two things, a folder or a file. So proper instructions are added to handle file deletion and folder deletion.   for file in os.listdir(BADGES_FOLDER):    file_path = os.path.join(BADGES_FOLDER, file)    try:        if os.path.isfile(file_path):            os.unlink(file_path)        elif os.path.isdir(file_path):            shutil.rmtree(file_path)    except Exception:        traceback.print_exc()   Here “os.unlink” is a function that is used to delete a file. And “shutil.rmtree” is a function that deletes the whole folder at once. It is similar to “sudo rm -rf /directory”. Proper error handling is done as well to ensure stability of program as well. Challenges There were many problems that I had to face during this bug. It was my first time solving a bug, so I was nervous. I had no knowledge about “shutil” library. I was a new-comer. But I took these problems as challenges and was able to fix this bug that caused the INTERNAL SERVER ERROR : 500 . Resources BadgeYay Repository : https://github.com/fossasia/badgeyay Pull Request for the same : https://github.com/fossasia/badgeyay/pull/59 Issue for the same : https://github.com/fossasia/badgeyay/issues/58 Learn about OS Module : https://docs.python.org/2/library/os.html Learn about SHUTIL module : https://docs.python.org/2/library/shutil.html Read about Error Handling : https://docs.python.org/3/tutorial/errors.html Learn how to delete folder and file in Python : https://stackoverflow.com/questions/6996603/how-to-delete-a-file-or-folder    

Continue ReadingResolving Internal Error on Badgeyay

Auto Deployment of Pull Requests on Susper using Surge Technology

Susper is being improved every day. Following every best practice in the organization, each pull request includes a working demo link of the fix. Currently, the demo link for Susper can be generated by using GitHub pages by running these simple commands - ng build and npm run deploy. Sometimes this process on slow-internet connectivity takes up to 30 mins to generate a working demo link of the fix. Surge is the technology which publishes or generates the static web-page demo link, which makes it easier for the developer to deploy their web-app. There are a lot of benefits of using surge over generating demo link using GitHub pages: As soon as the pull request passes Travis CI, the deployment link is generated. It has been set up as such, no extra terminal commands will be required. Faster loading compared to deployment link is generated using GitHub pages. Surge can be used to deploy only static web pages. Static web pages mean websites that contain fixed contents. To implement the feature of auto-deployment of pull request using surge, one can follow up these steps: Create a pr_deploy.sh file which will be executed during Travis CI testing. The pr_deploy.sh file can be executed after success i.e. when Travis CI passes by using command bash pr_deploy.sh. The pr_deploy.sh file for Susper looks like this: #!/usr/bin/env bash if [ "$TRAVIS_PULL_REQUEST" == "false" ]; then echo "Not a PR. Skipping surge deployment." exit 0 fi angular build production npm i -g surge export SURGE_LOGIN=test@example.co.in # Token of a dummy account export SURGE_TOKEN=d1c28a7a75967cc2b4c852cca0d12206 export DEPLOY_DOMAIN=https://pr-${TRAVIS_PULL_REQUEST}-fossasia-susper.surge.sh surge --project ./dist --domain $DEPLOY_DOMAIN;   Once pr_deploy.sh file has been created, execute the file in the travis.yml by using command bash pr_deploy.sh. In this way, we have integrated the surge technology for auto-deployment of the pull requests in Susper. References: Static web publishing for the Front-End developers: https://surge.sh/

Continue ReadingAuto Deployment of Pull Requests on Susper using Surge Technology

How to organise a successful Google Code-In meetup

In this blog post I hope to write about what is Google Code-In and the best way to organise a successful Google Code-In meetup or workshop in your local community. I hope you will find everything that you need to know about conducting a successful meetup. What is Google Code-In ? Google Code-In is a global and an open source contest funded by Google to give real world software development experience to pre-university students who are in age range 13-17. Beside of software developing, this contest’s main objective is to motivate tech enthusiastic students to contribute to opensource and give them the knowledge about open source software development. The usual timeline of the contest is, it opens for students on end of the November and runs until mid of January. There are 25 open source organizations participating for Google Code-In this time. Your role ? As a GCI mentor , past GCI student or an open source contributor you have a responsibility towards the community. That is to expand the community awareness and transfer your knowledge to next generation. You gather experience while working on the open source projects and GCI is the best place to give your knowledge to youngsters while working with them. You should be devoted to guide students and give them an introduction to open source software development. How students can be a part of the contest ? Any pre-university student in age group 13-17 can register for the contest. The following four steps needs to be followed by the student to be eligible to compete in the contest. Sign up at g.co/gci after reading the Contest Rules. Ask their parent or legal guardian to sign the Parental Consent form. Find a task that interests them. Claim the task and start working while getting guidance from the mentors. In return to their hard work and open source contribution, students can win digital certificates, t-shirts, hoodies based on their performance as well as a trip to Google HeadQuarters for Grand Prize Winner. How to organize a local meetup ? Since the Google Code-In contest is for pre-university students, I highly recommend that you organize a meetup for schools in the community. You can easily contact the club or society of the school which is related to Information and Communication Technology and convey your idea of the meetup so that the responsible person can get the management approval from their side to facilitate your meetup inside the school. If you are not confident enough to conduct a session on your own maybe because this is a new experience to you, Don’t worry ! You can always call some other past GCI students, GCI mentors or open source contributors to collaborate with you in conducting a successful session. As open source world teaches us, it’s always collaboration that brings success to any project. Taking the start to the meetup, you need to give an introduction to the Google Code-In. You may find different questions from the audience about “What…

Continue ReadingHow to organise a successful Google Code-In meetup
Read more about the article Setting up SUSI Desktop Locally for Development and Using Webview Tag and Adding Event Listeners
SUSI Desktop

Setting up SUSI Desktop Locally for Development and Using Webview Tag and Adding Event Listeners

SUSI Desktop is a cross platform desktop application based on electron which presently uses chat.susi.ai as a submodule and allows the users to interact with susi right from their desktop. Any electron app essentially comprises of the following components Main Process (Managing windows and other interactions with the operating system) Renderer Process (Manage the view inside the BrowserWindow) Steps to setup development environment Clone the repo locally. $ git clone https://github.com/fossasia/susi_desktop.git $ cd susi_desktop Install the dependencies listed in package.json file. $ npm install Start the app using the start script. $ npm start Structure of the project The project was restructured to ensure that the working environment of the Main and Renderer processes are separate which makes the codebase easier to read and debug, this is how the current project is structured. The root directory of the project contains another directory ‘app’ which contains our electron application. Then we have a package.json which contains the information about the project and the modules required for building the project and then there are other github helper files. Inside the app directory- Main - Files for managing the main process of the app Renderer - Files for managing the renderer process of the app Resources - Icons for the app and the tray/media files Webview Tag Display external web content in an isolated frame and process, this is used to load chat.susi.ai in a BrowserWindow as <webview src="https://chat.susi.ai/"></webview> Adding event listeners to the app Various electron APIs were used to give a native feel to the application. Send focus to the window WebContents on focussing the app window. win.on('focus', () => { win.webContents.send('focus'); }); Display the window only once the DOM has completely loaded. const page = mainWindow.webContents; ... page.on('dom-ready', () => { mainWindow.show(); }); Display the window on ‘ready-to-show’ event win.once('ready-to-show', () => { win.show(); }); Resources 1. A quick article to understand electron’s main and renderer process by Cameron Nokes at Medium link 2. Official documentation about the webview tag at https://electron.atom.io/docs/api/webview-tag/ 3. Read more about electron processes at https://electronjs.org/docs/glossary#process 4. SUSI Desktop repository at https://github.com/fossasia/susi_desktop.

Continue ReadingSetting up SUSI Desktop Locally for Development and Using Webview Tag and Adding Event Listeners

Make Flask Fast and Reliable – Simple Steps

Flask is a microframework for Python, which is mostly used in web-backend development.There are projects in FOSSASIA that are using flask for development purposes such as Open Event Server, Query Server, Badgeyay. Optimization is indeed one of the most important steps for a successful software product. So, in this post some few off- the-hook tricks will be shown which will make your flask-app more fast and reliable. Flask-Compress Flask-Compress is a python package which basically provides de-facto lossless compression  to your Flask application. Enough with the theory, now let’s understand the coding part: First install the module 2. Then for a basic setup 3.That's it! All it takes is just few lines of code to make your flask app optimized .To know more about the module check out flask-compress module. Requirements Directory A common practice amongst different FOSSASIA  projects which involves dividing requirements.txt files for development,testing as well as production. Basically when projects either use TRAVIS CI for testing or are deployed to Cloud Services like Heroku, there are some modules which are not really required at some places.  For example: gunicorn is only required for deployment purposes and not for development. So how about we have a separate directory wherein different .txt files are created for different purposes. Below is the image of file directory structure followed for requirements in badgeyay project. As you can see different .txt files are created for different purposes dev.txt - for development prod.txt - for production(i.e. deployment) test.txt - for testing. Resources Flask documentation: http://flask.pocoo.org/docs/ Optimizing Flask App: https://damyanon.net/flask-series-optimizations/ Badgeyay project:  https://github.com/fossasia/badgeyay

Continue ReadingMake Flask Fast and Reliable – Simple Steps

Join Codeheat Coding Contest 2017/18

Codeheat is a coding contest for developers interested in contributing to Open Source software and hardware projects at FOSSASIA.  Join development of real world software applications, build up your developer profile, learn new new coding skills, collaborate with the community and make new friends from around the world! Sign up for #CodeHeat here now and follow Codeheat on Twitter. The contest runs until 1st February 2018. All FOSSASIA projects take part in Codeheat including: Open Event/Eventyay  SUSI.AI loklak Front-end and Back-end Phimp.me PSLab Meilix Susper Yaydoc Query Server FOSSASIA Labs Projects SUSI.AI Magic Mirror Badgeyay Grand prize winners will be invited to present their work at the FOSSASIA OpenTechSummit in Singapore from March 23rd -25th 2018 and will get 600 SGD in travel funding to attend, plus a free speaker ticket and beautiful Swag. Our jury will choose three winners from the top 10 contributors according to code quality and relevance of commits for the project. The jury also takes other contributions like submitted weekly scrum reports and monthly technical blog posts into account, but of course awesome code is the most important item on the list. Other participants will have the chance to win Tshirts, Swag and vouchers to attend Open Tech events in the region and will get certificates of participation. Team mentors and jury members from 10 different countries support participants of the contest. Participants should take the time to read through the contest FAQ and familiarize themselves with the introductory information and Readme.md of each project before starting to work on an issue. Developers interested in the contest can also contact mentors through project channels on the FOSSASIA gitter. Additional Links Website: codeheat.org Codeheat Twitter: twitter.com/codeheat_ Codeheat Facebook: facebook.com/codeheat.org Participating Projects: All FOSSASIA Repositories on GitHub at github.com/fossasia

Continue ReadingJoin Codeheat Coding Contest 2017/18

FOSSASIA at Google Code-In 2016 Grand Prize Trip

This year FOSSASIA came up with a whopping number of GCI participants, making it to the top. FOSSASIA is a mentor organization at the Google Code-In contest, which introduces pre-university students towards open source development. Every year Google conducts the grand prize trip to all the GCI winners and I represented FOSSASIA as a mentor. FOSSASIA GCI winners and Mentor at Google Mountain View Campus. Day 1: Meet and Greet with the Diverse Communities We all headed towards the San Francisco Google office and had a great time interacting with members from diverse open source organizations from different parts of the world. I had some interactive conversations with the kids, on how they scheduled their sleep hours in order to complete the task and got feedback from the mentors from different time zones! I was also overwhelmed while listening to their interests apart from open source contributions. “I am a science enthusiast, mainly interested in Computer Science and its wide range of applications. I also enjoy playing the piano, reading, moving, and having engaging conversations with my friends. As a participant in the GCI contest, I got the chance to learn by doing, I got an insight of how it is like to work on a real open-source project, met some great people, helped others (and received help myself). Shortly, it was amazing, and I'm proud to have been a part of it. ” Shared by one of our Winner Oana Rosca. There were people from almost 14 different countries, in fact, FOSSASIA, as a team, was the most diverse group :) Day 2: Award Ceremony We had two winners from FOSSASIA, Arkhan Kaiser from Indonesia and Oana Rosca from Romania. There were 8 organizations with 16 winners. The award ceremony was celebrated on day 2 and each winner was felicitated by Chris DiBona, the director of the Google open source team. Talks by Googlers We had amazing speakers from Google who spoke about their work, experiences, and journey to Google. Our first speaker was Jeremy Allison, a notable contributor to “Samba” which is a free software re-implementation of the SMB/CIFS networking protocol. He spoke on “How the Internet works” and gave a deeper view of the internet magic. We had various speakers from different domains such as Grant Grundler from the Chrome team, Lyman Missimer from Google Expeditions, Katie Dektar from the Making and Science team, Sean Lip from Oppia(Googler and Oppia org admin), Timothy Papandreou from Waymo and Andrew Selle from TensorFlow. Day 3: Fun Activities We had various fun activities organized by the Google team. I had a great time cruising towards the Alcatraz island.  Later we had a walk on the Golden Gate bridge. Here comes the fun part of the tour “the cruise dinner” which was the best part of the day. Day 4: End of the trip Oana, Arkhan and I gave a nice presentation about our work during GCI. We spoke about all the amazing projects under FOSSASIA. One cool thing we did…

Continue ReadingFOSSASIA at Google Code-In 2016 Grand Prize Trip

Open Source Developer Guide and Best Practices at FOSSASIA

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…

Continue ReadingOpen Source Developer Guide and Best Practices at FOSSASIA

How to join the FOSSASIA Community

We often get the question, how can I join the community. There is no official membership form to fill out in order to participate in the Open Tech Community. You simply start to contribute to our projects on GitHub and you are already a member. So, let's work together to develop to develop social software for everyone! The FOSSASIA team welcomes contributors and supporters to Free and Open Source Software. Become a developer, a documentation writer, packaging maintainer, tester, user supporter, blogger or organize events and meetups about our projects. Women in IT discussion in the community Here are some ideas how we can collaborate Download our Open Source applications, install them and use them The first step of joining a project is always to download the software and try it out. The best motivation to support a project is, if the project is useful for yourself. Check out our many projects on github.com/fossasia and our project social media Open Source search engine on github.com/loklak. Show your support and ★star FOSSASIA projects Help to motivate existing contributors and show your support of FOSSASIA projects on GitHub. Star projects and fork them. Doing something that people like and that helps people is a great motivation for many. Learn about best practices We have formulated best practices for contributing to Open Source to help new contributors to get started. Please read them carefully. Understanding our best practices will help you to collaborate with the community and ensure your code gets merged more quickly. Subscribe to news Subscribe to the FOSSASIA Newsletter to stay up to date on new software releases, events and coding programs here on the main page. Read the blogs and support users on the mailing list Learn from Open Tech articles on our blog that are written by developers, contributors, volunteers, and staff of companies supporting the FOSSASIA network. Sign up for the FOSSASIA Mailing List and keep reading our blog at blog.fossasia.org. Follow us on Social Media Show us you interest in FOSSASIA's Open Technology and keep up to date on new developments by following us on Twitter and retweeting important updates: twitter.com/fossasia And, become a member on social networks like Google+ and Facebook and connect with other contributors: * Facebook www.facebook.com/fossasia/ * Google+ plus.google.com/108920596016838318216 Join and support the FOSSASIA network at community events Set up a booth or a table about FOSSASIA at Open Source community events! There are many events of the open source community all over the world. The core team of FOSSASIA is simply not able to attend all events. You can support the cause by making the project visible. Register as a member of the FOSSASIA community at events, set up an info point and showcase Free and Open Source projects. Check out for example FOSSASIA event calendar calendar.fossasia.org or our meetup group in Singapore: meetup.com/FOSSASIA-Singapore-Open-Technology-Meetup Translate our projects and their documentation Do you speak more than one language? Most Open Tech projects are 100% volunteer translated, which means you can be part of a translation team translating software and documentation thousands of people will use.…

Continue ReadingHow to join the FOSSASIA Community