32nd Monthly Technical Session (MTS) Report

32nd Monthly Technical Session (MTS) was held on March 17th. MTS is a knowledge sharing event, in which HDE members present some topics and have QA sessions, both in English.

The moderator of the 32nd MTS was Kevin-san.


The first topic was ‘Microsoft Azure Overview’ by Mami Konishi-san and Drew Robinsons-san from Microsoft.

Konishi-san explained the current momentum of Microsoft Azure. These days, 90% of Fortune 500 companies use Microsoft Cloud. Each month, there are 120,000 new Azure customer subscriptions. Furthermore, there are currently 34 available Azure regions, with 4 others coming soon.


Robinsons-san demonstrated how to utilize Microsoft Azure to create an Ubuntu server. This task can be accomplished in several ways, the first of which is to utilize Azure portal. For people who prefer to work with terminals, Microsoft offers Bash on Windows and Azure CLI 2.0. Using these tools in combination with Azure Resource Manager gets the job done, but Robinsons-san introduced yet another approach. Besides running commands in the CLI, Azure Resource Manager also provides Azure Quickstart Templates, with which deploying Azure resources becomes simpler. There are quite a lot of templates already available on the GitHub repository.

He also explained other Azure services, such as DocumentDB, Azure Container Service, and Service Fabric. DocumentDB is Azure’s NoSQL service. By turning on protocol support for MongoDB, DocumentDB databases can even be used as the data store for apps written for MongoDB. Azure Container Service enables deployment and management of container-based applications on Microsoft Azure. Service Fabric is Azure’s microservices platform. Robinsons-san mentioned some of its features, namely its support of both stateless and stateful microservices, its tools for Visual Studio, and local cluster.


The second topic was ‘Introduction to Swagger for Amazon API Gateway’ by Furukawa-san. Swagger is a framework for designing, building, and documenting RESTful APIs. Swagger consists of the specification (currently known as OpenAPI Specification) and the tools that support it.

Amazon API Gateway allows us to export APIs as Swagger. We can then update the exported API definitions using tools such as Swagger Editor. Finally, we can import the updated API definitions back to API Gateway. By default, imports merge updates to the existing API definitions. However, imports can also be configured to overwrite existing API definitions. In utilizing Swagger for API Gateway, Furukawa-san was concerned about how Swagger supports environment-specific configurations (e.g. AWS account IDs and Lambda function ARNs) and certain aspects of API Gateway (e.g. API keys, usage plans, and custom domains).


The third topic was ‘How to Make a Secure Web Application’ by Okubo-san. He had wanted to talk about this because of the change in HDE’s business environment and ISMS utilisation. He also mentioned past incidents that happened to other companies, such as YouTube (2010), Sony (2011), and Twitter (2014).

Okubo-san were particularly concerned about several aspects that affected security, which are programming rules, framework, vulnerability-checking tools, and third-party verification. He recommended us to make programming rules based on a certain standard, such as this document by Information Technology Promotion Agency. Because human error happens often, he suggested us to not implement validators individually. Instead, those validators should be included in a framework that everybody uses. Identification of some vulnerabilities can be automated by using tools such as OWASP Zed Attack Proxy Project. Finally, we should also consider doing third-party verification, because it may help us discover vulnerabilities that we didn’t realise before.


The fourth topic was ‘Designing APIs in Go’ by Shihan-san. The HDE service he’s working on consists of 10 microservices with no less than 130 HTTP endpoints. Furthermore, in maintaining the APIs, the team needs to modify handler functions, update the client codes, update the API docs, the list goes on. This led him to Goa, a Framework for building microservices and REST APIs in Go. Goa generates a lot of things automatically; such as boilerplate, glue code, documentation (JSON schema / Swagger), CLI, JavaScript Library, Go Client, and others.

To him, the benefits of utilizing Goa are we can focus on writing codes that matter, Goa generates the boring stuff as idiomatic Go codes, it also helps us completing documentation, and Goa has a friendly community surrounding it. On the other hand, he was still not sure about how to utilize Goa in several aspects of his work, namely things related to JSON Web Tokens (JWT) and role-based access control (RBAC).


The fifth topic was ‘Data Science & Python’ by Aji-san. He is one of our Global Internship Program (GIP) participants. In very simple terms, data science is about extracting knowledge from data. This extraction process usually involves data collection, preparation (e.g. cleaning and transformation), and manipulation. Afterwards, we can obtain hypotheses from the data, namely by examining what affects the attributes and the relationship between attributes.

In regards to Python, there are a quite a lot of data science libraries available. Aji-san explained some of them, such as NumPy, pandas, and Seaborn. With NumPy, we can utilize N-dimensional arrays, among other things. Pandas is a data structure and analysis tool. Seaborn allows us to create better-looking plots. He felt that, compared to R, Python is easier to read, can be combined with other platforms/domains, and has more and better visualization choices. On the other hand, regarding data science, it is easier to find answers about R, since it’s more mature than Python in that aspect.


The sixth topic was ‘Introduction to systemd’ by Chiachun-san. He is the other one of our GIP participants. init is the first process started during booting of a computer system (PID = 1). Most of Linux distributions used SysV-style init (SysVinit). However, it is too old and has many drawbacks, one of them is that it starts tasks serially.

This is where systemd comes in. It is a system and service manager for Linux operating systems, and a full replacement of SysVinit. Chiachun-san highlighted some of its features, such as service dependencies definition, its own logging system, and service identification by utilizing cgroups. It was released in 2010, and today most of Linux distributions have switched to systemd as the default init system.

He also explained some systemd commands, systemctl and journalctl systemctl is used to control the systemd system and service manager. journalctl is used to query the systemd journal (its own logging system). He also showed some usage examples of systemctl and journalctl to do certain tasks.


The seventh topic was ‘PHP 7.1 is Fast (?)’ by Uzulla-san from builderscon. He specializes in PHP, has won best speaker award from many tech conferences, and is an author as well. He is also an organizer of tech conferences, one of which is builderscon.

PHP 7.1 was released on last December, and Uzulla-san was intrigued by the impression that it is fast. He then took it upon himself to benchmark the new version of PHP. In doing so, he utilized tools such as ab, httperf, and wrk. He said he wasn’t successful in achieving higher performances than existing benchmarks, but he’s pretty satisfied with his results.


As usual, we had a party afterwards :)