Code

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:

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.

This week, in Open Event Orga App project (Github Repo), we wanted to add some static code analysers that run on each build to ensure that the app code is free of potential bugs and follows a certain style. Codacy handles a few of these things, but it is quirky and sometimes produces false positives. Furthermore, it is not a required check for builds so errors can creep in gradually. We chose checkstyle, PMD and Findbugs for static analysis as they are most popular for Java. The area they work on kind of overlaps but gives security regarding code quality. Findbugs actually analyses the bytecode instead of source code to find possible JVM bugs.

Adding dependencies

The first step was to add the required dependencies. We chose the library android-check as it contained all 3 libraries and was focused on Android and easily configurable. First, we add classpath in project level build.gradle

dependencies{classpath'com.noveogroup.android:check:1.2.4'}

Then, we apply the plugin in app level build.gradle

applyplugin:'com.noveogroup.android.check'

This much is enough to get you started, but by default, the build will not fail if any violations are found. To change this behaviour, we add this block in app level build.gradle

check{abortOnErrortrue}

There are many configuration options available for the library. Do check out the project github repo using the link provided above

Configuration

The default configuration is of easy level, and will be enough for most projects, but it is of course configurable. So we took the default hard configs for 3 analysers and disabled properties which we did not need. The place you need to store the config files is the config folder in either root project directory or the app directory. The name of the config file should be checkstyle.xml, pmd.xml and findbugs.xml

These are the default settings and you can obviously configure them by following the instructions on the project repo

You can also annotate your code to suppress warning in the particular class, mehod or field rather than disabling it for the whole project. For that, you need to add findbugs annotations dependency in the project

compile'com.google.code.findbugs:findbugs-annotations:3.0.1'

And then use it like this:

@SuppressFBWarnings(value="ICAST_IDIV_CAST_TO_DOUBLE",justification="We want granularity to be integer")publicvoidshowChart(LineChartlineChart){...}

It also allows setting the justification of suppressing the rule for clarity

PMD also supports suppressing warnings in the code itself using annotations. You don’t require any external libraries for it as it supports the in built java.lang.SuppessWarnings annotations. You can use it like this:

As you can see, we need to prepend “PMD.” to the rule name so that there are no clashes while annotation processing. Remember to comment the reason for suppressing the warning so that your co-developers know and can remove it in future if criteria does not meet anymore.

There is a lot more to learn about these static analyzers, which you can read upon in their official documentation:

Drum roll please! We are very proud to announce the 2017 FOSSASIA #CodeHeat Grand Prize Winners and Finalists. 442 participants from 13 countries and 5 continents committed over 1000 pull requests to our repositories over the course of the contest. Congratulations to everyone to this fantastic achievement! The winners were now chosen by our jury. Thank you for reviewing the contributions.

Our three Grand Prize winners will travel to the FOSSASIA Summit in Singapore from March 17-19 and present their work to developers from around the world. The winners are (in alphabetical order):

Many developers made outstanding contributions in the last months and we all learned a lot during the contest. Thank you so much! We hope you stay on board and continue to participate in the community to develop Open Tech that improves peoples lives and to seize the opportunity to develop your code profile with FOSSASIA. To receive your certificate of participation now, please claim it here.

Supporting Partners

We would also like to extend a special Thank you to our jury and to our supporting partners at the UNESCO and the Open Tech Society.

Thanks FOSSASIA mentors!

And we really love the work of our mentors! Thanks for your patient guidance, helping everyone with learning about best practices, reviewing the huge number of pull requests and discussing questions on the chat channels. Many of our mentors have been students in coding programs before and we are very very proud to see how you help newcomers to join. Keep up the fantastic work!

I’ve met many weird examples of behaviour in python language while working on Open Event project. Today I’d like to share some examples with you. I think this knowledge is necessary, if you’d like to increase a bit your knowledge in python area.

First output is obvious, but second not exactly. Let me explain it, It happens because x(empty list) argument is only evaluated once, So on every call foo(), we modify that list, appending a value to it. Finally we have [1,2, 4] output. I recommend to avoid mutable params as default.

Another example:

Do you know which type it is?

>>> print(type([ el for el in range(10)]))>>> print(type({ el for el in range(10)}))>>> print(type(( el for el in range(10))))

Again first and second type are obvious <class ‘list’>, <class ‘set’>. You may think that last one should return type tuple but it returns a generator <class ‘generator’>.

You have to know how python interpreter behaves while looking for OR and AND operators.

So OR Expression takes the first statement and checks if it is true. If the first statement is true, then Python returns object’s value without checking second value. If first statement is false interpreter checks second value and returns that value.

AND operator checks if first statement is false, the whole statement has to be false. So it returns first value, but if first statement is true it checks second statement and returns second value.

Below i will show you how it works

>>> 'c' == ('c' or 'b')>>> 'c' == 'c'True

>>> 'd' == ('a' or 'd')>>> 'd' == 'a'False

>>> 'c' == ('c' and 'b')>>> 'c' == 'b'False

>>> 'd' == ('a' and 'd')>>> 'd' == 'd'True

I hope that i have explained you how the python interpreter checks OR and AND operators. So know above examples should be more understandable.

Students from all around the world aged 13-17 years old worked with mentors of FOSSASIA on improving open source software during the 7 weeks the contest is run. They coded programs, designed artworks, tested software and more than anything else had fun.

174 students managed to complete at least one task with FOSSASIA and 43 out of them claimed a cool t-shirt from Google by completing 3 or more tasks.

Out of the 10 students who completed most number of tasks finalists and grand prize winners were picked collectively by FOSSASIA’s 24 mentors. Namanyay Goel and Samarjeet Singh won the grand prize, which is an all expense paid trip to Google HQ in Mountain View, California. Alvis Wong, Amr Ramadan and Tymon Radzik emerged as finalists. Congratulations finalists! Safe travels grand prize winners! We are thankful for your precious contributions and will be delighted see you continue to contribute even after the program.

Open source projects ExpEYES, sup, TiddlySpace, p5.js among few others, benefitted from FOSSASIA students’ work. More than 150 open source/ open tech projects and communities around asia were connected to FOSSASIA with the help of students. Students also worked together to build a nice website portraying students and mentors.

We would like to thank all participated students for the amazing interest they showed in our tasks. Its great to see some of them still hang around to help us. 24 mentors of FOSSASIA worked hard and stood up to the challenge of finding time to work with and help out students while having other obligations. Thank you mentors! Lastly we are grateful to Stephanie Taylor and Co. at the Google OSPO, for organizing the wonderful contest.