Informatica Applicatahttp://informatica.uniurb.it
STI Footer 2016Mon, 19 Mar 2018 17:21:13 +0000en-UShourly1DSLA lectureshttp://informatica.uniurb.it/en/dsla-lectures/
http://informatica.uniurb.it/en/dsla-lectures/#respondSun, 08 Jan 2017 22:10:11 +0000http://informatica.uniurb.it/?p=10073Read more &raquo]]>As agreed with the interested students in December, next week there will be two DSLA lectures: on January 9th (Monday), h 9pm, and on January 11th (Wednesday), as usual, h 9pm.
]]>http://informatica.uniurb.it/en/dsla-lectures/feed/0Scaling a Bot for the Europe Code Weekhttp://informatica.uniurb.it/en/quizzle-scaling-a-bot-for-the-europe-code-week/
http://informatica.uniurb.it/en/quizzle-scaling-a-bot-for-the-europe-code-week/#respondThu, 03 Nov 2016 14:23:43 +0000http://informatica.uniurb.it/?p=9842Read more &raquo]]>A couple of days have passed since the closing of the Europe Code Week 2016, topping the numbers of past editions with a record-breaking total of 20.000 events organized in more than 50 countries.

In the context of CodeMOOC, a massive open online course offered by the University of Urbino about computational thinking and coding, a large-scale coding quiz was planned for 20 October. Using only a Telegram client and a QR Code scanner, the participants were able to take part in the game and compete with over 900 groups in Italy.

Telegram channel.

Participants did register to a Telegram channel where they would receive instructions before the start of the game. At the start of the game, we handed out the link to a live Youtube stream, where further instructions and quiz questions were given out.

For each coding quiz, the Telegram bot coordinating the event wrote a special link to the channel conversation, that would redirect users to the voting conversation using Telegram’s deep link feature. Since each quiz had a unique identifier, the deep link would not only transfer the user to the bot, but also send out a hidden command.

/start IY4

(Where IY4 is the hidden code for the 4th quiz question.)

Participants could also access the voting process by scanning a QR Code, containing the same deep link.

Response and results of a quiz question.

Once invoked, the bot did ask for an answer from the user.
As soon as the question was closed from our side (by simply providing the correct answer to the bot), the bot did rank all correct answers by timestamp and signal the results on the channel. The first 3 correct answers were publicly acknowledged with various, priceless, emoji medals. ?

Message processing

A total of 974 participants (in terms of Telegram users) took part in the event. Since each person could register for a group of people (acting like a team leader), a total number of 9689 people were involved with the game.14 questions were asked, collecting a total of 7004 responses by participants, over approximately one hour and a half.

In other words: a lot of messages were sent to our bot over a short amount of time.

Pull mode

In pull mode, your bot server periodically connects to a Telegram end-point and downloads part of the messages queued up for delivery. The delivery mechanism can be customized, for instance downloading a batch of messages in a single call and using long-polling to stall the request until some data can be returned.

In theory, the pull method ensures higher efficiency: requests are sent out by your server, they can be controlled easily, and large batches of messages can be returned in a single HTTP data transfer.

However, pull operations are synchronized by nature. The Telegram API disallows multiple parallel requests (since, of course, the pull request operates sequentially on the delivery queue).
While transferring one single large payload and performing one single JSON decode step may be more efficient, in pull mode you are indeed increasing the average response time of each message.
Moreover, after the download phase, data parallelism is entirely up to the developer. Handing off message handling to different threads can be more or less easy, depending on your development framework: in Go a goroutine can be dispatched for each message, while the same can be done for async tasks on any .NET language.

Push mode

This mode—which incidentally is the only mode of operation of many other messaging platforms—trades off the single, efficient data transfer step for multiple parallel message handling operations.

Instead of waiting for your server to fetch messages, updates are pushed to your bot’s web server to an URL of your choice (Telegram requires HTTPS, a domain name, and a certificate). Instead of having to deal with parallelism, this mode exploits the inherent strong points of a web server: dealing with multiple incoming connections and handling them off efficiently to your code.

