What Is Kotlin?
After a 15-hour journey, we arrived in San Francisco on Tuesday so that we would be fresh for the conference. This gave us a good day and a half to explore the sights and the city itself.
Like most other tourists, we rented bikes to take a trip over the Golden Gate bridge to a small town called Sausalito. Biking also was a good activity to stretch our legs after the flight. Everywhere views were as picturesque as one can think and we also got a bit lucky with the weather every day.
We scheduled our trip so that after a few hard days in the conference we would still have a couple of days to spare before flying back home. During these days, we visited the legendary prison island Alcatraz AKA the Rock, rented a minivan and headed out from SFO to Levi’s Stadium to see the 49ers host Arizona Cardinals, we also visited Wente Wineyards and Rios-Lovell Estate Winery in Livermoore. Inevitably, we also got lost in an outlet mall for a few hours.
The Venue & Arrangements
The conference was held in Pier 27 not far from the Fisherman’s Wharf or downtown. The venue was nice and well-suited for a conference. There were three rooms named after European cities – St.Petersburg, Munich and Prague. St. Petersburg was the biggest and was used for keynotes and the main speakers. Munich was on the same (1st) floor and was a little smaller than St. Petersburg. Room Munich was located on the second floor and was just a little smaller. The rooms were perfectly sized for the 1200 participants of the conference. A funny fact that we learned: when the venue doesn’t serve as an event venue it is an actual port that is in use.
As the Kotlin Conf 2017 was the first of its kind ever, it was no surprise that there were some major problems with the arrangements like wifi not working basically at all, breakfast ran out both mornings, long lines for food at lunch and the evening party, beverages only available on the second floor, sounds carried between rooms St. Petersburg and Munich, etc. Not everything was wrong with the arrangements, though. Good parts included very smooth registration and great snacks.
The conference was divided between three rooms with varying capacities each having session at the same time so there was always three choices. Here’s a list of the best presentations we attended. All of the videos can be found in Youtube.
Day 1 keynote – Andrey Breslav (Kotlin X, JetBrains), Stephanie Saad Cuthbertson (Android PM manager, Google) et al.: Some announcements regarding the Kotlin. Notably Kotlin 1.2 RC, support for iOS with Kotlin/Native v0.4 and IDE support for Kotlin/Native. Interesting stuff coming, though we weren’t totally convinced whether Kotlin/Native is the wisest choice to be concentrated by JetBrains. For some reason, there’s is no video available for this session.
Introduction to Coroutines – Roman Elizarov (Kotlin): Interesting introduction to the Kotlin’s new (introduced in 1.1) take on asynchronous programming. Key takeaways:
suspendkeyword to make suspending functions.
- No need to create a new thread for each block of asynchronous code as threads are expensive. Instead Kotlin abstracts this away and executes blocks by default in threads managed automatically.
- Many parts of asynchronousity implemented as library methods rather than with language constructs.
Building Languages Using Kotlin – Federico Tomassetti (Language author): Extremely interesting case study on how to build a simple domain-specific language (DSL) using Antlr and Kotlin. Data classes shining once again. Federico has also wrote a book related to the topic of the presentation called How to create pragmatic, lightweight languages, though it still features Java.
Bootiful Kotlin – Josh Long (Spring core team): One of the best presentations ever. Such an amount of energy, enthusiasm and knowledge. Even though it has been heard many times earlier that Spring 5 is providing great experience with Kotlin, it was absolutely clear after hearing Josh’s presentation with lots of examples and tips. Josh’s live coding was just great! Spring 5 was also introduced quite well and looks really promising, though the poor interoperability of functional & reactive style with SQL databases seems quite problematic for any real applications.
My Life as a Tech Transfer Monad (Day 2 keynote) – Erik Meijer (Facebook): Erik, as always, had some interesting stories to share. This time he spoke about his current projects at Facebook related to the probabilistic programming paradigm built on top of PHP. Very interesting stuff and according to Meijer also the future of programming whereas the current way of programming will be done by machines.
Day 1 ended with a party on the 2nd floor. Before the actual party there was something odd marked in the program: Party keynote. Maybe you could’ve guessed what it was about had you googled the performer marked on the schedule. We didn’t so it was a great surprise to find out that there was a special kind of magician performing. This magician was called Michael Carducci who happens to be a former programmer so the magic so was excellently targeted to the audience. In the actual party we had a great chat with the JetBrains sales presentative to whom we got to express all of our concerns and got some great insights in to what is being done for other JetBrains products like IntelliJ IDEA.
The Kotlin Conf 2017 was a great success even with the problems in the arrangements. The main takeaways are:
- Kotlin/Native is coming and it seems very ambitious. We, like many others, weren’t totally convinced that this is the direction that should be taken as it is extremely time-consuming and the odds that it will succeed aren’t on Kotlin’s side. Yet, the team seemed to believe it is the best thing to concentrate on and surely it would be great to have a single language to rule them all. We’ll see about that in the upcoming years.
- Coroutines are an interesting approach to the problems of asynchronicity and deserve a more in-depth exploration.
- Spring 5 <3 Kotlin
- The Kotlin Conf might very well be organized in Europe next year – looking forward to that!
Hope to see you next year in Kotlin Conf 2018 (in Europe)!
We are always on the lookout for great developers at Gofore. Why not see what we can offer https://gofore.com/?vacancy=net-osaaja
At Gofore we love sharing our experiences and helping the next generation of researchers. Whenever we can, we talk to students, giving them practical examples of what it is like to be a researcher/designer in a digital transformation project. Previously we ran a course at the Tampere University of Technology, this course, “Introduction to Interactive Technology” was mainly for first-year students who have just started at the university. Our take on this topic was to provide insight into how to conduct research projects in different contexts taking into consideration, for instance, special user groups such as children and people with disabilities.
Below are some points from the course that we thought would be helpful for those aspiring to become researchers.
Do your background research
Try to get acquainted with the research target, the industry and terminology as thoroughly as possible. It’s alright that you don’t know everything – that is what interviews are for. The more you know about the subject before the interview, the easier it is to conduct your research and to get to the same level as your interviewee.
Understand the objective
It is extremely important to understand what it is that your customer wants to achieve with the research. If the objective is not clear, you might end up choosing the wrong methods, wrong questions and taking your analysis in the wrong direction. Even worse, you may report findings that are not useful for the customer. So have plenty of discussions with your customer to make sure you understand each other and share the same objectives.
Choose the most suitable research methods
Not all research methods can be used for all purposes. For instance, the interview type and duration have to be thought about carefully, especially when doing research among special groups. If you are conducting a usability test, the test tasks have to be designed keeping the target user group in mind. You have to take into consideration the research objective, the group that you are studying and the possible outcome you need from the study.
Expect the unexpected
You can never prepare yourself for everything that can happen during an interview. For example, one of our researchers, Suvi faced a tricky situation when interviewing children under five years with their parents. One participant threw a real tantrum in the middle of the interview and was not cooperative at all. The solution was to distract his attention, this time it was done by trying out the Gigglebugg iPhone game while the interview continued. Discretion is key in any situation; you need to be able to interpret the interviewee and make sure they feel at ease in the situation. After conducting research for years, believe me, you get used to being out of your comfort zone most of the time.
Maintain a child-like enthusiasm
Interviewing people and getting to know their stories can be truly fascinating! Be prepared to ask as many why’s and why not’s as you possibly dare in order to delve deeper into the subject. Have an open mind and be prepared to learn things you thought you would never even come across.
Be empathic but maintain objectivity
Empathy as a word does not mean much, but it is a state of mind that should be reached while doing research. Showing your emotions and understanding how the other person feels and what their struggles are can enable a major breakthrough in the interview. If you just stick to asking questions like a robot, you probably won’t get much out of the interview. However, when analysing the results, you need to maintain objectivity and treat all the interviewees as equal.
Analyse the results with a colleague
This is not a requisite, but sometimes it is easier to find the storyline and missing links while doing analysis with a colleague. For example, creating an affinity wall makes the data visual allowing several people to pitch into the analysis. In addition, you get confirmation that the findings are not just your own, but others can back them up as well. Most of all, doing analysis and reporting with a colleague can be fun and inspiring!
We hope that these tips will help the next generation of user researchers as they navigate their academic studies. We are always open to comments, suggestions and questions about user research and service design, and if these tips have inspired you, why not comment below or get in touch.
GOFORE OYJ PRESS RELEASE 10.11.2017 AT 12:00
The University of Helsinki and Gofore continue their cooperation. Gofore was chosen for the next four-year term of the agile development framework arrangement of the University of Helsinki. The arrangement covers development and expert services and involves four suppliers.
The maximum value of the University of Helsinki’s framework agreement is eight million euros. Gofore estimates that its share of the agreement will be approximately a million euros per year.
The same suppliers who partnered with the University of Helsinki for the previous four years will continue this cooperation in the new agreement.
The University of Helsinki and Gofore are working together to develop the digital services of the largest university in Finland in order to meet the varied needs of the users.
“Gofore’s experts provide the University of Helsinki with software design, development, consulting and other services in accordance with the principles of agile development,” says Gofore’s Business Manager Ville Nordberg, who is in charge of the agreement.
For more information, please contact:
Business Manager, Education & Transportation
tel. +358 (0)50 506 0017
Gofore Plc is a digital services company operating since 2002. We offer modern services that help operators in the private and public sectors to face digital change. Our mission is to change the world for the better through digitalisation and by renewing ways of working. Our services cover the entire value chain – from management consultation to service design and implementation as well as cloud services. Staying on top and ahead of the development requires us to be fast-paced, regenerative and competitive. We have 15 years of expertise in this. Our operations are characterised by top expertise, alacrity and genuine interaction. We believe that we are the best partner to our clients on the path to digital change. Gofore currently employs over 350 people in Helsinki, Jyväskylä, Tampere, Swansea and Munich. Go-fore was chosen as the best workplace in Finland and the second-best workplace in Europe in the Great Place to Work® survey in 2017. More information: www.gofore.com.
My previous blog post focused on the side effects of ‘over documentation’s’. I identified reasons why so many projects are struggling with documentation and listed a few solutions how to prevent it. One of the solutions was that you should keep your documentation close to the source code.
Documentation as a service
As I previously wrote, documentation is valid only when it’s up-to-date. A development team will create and maintain most documentation, so it must be as developer friendly as possible.
Developers are craftsmen who make products with the help of programming code. If a developer can code and create or maintain documentation simultaneously, there is a good chance the documentation stays up-to-date. Next, we will see two examples of this ‘keep documentation close to the source code’ approach.
Dynamic style guide
A style guide is a comprehensive document that keeps track of all the common user interface elements for a project track of all the common elements for a project, from branding rules to the amount of bevelling for call-to-action buttons. On a more holistic level, a style guide defines the design philosophy for a company. A traditional way to create a style guide is in a separate pdf-document, which usually ends up being out-of-date.
A better alternative is to create a dynamic style guide. A Finnish software and consulting company SC5 Online has created a useful open source tool for this. The tool generates a style guide catalogue, where user interface elements and styles are grouped and visible to everybody. When a developer edits a style, changes will be updated to the product’s UI and the style guide catalogue.
The dynamic style guide eliminates the need for static style guide documents. Business people can review styles online and developers can make quick changes anytime. Ultimately, this approach simplifies and standardizes the whole UI design.
Software components need APIs (application programming Interface) to communicate with other components. Some believe that we will soon have an ‘API economy’, where organisations can positively affect their profitability via APIs. Anyhow, API documentation is a crucial part of the quality of software projects; the traditional way to have API documentation is in excel-documents, where data models, operations, URIs etc. are defined.
Swagger is a good example of a modern documentation tool. Swagger is a specification format that describes an API in a common language everyone can understand. Swagger packs everything about the API in a single and dynamic file which is easy to use.
The benefits of Swagger are clear. With Swagger, it is possible to design and document APIs simultaneously, thus keeping the blueprint and documentation in sync. Developers and non-developers can both have input to the API design because of the user-friendly UI. Swagger is readable by both human and machine, which gives a possibility to share documentation externally and allows powerful integration. Swagger contributes to API design in the same way that SC5 Style Guide contributes to style design – simplifying and standardising it.
Minimum Viable Documentation
Although all projects are unique, there are general documentation patterns that can be used. While reading my ‘Minimum Viable Documentation’ list, think how you could keep this documentation close to the source code in your project:
- How to get started – a tutorial for how a new developer sets up a development environment
- Design guidelines – see above
- API documentation – see above
- Definition of Done – define teams’ responsibilities
- Coding conventions – a set of guidelines and standards for programming languages
- Licenses – make visible which open source and other licences are used in the product
- High-level architecture descriptions – illustrates software architecture from different angles, for example, infrastructure, application, and integration. Favour pictures
- Maintenance process – if you can document a maintenance process, you can most probably also script it
- Principles for general tech. features – such as version control, authorisation, authentication, logging, validations, localisations etc.
- The most complicated business rules – such as complex algorithms, mathematical formulas and extensive searches
Fossil of the Project
‘It’s code which always wins; not comments or documentation’ is a common phrase. Still, many projects create way too high standards for documentation, although working software should be valued over comprehensive documentation.
Raise a hand those of you whose software project’s documentation needs updating? If you are working on a normal software project, you probably raised your hand. Typically, project documentation is outdated, contains useless information, and is scattered around. This blog post reveals the reasons for this ‘documentation chaos’ and how you can prevent it.
Reasons for The Chaos
Before we jump into the details, it’s good to understand what `documentation` means. Documentation is the information that describes the product to its users. This blog post focuses only on maintained documentation so, user stories, whiteboard drawings, PowerPoint presentations and UX-sketches are ignored.
The next question is, why software projects are facing documentation chaos? One reason is that, while only programmers see the code, documentation is visible to everybody. Therefore, documentation can be seen as a symbol of the quality of the software. Some projects` boundary conditions also require high documentation standards.
Another reason is the project lifecycle. The development team gather and document random information when a new project starts. When the deadlines are coming and budgets are running out, the team concentrates on developing software and fixing bugs and stop maintaining the documentation. In my experience, this is a very typical situation in software projects.
Universities have a very theoretical approach to software development. Courses are full of rules and regulations about how you should write documentation. In addition, courses, for example, determine at a very detailed level what documentation is needed in different phases and reference groups. This approach gives a misguided picture to students and reflects on the whole software development community.
Sometimes documentation chaos is caused by the software project structure. If the project has only a few skilled developers but many consultants and managers, documentation becomes an absolute value. The result is a massive set of documentation without working software. While documentation is visible to all, documentation costs are not.
But it’s just a piece of paper?
When the amount of documentation exceeds a certain level, documentation turns against itself. This is because documentation is valid only when it’s up to date. Documentation costs are easy to understand through this example.
Let’s have a project which needs only 200 pages of documentation in total. According to these sources (link1, link2, link3), it takes 2 – 4 hours to write a text page. We are fast writers so writing 200 pages of documentation takes us 400 hours. It’s only 53 man-days and is easily defensible.
Let’s decide that the project’s lifespan is two years. According to the same sources, it takes 1 hour on average, to revise a text page. If documentation needs to be changed on average once a month, it takes a total of 200 man-days. This time, it is more but still manageable.
Let’s have a second project which needs 2000 pages of documentation. Usually, this means that the product’s business rules are part of the documentation. On this occasion, the numbers are 530 and 2000 man-days. It’s more than 2 years non-stop work, for a team of five.
Less Documentation, Less Worries
‘If I had asked people what they wanted, they would have said faster horses’ is a famous quote by Henry Ford. Product owners and other decision makers want the top product which is fully documented. Unfortunately, documentation is expensive as the previous example showed.
The best way to prevent documentation chaos is to focus on quality over quantity. It’s better to have one page up to date than ten pages outdated. Here are some practical tips to keep documentation chaos under control:
- Make documentation costs visible. New documentation is a new user story and will be will be prioritised against other stories
- Don’t create documentation without the team commitment that documentation must be kept up to date
- Keep documentation close to the source code. Comments, dynamic guides and scripts beat Word documents and wiki-pages
- Document every business rule and screens only if someone `holds a gun to your head’
- Most of the formal UML-models are too heavyweight for today’s software development
- The more detailed the documentation, the greater the amount, and the bigger the risk that documentation is outdated
- Create a culture where most design, such as sketches, drawings, and prototypes, will be disposable
- Use images and avoid long text. Humankind has painted caves ten times longer than it has written texts
Integration problems, complicated customers, and wrong technologies. Many typical problems are, at least partly, coming from outside. In contrast, documentation chaos is self-caused and self-perpetuated. The positive side is that the project team has the power to stop the chaos.
My next blog post will share more concrete examples of how to improve documentation and what is my ‘Minimum Viable Documentation’.
After a long week of hard work Mark was finally ready to execute the final tests on his laptop. A few taps on the keyboard activated the screen and progress bars started slowly moving. Mark was confident that all would go as planned and he was happy to give a demonstration of his skills to the audience who were mainly dressed in black suits and white helmets. Renewing the production lines in a local factory had been a significant investment. Project manager Mr Jokinen, standing next to Mark, was waiting anxiously for Mark to nod as a sign that everything would be ready to start the production. Mark was looking at his laptop and all the tests had been completed successfully, although there was one warning message. Mr Jokinen was happy to push the start button and the audience started cheering as the production successfully started.
Mark, in his 40’s, is a recognized expert in his field of engineering automation. He is trusted by his bosses and clients. He plays a critical role in large factory automation projects. There are multiple members in the team but for final integrations, he is the subject area expert who is familiar with the software tools and factory specific configurations. There are few people with similar competencies within their company but they don’t get too many opportunities for interaction. It has taken years for Mark to gain the practical knowledge and skills to master all tools and information. He has been very active contacting software companies to request new features for engineering tools. The majority of his ideas have been implemented over the years and the introduction of new technologies have cut many days from project installations. However, the software tools and installation process have grown to be quite complicated.
Recently Mark hasn’t been very satisfied with his job. He does his job well but feels that he hasn’t been able to create any major improvements in the broader sense. His bosses treat him as a wizard but recently, the reason for this has been more related to their lack of interest to understand Mark’s work than his performance in solving complex problems. As a consequence of this Mark has been thinking about the possibility of getting into teaching which he enjoyed during the last years of his studies at university helping freshmen.
The ‘Mark’ Persona – an imaginary representation of a real user group based on user research data.
There are also other types of user groups involved in the same process. Mark is a good example of a user who has been benefitting from the incremental development of technology. Growing a digital layer on top of physical products has been contributing significantly to the speed and efficiency of his work. Still, the added value of technological development has been focused on the rational dimensions of value. This has been the result of years of technological development in many fields. Designers have been part of the development but their focus has been primarily dedicated to consumerism rather than value creation.
Today design is focused on gathering user insight and integrating that insight throughout the development of better businesses, processes, services and products.
Imagine we needed to design better processes and tools for Mark
- Could we come up with solutions which would allow Mark to understand and share his role in a bigger context?
- Could we let him share some of his experience with other experts, maybe even outside his team?
- Could we, somehow, make him more satisfied with his work?
- Could we build a system to support his other motivation for teaching as well?
Evolving the role of the users (customers) within value creation is a fundamental design concern. Including customers as part of value co-creation will open up opportunities to better address more subjective dimensions of value. We must acknowledge customers as humans, rather than rational actors, belonging to a social process.
Digital transformation will create new opportunities for value creation
In order to do this transformation successfully, we believe that systematically gathering customer insight, developing the role of the customer from consumer to co-creator, and transforming the organization to better manage value creation are essential steps.
The focus of design is value creation – for all stakeholders
Blog series “Digital Companion”
In blog series “Digital Companion” Gofore’s expert services managers explain how digitalization turns from festive speeches into actions. Change is accelerating exponentially right now. In this change, organizations require assistance with project management, leadership, service design, graphic design, programming and data analysis. This – and as a cherry on the top cloud infrastructure management – can all be provided by Gofore.
Previous posts in the blog series: