71st Monthly Technical Session
Monthly Technical Session (MTS) is HENNGE’s mini-conference. As the name implies, MTS is held monthly and its talks are (mostly) about technology.
The 71st MTS was held on June 26th, 2020.
“Customer Portal” by Yohei and Takeru
Yohei kicks off the talk with a clear description of a problem he is trying to solve and his vision of what the solution may one day become. Yohei is part of the team that handles renewal sales, i.e. when customers renew their contract with us. As HENNGE continues to grow, so does our customer base.
Consequently, the workload of Yohei’s team has continued to increase. He figured that an all-in-one Customer Portal can simplify the workflow; thus, allow them to work more efficiently. He explains the three phases of this software product. Phase 1 will be an organized source of all the contract-related information which is easy to look up and understand. Phase 2 will be an automated contract renewal workflow. Last but not least, phase 3 will be the contract drafting workflow. They have already started building such a system. The talk was then handed over to Takeru to share their progress.
Takeru humbly introduced the tech stack of the prototype he has built so far. Though ‘simple’, as he describes it, it looks promising. However, he expresses some concerns about the development work. There is a lack of developers for the scale of the system that their team is envisioning. Overall though, Takeru is very optimistic and openly invites other employees to join the project. Yohei sees that this system will not only be useful internally but can also be sold along with other HENNGE products like HENNGE ONE one day.
“How to Avoid Spam-Filter” by Ryota
Email has become so ubiquitous and a main form of communication, but Ryota tells us that the first web-based email service — Hotmail, was launched around in 1996, which is not so long ago considering how much the technology has advanced since those early days. Ryota gives a brief introduction to the history of email. Nowadays, on average 300 billion emails are sent per day, but a huge portion of them are spam emails. Therefore, most email service providers have spam filters so that these unwanted or sometimes malicious emails will not reach their customers’ mailboxes.
However, as Ryota explains, these spam filters sometimes cause trouble for our customers too. He recounts an incident in the past, where our customers accidentally sent bulk emails to their own email addresses. They use our email relay service and a third-party spam-filter, and as a result, our IPs were blocked; therefore, their emails experienced significant delays.
Ryota concludes that troubleshooting email problems are usually very difficult. It relies on high-quality monitoring tools and cooperation from customers. His story shows that even a generally useful tool, like a spam-filter, can be troublesome sometimes.
“Cleanup Your I/O” by Camilo
In his talk, Camilo teaches us what functional programming is, and what it is not.
He starts with what functional programming is not. It does not mean that I/O is not allowed. It does not mean that callbacks are not allowed. Last but not least, a program with only immutable variables does not make it purely functional. So what is functional programming? The first necessary condition is that each function can only produce one value of type b, given one value of type a. However, it is not sufficient. Side effects are one of the things that developers dread. A seemingly harmless function can do all sorts of crazy things. A side-effect is the number one enemy that functional programming tries to fight off.
To better understand function programming, we need to understand what side-effect is. Camilo tells us that “a side effects are anything that violates referential transparency.” What is referential transparency then?
Referential transparency: An expression e is referentially transparent if for all programs p every occurrence of e in p can be replaced with the result of evaluating e without changing the meaning of p.
In functional programming, writing pure functions usually force developers to have a clear separation of concerns, which comes hand-in-hand with the goal of eliminating side-effects. However, when a program depends on the results of I/O operations, it is very tempting to intertwine program logic with I/O operations, which can cause a lot of undesired side effects, and lead to confounding or inconsistent results. Camilo then walks through an example of how to separate I/O operations from program logic.
He concludes that even if one does not want to adopt functional programming, the key concepts of it can still be applied in other programming paradigms, one being the separation of program logic and I/O.
“Humans today, Cyborgs tomorrow?” by Dima
Dima explores the topic of whether one-day science and technology will be mature enough to put our brain inside a computer, or more practically speaking, to simulate the human brain in a computer. He first presents a graph that shows the trend of the number of calculations a computer can make per second, which predicts that computers will be able to make the same number of calculations that a human brain does in the year 2025, which provides a very optimistic outlook of the realization of human brain simulation. While this research seems irrelevant to most of our day-to-day life, he explains that the preservation of the human brain is important for issues like space exploration and the preservation of humanity. Long story short, it would be useful if we were able to simulate the human brain, and it seems plausible. However, we all know that the human brain is a complex structure, so is it just a matter of “the number of calculations per second?”
The answer is no. Dima gives us a brief overview of the structure of the human brain. Different parts of the brain have their “main responsibilities” but are usually shared or integrated with other parts too. There are many different types and shapes of neurons and neuroglia. We have learned a lot about their appearances but it does not allow us to clearly understand their functionalities right away. To simulate a human brain, we first need to understand how it works, and we are still quite far from that.
Nevertheless, Dima concludes his presentation with a very hopeful and optimistic tone by showing us some beautiful images of the brain and telling us ways to support the research field — one, surprisingly simple enough, being just to use computers more. That we can all do, right?
“The Nuts and Bolts of GraphQL” by Laurence
In his talk, Laurence teaches us how to implement a GraphQL server. Laurence starts with a conceptual model of what GraphQL is. A GraphQL api is an alternative to a RESTful api. An important distinctive concept is that in GraphQL, the api describes the data as data models, or a schema, a technical term in the GraphQL world. He then shows us some tools that allow us to visually introspect schemas, which are very useful for development. This is a huge plus for using GraphQL.
Laurence proceeds to talk about the technical side of a GraphQL server. There are two approaches when defining a schema: schema-first and code-first. In the schema-first approach, one declares the types and relations between objects in the schema. Resolvers, which is another important concept to be introduced later, are defined separately. In the code-first approach, one defines the schema using code through some third-party libraries. Laurence personally recommends the code-first approach because it is more type-safe.
He then walks us through an example of how a GraphQL query is executed using Gohunter, an internally developed web application that uses GraphQL, which leads to the “nuts and bolts” of a GraphQL server. The walkthrough is elaborate and clear. He introduces the concepts of contexts, data loaders, and resolvers. He explains where and how they are used when resolving fields in a GraphQL query.
Towards the end, he shows some examples of managed GraphQL services, including Apollo and AWS Amplify.
“Customer Stage Visualization: TCP/Karin” by Iwano
In his talk, Iwano introduces us to ‘Teal Communication Platform’ (TCP), an in-house web application for sharing customer information of HENNGE One within the company. Built on Nuxt.js and Express, TCP collects data from various cloud services such as SalesForce and Google Apps and then presents the data to HENNGE employees in a meaningful way.
He then shares with us the exciting new feature their team is planning to implement this year: customer stage visualization. Customer Success Division identified five different stages that our customers can reach as they become more familiar with HENNGE one. Customers face different kinds of problems at each stage so it is necessary to identify where they are now in order to best assist them.
Having given a brief overview of the new feature, Iwano then lays out clearly the current progress of TCP and what the finished feature is expected to look like. Essentially there will be two views — an overall analysis view that illustrates the distribution of our customers across various stages, and an individual analysis view that details the information of a particular customer. He highlights some core indicators on the individual analysis view, including labeling, scoring, and timeline. Labeling refers to the labeling of the customer and person-in-charge in ways that are meaningful to us. Scoring shows a customer’s scoring in our internal metrics. The timeline indicates the type of interactions we had with the customer and when those interactions happened.
Iwano demonstrates to us what it means to have a passion for problems. Although TCP is still in its early stage of development, we hope that one day it will achieve its goals and help CS members to do their jobs more effectively.
After all the awesome talks, we had our virtual beer bash on Zoom. Unfortunately, we did not take a group screenshot during the official beer bash but here is a photo of a few of us who tried socializing on Online Town.