Results

Based on our logs, 7.414.458 messages where sent to the bot through Telegram, in little over 80 minutes of operation.

An average of over 380 messages per minute were handled, with a peak of around 1200. If you watch closely, you can get a hint of when the 14 questions were asked.

Initially, our bot was configured to operate via pull and synchronous message handling, since this mode allows for far easier debugging and development. However, as soon as the event did start, we quickly discovered that the queue of messages was growing uncontrollably and the bot simply could not keep up.
We quickly switched over to push mode. Over the course of a couple of minutes the bot was able to catch up and performed very responsively for the rest of the event.

The bot was running on a quad-core machine clocked at 2.6 GHz, with 2 GBs of RAM.

In conclusion, pull mode is perfectly suited for bot development, since it allows developers to control the flow of messages and to carefully debug the code. Implementing an efficient message handling method via pull mode, however, probably isn’t worth the development effort. As suggested by others, it is far easier to entrust the web server with handling parallel requests on your behalf.

More generally—and this is very important in the context of the recent focus on bots as a replacement of apps—using a bot instead of a web site (for instance) gave us a very important advantage. The messaging platform, Telegram in this case, acts as an extremely scalable load balancer in front of your service. It handles message queuing, retrying, delivery, and push notifications—essentially Telegram offers an incredible amount of complex infrastructure for free. This allows you to focus on actual service development instead of having to worry about the plumbing.

This Europe Code Week event has been a good opportunity to appreciate the effects of an unusual load (for our scale of development) on our bot. Further similar events will be planned and we look forward to evaluate performance and scaling issues in deeper detail.

]]>http://informatica.uniurb.it/en/quizzle-scaling-a-bot-for-the-europe-code-week/feed/0Online 1st Year Students Reception 2016-17http://informatica.uniurb.it/en/reception/
http://informatica.uniurb.it/en/reception/#respondThu, 29 Sep 2016 08:34:34 +0000http://informatica.uniurb.it/?p=9640Read more &raquo]]>Online students are strongly recommended to consult the Academic Calendar and Bullettin Board, in order not to miss any important news and notice.

A trial lesson is planned on October, 10 at 6.00 pm. First year students shouldn’t miss this opportunity to get all the information they need, ask all the questions they have, and test our learning platform and chat.

]]>http://informatica.uniurb.it/en/reception/feed/0Implementing a bot-based treasure hunt gamehttp://informatica.uniurb.it/en/treasurehuntbot/
http://informatica.uniurb.it/en/treasurehuntbot/#respondTue, 13 Sep 2016 16:07:59 +0000http://informatica.uniurb.it/?p=9535Read more &raquo]]>On August 26th, during the course of the “Coding in your Classroom, Now!” summer school, a large treasure hunt game took place in the historical center of Urbino: 26 groups, composed of 139 participants overall, challenged each other by chasing clues through the narrow and steep streets of the city, following the orders of a… bot.

The game had been developed during the week just before the event and the whole team behind the treasure hunt spent the last minutes before the start feverishly fixing the last bugs. (Well, most of them.)

The summer school, aimed at school teachers of all grades, had the main focus of bringing coding to the classroom, in a way that could be engaging for both teachers and young students. Thus, it made more than sense that the treasure hunt itself, “Urbino Code Hunting” as it was called, would be based on coding puzzles as well.

What made the treasure hunt interesting is that the whole registration process, the actual hunting, puzzling, and other game mechanics were directly handled by a Telegram bot. Anyone with a Telegram account could very easily register during the 4 days before the game just by entering a conversation with it.

Registrations to the game were handled by a run of the mill conversation with the bot.

The bot asked registrants to solve a “preliminary” puzzle (to prepare players for what would have come later and to work as some kind of captcha), how many other participants would have taken part to the game together with the team leader, and the team’s name.

