FOSSASIA Summit 2018: “The Open Conversational Web” with Open Source AI

FOSSASIA teams up with Science Centre Singapore and Lifelong Learning Institute for Asia’s premier open technology summit. The FOSSASIA OpenTechSummit is taking place from March 22-25, 2018 under the tagline “The Open Conversational Web” with a strong focus on Artificial Intelligence and Cloud for the Industry 4.0. More than 200 speakers will fly in to present at the event. International exhibitors will showcase their latest advancements and meet developers in a careers fair.

The FOSSASIA Open Tech Summit is an annual tech event featuring tech icons from around the world since 2009. The event is all about the latest and greatest open source technologies and their impact and applications on business and society. With more than 3,000 attendees the FOSSASIA Summit is the biggest gathering of Open Source developers and businesses in Asia. A great feature of 2018 is the expanded exhibition space where tech businesses, SMEs and startups converge with developers and customers and meet potential candidates in a careers fair.

“The goal of the FOSSASIA Summit is to bring together developers, technologists and businesses to collaborate, share and explore the full potential of open source to create opportunities for new industries. And, right now there is a shift happening where users increasingly communicate through their voice with computer applications enhanced by Open Source AI technologies.“, says Ms. Hong Phuc Dang, chair of the summit and continues: “We expect to see interesting new voice gadgets to try out at the event. And, attendees will be able to learn how to develop solutions for these new voice interface devices here.”

Associate Professor Lim Tit Meng, CE of Science Centre adds: “Technologies like Big Data, AI and VR, and the web itself are becoming more open and conversational. They are also the engines behind the Industry 4.0 innovations. The open source community, with its spirit of co-creation and sharing is at the forefront of conversations on the web. At Science Centre Singapore, we aim to showcase and create content using these technologies and look forward to learning from and working with the open source community.”

The call for speakers is open and “we are seeing a large increase in proposals this year” says Mr. Mario Behling from the FOSSASIA Summit committee. Speakers are expected from companies such as car manufacturer Daimler, tech companies like Google, Microsoft, Oracle, Samsung, Intel and from many Singapore startups with topics ranging from algorithms and cognitive experts to DevOps, cloud containers, Blockchain and Neurotechnologies. Voice assistants and Open Source development solutions for SUSI.AI, Amazon Alexa, Google Assistant, Microsoft Cortana, Siri, and solutions using Nuance or IBM Watson are a big topic.

Tickets are available on the website 2018.fossasia.org.

The press representatives signup is here.

Links

Event-driven programming in Flask with Blinker signals

Setting up blinker:

The Open Event Project offers event managers a platform to organize all kinds of events including concerts, conferences, summits and regular meetups. In the server part of the project, the issue at hand was to perform multiple tasks in background (we use celery for this) whenever some changes occurred within the event, or the speakers/sessions associated with the event.

The usual approach to this would be applying a function call after any relevant changes are made. But the statements making these changes were distributed all over the project at multiple places. It would be cumbersome to add 3-4 function calls (which are irrelevant to the function they are being executed) in so may places. Moreover, the code would get unstructured with this and it would be really hard to maintain this code over time.

That’s when signals came to our rescue. From Flask 0.6, there is integrated support for signalling in Flask, refer http://flask.pocoo.org/docs/latest/signals/ . The Blinker library is used here to implement signals. If you’re coming from some other language, signals are analogous to events.

Given below is the code to create named signals in a custom namespace:


from blinker import Namespace

event_signals = Namespace()
speakers_modified = event_signals.signal('event_json_modified')

If you want to emit a signal, you can do so by calling the send() method:


speakers_modified.send(current_app._get_current_object(), event_id=event.id, speaker_id=speaker.id)

From the user guide itself:

“ Try to always pick a good sender. If you have a class that is emitting a signal, pass self as sender. If you are emitting a signal from a random function, you can pass current_app._get_current_object() as sender. “

To subscribe to a signal, blinker provides neat decorator based signal subscriptions.


@speakers_modified.connect
def name_of_signal_handler(app, **kwargs):

 

Some Design Decisions:

When sending the signal, the signal may be sending lots of information, which your signal may or may not want. e.g when you have multiple subscribers listening to the same signal. Some of the information sent by the signal may not be of use to your specific function. Thus we decided to enforce the pattern below to ensure flexibility throughout the project.


@speakers_modified.connect
def new_handler(app, **kwargs):
# do whatever you want to do with kwargs['event_id']

In this case, the function new_handler needs to perform some task solely based on the event_id. If the function was of the form def new_handler(app, event_id), an error would be raised by the app. A big plus of this approach, if you want to send some more info with the signal, for the sake of example, if you also want to send speaker_name along with the signal, this pattern ensures that no error is raised by any of the subscribers defined before this change was made.

When to use signals and when not ?

The call to send a signal will of course be lying in another function itself. The signal and the function should be independent of each other. If the task done by any of the signal subscribers, even remotely affects your current function, a signal shouldn’t be used, use a function call instead.

How to turn off signals while testing?

When in testing mode, signals may slow down your testing as unnecessary signals subscribers which are completely independent from the function being tested will be executed numerous times. To turn off executing the signal subscribers, you have to make a small change in the send function of the blinker library.

Below is what we have done. The approach to turn it off may differ from project to project as the method of testing differs. Refer https://github.com/jek/blinker/blob/master/blinker/base.py#L241 for the original function.


def new_send(self, *sender, **kwargs):
    if len(sender) == 0:
        sender = None
    elif len(sender) > 1:
        raise TypeError('send() accepts only one positional argument, '
                        '%s given' % len(sender))
    else:
        sender = sender[0]
    # only this line was changed
    if not self.receivers or app.config['TESTING']:
        return []
    else:
        return [(receiver, receiver(sender, **kwargs))
                for receiver in self.receivers_for(sender)]
                
Signal.send = new_send

event_signals = Namespace
# and so on ....

That’s all for now. Have some fun signaling 😉 .