Usually a treasure hunt game requires players to find hidden objects or reach secret locations based on some—more or less vague—clues. In our case, the actual puzzling was centered around coding questions delivered by the bot, not around recognizing locations from clues, both because coding was the theme of the game and because many participants weren’t familiar with the city. Therefore, locations to reach were given out explicitly by the bot.

Each location had its own secret 16-character code.

How did the bot ensure that a group has reached its destination? Easy. We printed 30 paper signs (on A4 sheets), one for each location, with a special QR Code linking to an URL following this scheme:

https://telegram.me/treasurehuntbot?start=0123456789ABCDEF

This link makes use of the deep linking feature of Telegram: after opening the URL through a QR Code scanner, the user’s phone automatically starts the Telegram client and sends the “/start 0123456789ABCDEF” string to our bot, without actually displaying it inside the conversation screen. Since each QR Code contained the location’s secret 16-character code inside the URL, the bot would know with certainty which code the group had scanned and thus which location was reached.

The bot tracked each group making its way through a sequence of 12 locations. To ensure that groups of players do not follow each other and that they don’t cluster in the same area, the sequence of locations to reach for each group was chosen at random.

In order to ensure fairness, sequences of locations were generated beforehand with a bounded maximum (and minimum) length.

Puzzles—which were given out as soon as a group reached a location and sent a confirmation selfie of the group—were based on the CodyRoby quizzes . These simple logical puzzles make use of shared conventions, like the colored pseudo-code blocks from Blockly used in Code.org and the CodyRoby coding cards .

Sample question.

All puzzles required at most a couple of minutes to be solved and the answer could be provided as a simple text message, usually with a single character or a single number. Answers would be accepted quite liberally, with whitespace, in upper or lower case, and with any formatting. Wrong answers caused a forced delay of 60 seconds before the next attempt.

Correct answers not only let the group move forward, but they also rewarded the group with an important clue that would then be used to solve the last riddle: as soon as a group reached the last location (which we made sure was the same for all groups), they were given a map (like, a real, tangible, honest to goodness map made out of paper) that could be used to find out the exact place where the coveted prize was hidden.

The first group that reached it would get to keep the prize and receive another wonderful QR Code. Who doesn’t love QR Codes anyway? This last code signaled that the game was over for everyone.

A Telegram channel was used to broadcast information, to share selfies, and to make the game more engaging.

The Urbino Code Hunting Telegram channel was created on the day of the game and all participants were invited to subscribe to it. Major advancements of the groups were broadcast on the channel, along with all selfies taken by the groups as soon as they were sent in from the various locations. The channel gave the participants and us a way to monitor the state of the game, thus making it more engaging as the groups got closer to their final destination.

Part of all the selfies collected by the bot.

The bot was powered by a PHP program and a MySQL database, patched together in less than a week. The source code has been published on Github under the MIT license if you want to take a look. At the moment, deploying the bot for your own backyard treasure hunt might not be the easiest of tasks, but we are already planning to make it reusable at will.(And we have other significant—and scary?—plans for the future…)

]]>http://informatica.uniurb.it/en/treasurehuntbot/feed/0Crowd-Scratching with DirectPollhttp://informatica.uniurb.it/en/crowd-scratching-directpoll/
http://informatica.uniurb.it/en/crowd-scratching-directpoll/#commentsSat, 14 May 2016 22:08:10 +0000http://informatica.uniurb.it/?p=8539Read more &raquo]]>To celebrate Scratch Day 2016, UniUrb has developed a simple .NET application, called DirectPollMonitor, to allow the audience of a webinar to control a Scratch project in real time. DirectPollMonitor takes in input the URL of the result page of a poll made by DirectPoll. Each option of the poll is associated with a specific keypress event on the computer in which the app executes, so that every time the option is voted the corresponding keypress event is generated. By default, the keypress events associated with the first 26 options correspond to keys ‘a’ to ‘z’, while all subsequent options (if any) are associated with the ‘space’ key. DirectPoll ‘stop/reset’, ‘pause’, and ‘play’ events are mapped onto keys ‘0’, ‘1’, and ‘2’.

When the program executes, keypress events are treated as if they were generated by the local keyboard and received by the focus window.

This provides a very simple and general mechanism to grant collective control of any Scratch project to an arbitrary number of people taking part to an instant poll.

4. Launch the DirectPollMonitor from command line using as a parameter the URL of the DirectPoll result page

5. Start the DirectPoll and invite the audience to vote

6. Change the keyboard focus to the Scratch project

In order to make sure that all keypress events are properly received by the Scratch project, it is recommended that the window in which the Scratch project executes keeps the keyboard focus for the entire duration of the poll. Hence, it is better to control the poll from a different computer, while leaving in background the Command Prompt Terminal in which DirectPollMonitor executes.

A standard poll has been created for testing purposes. It has only 5 options associated with keys A, B, C, D, and E. Hence, it can be used to control any Scratch project designed to react to these keypress events.

DirectPollMonitor was tested for the first time on ScratchDay 2016 during a public webinar attended by many Italian School teachers with their pupils. Several Scratch projects were developed during the webinar and controlled in real time by more than 100 people. Here is the video log.

Sources files to be published on GitHub.

]]>http://informatica.uniurb.it/en/crowd-scratching-directpoll/feed/3Two days at DroidCon Turin 2015http://informatica.uniurb.it/en/two-days-at-droidcon-turin-2015/
http://informatica.uniurb.it/en/two-days-at-droidcon-turin-2015/#respondFri, 24 Apr 2015 10:06:06 +0000http://informatica.uniurb.it/?p=6810Read more &raquo]]>New year, new DroidCon: like last time, two heros from our lab (Lorenz e Saverio namely) traveled to Torino in order to attend the yearly italian Android conference. The 2015 edition reached new heights of attendance: last year we had great fun attending the conference, but this time the event had grown even more.

The conference was held in the imposing conference center Lingotto in Turin, nicely bathed in sun and nice weather, with more than 700 participants from over 21 different countries.

Saverio and Lorenz after getting their badges. As you can see, badges = bliss.

Last year’s event was marked by an unmanageable epidemy of Google Glass-wearing speakers. The 2015 edition fortunately marked a switch from Google’s glasses to more discreet Android Wear based watches. A nice advantage, from a stylistic perspective at the least.

Because of that, many sessions were actually focused on Android Wear and Android Auto, the brand new platforms where our favorite green droid is expanding into. Many other talks during the two intense days of DroidCon where instead focused on the intersection between Android and the Internet of Things: for instance interesting stuff about iBeacons and (a bit discouraging) experiments on proximity monitoring by Matteo Gazzurelli.

Apart from software development, one of the most discussed topics was actually user experience (or “UX”): Lydia Selimalhigazi and Roberto Orgiu gave a nice overview on why developers and designers need to stick together and help each other in order to obtain results without (too much) conflict. The same topic was taken on, from a branding perspective, during the stimulating talk by Marie Schweiz on how the specific features of a brand influence the user experience (not only the logo, that is).

Another totally different point of view on “user experience”: Kentaro Takiguchi gave a very nice talk “Improving UX through Performance” with an in-depth overview of those little optimizations that can be applied, both on the app and on the server side, in order to improve an app’s fluidity, reliability and responsiveness. An interesting bag of tricks for scenarios where even shaving off 4 KBs from a remote request can have a great impact.

Benjamin Augustin made clear that in fact software development can, at times, be a hellish affair. However, in order to free developers from pain, a growing number of libraries and tools are being worked on. One of those libraries is in fact RxJava, the Java port of the Reactive extensions originally created for .NET: those extensions offer a nice way to “invert” how your code work, by adopting a “reactive” coding paradigm which is very well suited to manage the interactions between user interface and an unreliable backend (like network access, for instance).

Likewise, Maciej Górski presented several ways, especially using Gradle plug-ins, to reduce the amount of “boilerplate” code developers need to write (for instance getter and setter methods for Java classes). Also very interesting: the “Holy Sync!” session by Eugenio Marletti, about cross-platform synchronization methods, using CouchBase.

“Test, test and test!” was the mantra of several other talks, in particular the one given by the always funny Ali Derbane e Wiebe Elsinga (don’t even try pronouncing his name, you’ll fail) who during their talk “The hitchhiker’s guide to functional testing” gave an overview of most functional testing suites available for Android. Stephan Linzner instead showed the glorious new tools developed at the Google mothership for its mobile developers.

Finally, at 12 o’clock of the first day, pushed by hunger more than anything else, our Lorenz gave his talk “The love child of Android and .NET: using Xamarin for app development” about all our recent experiences using the Xamarin platform for Android development during the last year. Slides can be downloaded as PPTX as well.

Gave us the necessary energy between sessions: the Cola from Turin!

After two very intense days we left Turin exhausted, but encouraged and inspired by many new things to check out, technologies to use in our projects and details to keep in mind while developing on Android (and not only)! Looking forward for next year!

The University of Urbino awards 1 credit to students who enrol to Applied Computer Science for Academic Year 2015/2016 having already obtained Code.org certificates signed by their School teachers. This initiative is aimed at contributing to the early development of computational thinking skills, by encouraging secondary schools to adopt Code.org instruments as proposed by Ministry of Education and Consorzio CINI with the “Programma il Futuro” initiative.

The University of Urbino has always worked together with schools to provide early learning opportunities based on playful and intuitive methods: It has took part since the first editions to Computer Science Education Week and Europe Code Week, it has launched the Code’s Cool learning community, it led the Italian participation to Europe Code Week 2014 with CodeWeek ambassador Alessandro Bogliolo, and it’s now offering a MOOC to support school teachers who want to adopt Code.org instruments.

This initiative gives to Italian schools the opportunity to take their students to conquest their first university credit!

The introductory course of Code.org offers approximately 20 hours of playful interactive activities which introduce the main coding principles, contributing to the development of computational thinking and problem solving skills. The MOOC completes the course by showing how to put the concepts into practice to develop original mobile applications. School teachers can directly manage a virtual classroom, which gives them the online instruments to monitor and certify the progress of their pupils. The certificate of completion will be recognized by the University of Urbino in case of enrollment.

“The credit that will be recognized is deserved – says Alessandro Bogliolo, coordinator of the School of Information Science and Technology of the University of Urbino – Students who enrol to a University degree program having already developed basic computational thinking skills are predisposed to learning computer science, are fully aware of the meaning and power of coding, and they are familiar with visual programming tools and teaching methods that are complementary and preparatory to academic study.”

People who is no longer at school can take advantage of the MOOC individually by registering to the virtual class directly managed by Alessandro Bogliolo, who will certify the completion. Certification will be recognized in case of enrollment to the Laurea degree program in Applied Computer Science, delivered both on campus and at the distance.

An effective infographic by European Schoolnet published by Debating Europe provides a comparison between the ICT skills required to find a job and the ones provided at school.

The ICT skill gap is apparent and it is expected to cause 900,000 unfilled ICT positions by 2020.

]]>http://informatica.uniurb.it/en/job-offers-require-ict/feed/0ISEP international exchange program 2015-16 – Scholarships for the USAhttp://informatica.uniurb.it/en/sep-international-exchange-program-2015-16-scholaships-for-the-usa/
http://informatica.uniurb.it/en/sep-international-exchange-program-2015-16-scholaships-for-the-usa/#respondWed, 21 Jan 2015 13:56:33 +0000http://informatica.uniurb.it/?p=6303Read more &raquo]]>The University of Urbino, as ISEP International member University, offers students the opportunity to apply for no. 3 international semester scholarships for study at one of the over 140 member universities in the United States.

Students are eligible to apply for ISEP Exchange programs at the U.S. institutions listed here.

To find out what benefits are included in the scholarship and for the procedure application, please see the Notice of Selection (in IT only).