August 2018

Applying ‘Product Thinking’ to UX

Life’s too short to build something nobody wants.

Ash Maurya in “Running Lean: Iterate from Plan A to a Plan that Works”

UX/UI in Xpand IT

During recent years, Xpand IT has been investing in supplying UX/UI services, which has resulted in significant growth of our HCI (Human Computer Interaction) portfolio in B2B and B2C application software and mobile apps to both Portuguese and international clients.

Our interfaces and user experience design have always been based on the User-Centred Design concept and have been delivered in almost all industries: retail, banking, telecommunications, insurance, health, transportation, e-commerce, mobility, public utility, and others.

We are prepared for the next challenges concerning user experience in digital products  –  for example, we increasingly propose and design CUI (Conversational User Interfaces). However, we still find traces of a mentality that is not completely receptive to the idea of the digital product, and is more worried about lining up a huge number of functional requirements that sometimes are completely inappropriate to the needs of the final user of the product.

The immediacy experience offered mainly by social media apps is transforming our expectations concerning the way we want to use products and digital services. As UX designers, we feel the need to analyse the complete ecosystem that brands and users share, in order to define how a business can still be relevant in a world where immediacy is king.

User-Centred Design – with its concept of bringing users into the design process – exists to reduce the gaps between those who create a product and those who use it. The UX team from Xpand IT is focused on finding these gaps, preventing them and eliminating them.

Thinking about the product

In its traditional approach, UX/UI design is focused on the functionality of a digital product: the appearance of the interface (UI) and how users interact with it (UX).

However, a group of functionalities is just a small and fragile part of a product: it is just some of the many possible solutions to the problem the product is trying to solve.

It is not that functionality is not important, but it is usually secondary to the reason why people use a product. The reason is simple: the user uses the product to solve a specific problem in the real world.

In practice, this means we have to understand the product first. A particular function may (or may not) be a useful part of a product, but without the product, that functionality may be wasted.

For example, Uber’s app is frequently used as a good example of user experience design: one of the functions that creates the most empathy is the countdown that shows the time until the car is due to arrive, which is certainly convenient and is related to the goal of the app. However, what makes Uber so attractive is the ability to obtain quick and easy transportation in your area at any time. Even if the countdown functionality did not exist, the app would still be useful. In other words, Uber was conceived having in mind the goal of the product and not the resources that came with it.

Applying Product Thinking to the user experience has been experiencing increasing adherence by UX designers worldwide and expanded when well-known international professionals – such as the German Nikkel Blaase – brought it to a wider sphere of public disclosure. By the way, this talk might be a good starting point to learn more about the subject.

Defining the product

All in all, companies tend to assume that the more functions, the more useful the product will be; that the broader the target audience, the more people will use it; that the more use scenarios are mapped out, the more it will be present in people’s lives.

Which is not necessarily true: there are plenty of products out there with loads of functions that are not used by anyone.

A very common mistake is to start immediately by designing any kind of interface.

However, if the user’s problem has not yet been identified, why are functions and interfaces already being thought about?

It is precisely in this aspect that a lot of digital products fail: they try to solve a problem that does not exist.

A few things need to come before the solution that will be found to solve it: deeply understanding the problem, who the user is, and how the product is going to solve this problem.

However, the process of creation of digital products tend to be a little chaotic: inside a company, there are different departments, areas and businesses that have different opinions about what the product must be, for whom it must be designed and, mainly, which functionalities it must have.

That is why a thorough reflection to clearly define the scope and requirements of a digital product should be done:

  • Why are we investing in this product? What is the business deal in creating this product? Which data and statistics prove that the product is viable?
  • What is the product? What is its primary function? How does it stand out from the competition?
  • For whom is the product being created? What is the profile of the typical user? Which specific behaviours or needs of this user should be considered?
  • Where and when will the product be used? At what time and how much? At home, in traffic, at work? Is it a product for constant use or a one-time use product?
  • How do we want people to use the product? What do we want people to feel when using it? What problems do we want to solve?

Finding the correct answers to these questions constitutes the basic strategy to define a product and causes alignment between the various business areas of companies. This process, when well driven and supported by UX designers, brings huge advantages:

  • Build the right functions and interfaces for the user.
  • Understand the experience as a whole and not just a visual and interaction layer the user will see.
  • Ensure that the product solves real problems for its target users.
  • Minimize the risk of building something nobody would want to use, or that does not last a long time.

Conclusion

When this kind of thought about the product is part of the process from the beginning, UX designers can ask the right questions, communicate more efficiently and suggest appropriate functionalities.

It is easy to be overwhelmed with infinite functionality possibilities and ignore some of the important parts of the design process.

Avoid the potential traps when focusing only on functionality instead of on product usability, thereby turning the thinking about the product into part of the UX design process of the mobile or web app. There is nothing wrong with functionality, but it should not be more important than the real goal of the product.

Have this in mind, and the final result will be a digital product that is created, tested and personalised for the defined target audience, with greater probabilities of becoming essential and making users’ lives easier.

Carlos Neves

Senior Ux & UI Consultant, Xpand IT

Carlos NevesApplying ‘Product Thinking’ to UX
read more

Aplicar ‘Product Thinking’ a UX

A vida é curta demais para construir algo que ninguém quer.

- Ash Maurya in “Running Lean: Iterate from Plan A to a Plan that Works”

UX/UI na Xpand IT

A Xpand IT tem investido nos últimos anos na oferta de serviços UX/UI, o que resultou num crescimento significativo do nosso portfólio HCI (Human Computer Interaction) em software aplicacional B2B e B2C e aplicações móveis em clientes portugueses e estrangeiros.

Os nossos interfaces e design de experiência de utilização, desde sempre baseados no conceito de Design Centrado no Utilizador, estão presentes em praticamente todos os setores de atividade: retalho, banca, telecomunicações, seguros, saúde, transportes, e-commerce, mobilidade, utilidade pública, entre outros.

Estamos preparados para os próximos desafios da experiência de utilização em produtos digitais – por exemplo, propomos e desenhamos cada vez mais CUI (Conversational User Interfaces) – mas deparamo-nos ainda com vestígios de uma mentalidade não totalmente alinhada para o pensamento de produto digital, mais preocupada em desfilar uma enorme quantidade de requisitos funcionais, por vezes totalmente desadequados das necessidades do utilizador final do produto.

A experiência de imediatismo oferecida, sobretudo, pelas aplicações de social media, está a transformar as nossas expetativas em relação à forma como queremos utilizar produtos e serviços digitais. Enquanto UX designers, sentimos necessidade de analisar o ecossistema completo que as marcas e os utilizadores compartilham, para definir como o negócio ainda pode ser relevante num mundo onde o imediatismo é rei.

O Design Centrado no Utilizador – com a sua mentalidade de trazer os utilizadores para o processo de design – existe para reduzir as lacunas entre quem cria um produto e quem o está a usar.

A equipa de UX da Xpand IT está focada em encontrar essas lacunas, preveni-las e eliminá-las.

Pensar o produto

Na sua abordagem tradicional, o design de UX/UI tem-se concentrado nas funcionalidades de um produto digital: qual o aspeto do interface (UI) e como os utilizadores interagem com ele (UX).

No entanto, um conjunto de funcionalidades é apenas uma pequena, frágil, parte de um produto: são algumas das muitas soluções possíveis para o problema que o produto tenta resolver.

Não é que as funcionalidades não sejam importantes, mas geralmente são secundárias em relação ao motivo pelo qual as pessoas usam um produto. Essa razão é simples: o utilizador usa o produto para resolver um problema específico do mundo real.

Na prática, isso significa que temos de compreender o produto primeiro. Uma funcionalidade pode (ou não) ser uma parte útil de um produto, mas sem o produto, essa funcionalidade poderá ser desperdiçada.

Por exemplo, a app da Uber é frequentemente usada como uma boa referência de design de experiência do utilizador: uma das funcionalidades que cria mais empatia é a contagem regressiva que informa o tempo que resta até à chegada do carro, o que certamente é conveniente e está relacionado com o objetivo da aplicação. Mas o que torna a Uber tão atraente é a capacidade de obter rápida e facilmente um transporte na sua área a qualquer hora. Mesmo que a funcionalidade de contagem regressiva não existisse, a aplicação ainda seria útil. Por outras palavras, a Uber foi pensada tendo em mente o objetivo do produto, não os recursos que o acompanham.

A aplicação de Product Thinking à experiência do utilizador tem tido uma adesão global pelos UX designers e ganhou dimensão quando profissionais de reputação internacional – como o alemão Nikkel Blaase – a trouxeram para uma esfera mais alargada de divulgação pública. A propósito, esta talk poderá ser um bom ponto de partida para aprofundar o tema.

Definir o produto

De um modo geral, as empresas tendem a assumir que quantas mais funcionalidades houver, mais utilidade terá o produto. Que quanto mais abrangente for o público-alvo, mais pessoas irão utilizá-lo. Que quanto mais cenários de uso forem mapeados, mais ele estará presente na vida das pessoas.

O que não é necessariamente verdade: o que não faltam por aí são produtos com toneladas de funcionalidades que não são usados por ninguém.

Um erro muito comum é começar imediatamente por desenhar algum tipo de interface.

Mas, se o problema do utilizador não está ainda identificado, porque é que se está já a pensar em funcionalidades e interfaces?

É justamente neste ponto que muitos produtos digitais falham: quando tentam resolver um problema que não existe.

Entender a fundo o problema, quem é o utilizador e de que forma o produto irá resolver esse problema, precisa de vir antes da solução que será encontrada para o resolver.

No entanto, o processo de criação de produtos digitais tem tendência a ser um pouco caótico: dentro de uma empresa são diversos os departamentos, áreas e negócios que têm opiniões diferentes sobre aquilo que o produto deve ser, para quem deve ser desenhado e, principalmente, que funcionalidades deve conter.

Deve-se, por isso, realizar uma reflexão profunda para definir com clareza o âmbito e os requisitos de um produto digital:

  • Porque estamos a investir neste produto? Qual a oportunidade de negócio em criar este produto? Que dados e estatísticas comprovam que o produto é viável?
  • O que é o produto? Qual a sua principal funcionalidade? Como se destaca da concorrência?
  • Para quem se vai criar o produto? Qual o perfil do utilizador típico? Que comportamentos ou necessidades específicas desse utilizador devem ser tidos em conta?
  • Onde e quando o produto será usado? A que horas e com que frequência? Em casa, no trânsito, no trabalho? É um produto de uso constante ou algo para usar uma vez só?
  • Como queremos que as pessoas usem o produto? O que queremos que as pessoas sintam ao utilizá-lo? Que problemas queremos resolver?

Encontrar a resposta correta a estas perguntas constitui a estratégia básica da definição de um produto e provoca alinhamento entre as várias áreas de negócio das empresas. Este processo, quando bem conduzido e auxiliado por designers UX, traz enormes vantagens:

  • Construir funcionalidades e interfaces corretas para o utilizador.
  • Entender a experiência como um todo, não apenas a camada visual e de interação que o utilizador verá.
  • Garantir que o produto resolve problemas reais dos utilizadores.
  • Mitigar o risco de construir algo que ninguém queira usar, ou que não dure por muito tempo.

Conclusão

Quando este tipo de pensamento sobre o produto faz parte do processo desde o início, os designers UX podem fazer as perguntas certas, comunicar com mais eficiência e sugerir as funcionalidades mais adequadas.

É fácil ficar atolado em funcionalidades infinitas e ignorar algumas das partes importantes do processo de design.

Evite as potenciais armadilhas de se concentrar apenas nas funcionalidades, em vez da usabilidade do produto, tornando o pensamento do produto parte do processo de design UX da aplicação móvel ou web. Não há nada de errado com as funcionalidades, mas elas não devem tornar-se mais importantes do que o objetivo real do produto.

Tenha isso em mente e o resultado final será um produto digital criado, testado e personalizado para o público-alvo definido, com maiores probabilidades de se tornar indispensável e tornar a vida dos utilizadores mais fácil.

Carlos Neves

Senior Ux & UI Consultant, Xpand IT

Carlos NevesAplicar ‘Product Thinking’ a UX
read more

Kotlin and a brighter future

Picture this odd world called The JVM.

(From here on, it’s better to read it with David Attenborough’s voice…)

At first there was only one living creature on it: its name was Java. Java was fun; Java was new; Java was simple; Java was powerful – yet Java wasn’t enough. Other species started to come to life, such as: Ceylon, Groovy, Scala, Clojure, Frege, Kotlin. Even Java itself evolved over time. “But why so many species?” is a question one might ask. Had the mighty creator failed with its own creation? Were the other Gods (the programmers) not pleased? Maybe they just weren’t happy enough…who knows!

Now, this is the case for Kotlin.

Enough with the “Life on Earth” analogy, but you can keep the David Attenborough voice – we all know how incredible it is.

Yes, the question is, indeed, why yet another programming language for the JVM? I can’t answer that, I really don’t know, but I believe I have some arguments that might help shed light on why this is a strong specimen.

Kotlin’s evolution

Although it seems like it is, Kotlin is not completely new. Its first commit dates back to 8 November 2010 and it has been slowly maturing over time, just like a fine whiskey.

General adoption has been increasing in recent months helped by major events such as Spring adoption in version 5 or Google I/O 2017, where Google announced official support for the Android platform. 2017 was also the year of the first KotlinConf, where it became noticeable how much Kotlin is reaching beyond the Android World.

It is also curious to see the number of StackOverflow questions related to Kotlin increasing after the Google I/O announcement and the fact that it now appears on the TIOBE Index.

As for public open source projects on GitHub, according to GitHut 2.0, for 2017/Q4 in the top 50 list, Kotlin scores:

  • 16th place for projects stars for a total of 0.480%
  • 17 th place for issues, totalling 0.489%
  • 23 rd place on pull requests making a total of 0.351%
  • 19 th place for pushes, totalling 0.424%

…with overall positive growth.

Java interoperability

Kotlin stands out amongst many, mainly because of its ability to interop easily with Java on the JVM runtime.

It compiles to Java Bytecode and adds practically zero overhead, it being possible to compile to versions 6, 7, 8 and 9 of Java bytecode and at the same time take advantage of the features of each version. One great example of Kotlin’s power is its support for Lambda Expressions even when compiling to Java Bytecode 6. Even the Java language doesn’t provide support for them.

Tooling

Kotlin is developed by JetBrains, making it a first-class citizen within IntelliJ IDE, Android Studio and CLion. Features such as refactoring, code generation, code completion, compiling to bytecode and sneak-peeking the bytecode on the fly – and even a Java to Kotlin converter – are all there for your delight.

The command-line compiler (kotlinc) has a REPL mode that can be used to easily try out Kotlin snippets of the fly.

Mutiplatform targets

Compilation for multiple platforms is supported. Using Kotlin you can target the JVM, Javascript and LLVM.

Let me try to rephrase that to get the point across:

“Program with Kotlin and get the server-side code deployed to JBoss; share business logic code with the Android client application and also the JS/HTML web client. Oh, let’s not forget that cute IoT device – share some code with it as well. What’s that? You want iOS? Sure, why not!”

Kotlin/Native leverages LLVM to ease natively targeting a vast number of platforms like Windows, Linux, MacOS, iOS, Android and WebAssembly.

Kotlin for Javascript enables you to transpile Kotlin into Javascript, making it possible to, for example, create React web apps.

A great showcase of this feature is the KotlinConf 2017 companion application, which is entirely implemented using Kotlin, covering backend, frontend and mobile applications.

Embracing Kotlin as a team

Starting to use Kotlin doesn’t have to be a risky decision! By nature, it works incredibly well with existing Java code and it’s even possible to have both Kotlin and Java code on the same project. Developing new features in Kotlin on an existing project can make it a good approach for adoption with low risk as there’s no need to scrap everything and start from the ground up with a new programming language/technology.

Using Kotlin has also become a day-to-day reality for Android developers. Most Android GDEs (Google Developer Experts) advocate and use Kotlin on a daily basis and it can even be found in Android’s Official documentation.

As for non-mobile developers, such as backend developers, Kotlin presents itself not only as a way to achieve current programming language standards on the JVM while targeting Java 6/7, but also as a replacement for Java as a whole. Projects such as TornadoFX, Ktor and Spring, among many others, provide the necessary foundations for Kotlin to thrive outside the realms of mobile. And since Kotlin is almost 100% interoperable with Java, you can keep using the same frameworks you’re used to but with the syntactic happiness of Kotlin!

The most common approaches to adopting Kotlin are:

  • Re-write Java unit tests with Kotlin. Some advocate this as a good approach to dip your toes into Kotlin while not putting your production code at risk. However, from my perspective, tests should be using production code. However, Kotlin does offer some neat tricks to make unit tests more legible and compact.
  • When starting new features, instead of using Java, use Kotlin!
  • If the project you’re working is due some refactoring, apply Kotlin into the new refactored version of the code base.
  • Go full Kotlin and leave the sad days behind by saying sayonara to Java!

Kotlin language

The language itself is beautiful. Kotlin is a statically typed language with conciseness and readability as major goals.

It also attempts to solve one of the biggest problems of the Java world: NullPointerException. It does so by making nullability part of the type system and enforcing the developers to think about it explicitly.

Another aspect that makes it a top tier language is the fact that the authors attempt to bring the best features available in other languages into Kotlin itself. To name a few:

  • Extension Functions
  • Destructuring declarations
  • High Order Functions
  • Type inference
  • Functional Facilities (map, filter, flatmap, etc.)
  • Custom DSLs
  • Named parameters
  • Pattern Matching
  • Operator overload

Kotlin syntax

Here are some Kotlin snippets as a sneak peek. These attempt to showcase the simplicity and conciseness of the Kotlin language in comparison to Java.

Java Kotlin

// Class definition

class Person {

private String name;

private int age;

public String getName(){

return name;
}

public int getAge(){
return this.age;
}

public Person(String name, int age) {
this.name = name;
this.age = age;
}

public String greet(){
return “Hi ” + this.name + “, how are you doing?”;
}
}

// Class definition

class Person(val name:String, val age:Int) {

public fun greet():String {

return “Hi $name, how are you doing?”

}

}

// A Typical unsafe Java Singleton

public class Singleton {

private static Singleton instance = null;

private String someProperty = “SOME_SINGLETON”;

private Singleton() {

}

public static Singleton getInstance() {

if (instance == null) {

instance = new Singleton();

}

return instance;

}

public String getSomeProperty() {

return someProperty;

}

public String appendSomethingToProperty(String something) {

return someProperty + something;

}

}

// A simple Kotlin Singleton

object Singleton {

val someProperty:String = “SOME_SINGLETON”

fun appendSomethingToProperty(something:String) = someProperty + something

}

What’s next?

If I’ve sold you on Kotlin and you want to try it out, here are some pointers to help you:

And keep an eye out for future Kotlin articles on this blog!

João Gonçalves

Mobile Consultant, Xpand IT

João GonçalvesKotlin and a brighter future
read more

Kotlin e um futuro (ainda mais) brilhante

Imaginem um mundo muito estranho chamado “A JVM”.

(A partir deste momento, o melhor é ler com a voz de David Attenborough).

No início, existia uma única criatura. O seu nome era Java. A Java era divertida, nova, simples, poderosa… mas a Java não era suficiente. Outras espécies surgiram, tais como: Ceylon, Groovy, Scala, Clojure, Frege, Kotlin. Até a Java evoluiu com o tempo! Mas porquê tantas espécies? – é uma questão que vos pode surgir. Será que o Criador falhou na sua própria criação? Estariam os outros deuses (os programadores) descontentes? Talvez não estivessem felizes o suficiente… Quem sabe?

Então… Este é o caso de Kotlin.

Mas chega de analogias a A Vida na Terra. Ainda assim, podem continuar a ler com a voz do David Attenborough, todos sabemos o quão incrível é.

Ainda assim, a questão que se coloca é: mas porquê outra linguagem de programação para JVM? A isso não posso responder, porque não sei. No entanto, acredito ter alguns argumentos que possam ajudar a explicar porque é que Kotlin é um espécimen muito forte.

A Evolução de Kotlin

Embora pareça, a linguagem Kotlin não é totalmente nova. A sua primeira aparição aconteceu no dia 8 de novembro de 2010 e, desde então, tem amadurecido com o tempo, tal como um bom Whiskey.

A adoção desta linguagem tem aumentado significativamente ao longo dos últimos meses, impulsionada pela referência em grandes eventos, como o Spring Framework 5.0 ou o Google I/O 2017, no qual a Google anunciou o seu apoio oficial a Kotlin para a plataforma de Android. 2017 foi também o ano da primeira KotlinConf, na qual ficou claro que as potencialidades de Kotlin vão muito para além do mundo Android.

É curioso ver o número de questões relacionadas com Kotlin a aumentar no StackOverflow, depois do anúncio feito pela Google e pelo facto de agora aparecer no TIOBE Index.

Quanto aos projetos open source no GitHub – segundo o GitHut 2.0 – num ranking de 50, Kotlin pontua da seguinte forma:

  • 16º lugar para project stars, num total de 0.480%;
  • 17º lugar para issues, com um total de 0.489%;
  • 23º lugar nos pull requests, perfazendo um total de 0.351%;
  • 19º lugar para pushes, totalizando 0.424%.

Verifica-se que o crescimento, no geral, é bastante positivo.

Interoperabilidade com Java

Kotlin destaca-se em relação a outras linguagens de programação principalmente pela sua abilidade de interoperar de forma simples com Java no runtime JVM.

Esta linguagem tem também possibilidade de compilação para Java Bytecode e adiciona praticamente zero overhead, sendo possível compilar para versões 6, 7, 8 e 9 de Java Bytecode e, ao mesmo tempo, tentar extrair vantagens das características de cada versão. Um bom exemplo do poder de Kotlin é o suporte que dá às expressões Lambda, mesmo quando compiladas para Java Bytecode 6.

Tooling

Kotlin foi desenvolvida pela empresa JetBrains, que acabou por torná-la numa linguagem first-class citizen no IntelliJ IDE, Android Studio e CLion. Inclui features como refactoring, geração de código, code completion, compilação para bytecode e sneak-peeking ao bytecode on the fly, e, até mesmo, um conversor de Java para Kotlin. Tudo ao vosso dispor.

O compilador (kotlinc) tem um modo REPL que pode ser utilizado para testar facilmente alguns snippets de Kotlin the forma interactiva.

Targets Multiplataforma

Utilizando Kotlin é possível compilar para JVM, Javascript e LLVM.

Vou reformular a frase para que percebam o meu ponto:

“Programar em Kotlin e obter o código server-side para distribuir em JBoss, partilhar código referente à camada de lógica aplicacional com a aplicação Android, e, ainda, com a webapp JS/HTML. Oh! E não vamos esquecer aquele device de IoT, vamos partilhar algum código com ele também. Como assim? Também partilhar a lógica com a aplicação iOS? Claro, porque não!”

Kotlin/ Native tiram partido de LLVM de forma a facilitar o suporte de forma nativa de um vasto número de plataformas como Windows, Linux, OSX, iOS, Android e WebAssembly.

Kotlin para JavaScript permite a transpilação de Kotlin para linguagem JavaScript, tornando possível, por exemplo, a criação de web apps de React.

Um ótimo showcase destas características é a aplicação da KotlinConf 2017, que foi inteiramente implementada com recurso a Kotlin, desde o backend, ao frontend e aplicações móveis.

Aceitar Kotlin como uma equipa

Começar a utilizar Kotlin não tem de ser uma decisão arriscada! Por natureza, Kotlin funciona incrivelmente bem com o código Java existente e é até possível ter código Kotlin e Java no mesmo projeto. Desenvolver novas características em Kotlin num projeto existente pode ser uma excelente abordagem para proceder à adoção com um risco mínimo, já que não existe a necessidade de começar tudo de novo por causa de uma nova linguagem ou tecnologia.

Utilizar Kotlin tornou-se numa realidade diária para os Android developers. A maioria dos GDEs (Google Developer Experts) defende e utiliza Kotlin diariamente e pode ser encontrada bastante informação sobre esta linguagem na documentação oficial de Android.

Para os developers fora do universo mobile, por exemplo, os backend developers, Kotlin apresenta-se, não só como uma forma de alcançar os padrões standard de atuais linguagens de programação na JVM, mas também como um substituto para a linguagem Java na sua totalidade. Projetos como o TornadoFX, Ktor, Spring, entre muitos outros, oferecem as bases necessáras para que a linguagem Kotlin possa triunfar fora do domínio mobile. E uma vez que Kotlin é praticamente 100% interoperável com Java, os programadores podem continuar a utilizar as mesmas frameworks às quais já estão habituados mas com a felicidade que a sintaxe de Kotlin oferece!

As abordagens mais comuns para a adoção de Kotlin são:

  • Reescrever os testes de unidade Java com Kotlin. Muitos concordam que esta é uma ótima abordagem para começar a mexer em Kotlin, sem colocar em risco o código que vai para produção. Kotlin oferece alguns truques que permitem tornar os unit-tests mais legíveis e compactos.
  • Quando projetar novas características, em vez de utilizar Java, recorra a Kotlin!
  • Se o projeto em que está a trabalhar se deve a um refactor, aplique Kotlin à nova versão reescrita do código base.
  • Entregue-se totalmente a Kotlin e deixe para trás os dias tristes dizendo adeus a Java!

Linguagem Kotlin

Esta linguagem, em si, é maravilhosa. Kotlin é uma linguagem fortemente tipada, e que tem como principais objetivos ser concisa e legível.

Esta tenta também resolver um dos principais objetivos no mundo Java: NullPointerException. Torna a nulabilidade parte do sistema e força os developers a pensarem explicitamente sobre os seus impactos.

Outro aspeto que torna Kotlin uma linguagem extraordinária é o facto de permitir que os autores possam transportar as melhores carateríticas de outras linguagens para Kotlin. Para nomear algumas:

  • Extension Functions
  • Destructuring declarations
  • High Order Functions
  • Type Inference
  • Functional Facilities (map, filter, flatmap, etc)
  • Custom DSLs
  • Named parameters
  • Pattern Matching
  • Operator Overload

Sintaxe de Kotlin

Aqui ficam alguns trechos de código Kotlin. Um pequeno sneak peek. Estes tentam mostrar quão simples é a linguagem Kotlin, quando comparada a Java.

Java Kotlin

// Class definition

class Person {

private String name;

private int age;

public String getName(){

return name;
}

public int getAge(){
return this.age;
}

public Person(String name, int age) {
this.name = name;
this.age = age;
}

public String greet(){
return “Hi ” + this.name + “, how are you doing?”;
}
}

// Class definition

class Person(val name:String, val age:Int) {

public fun greet():String {

return “Hi $name, how are you doing?”

}

}

// A Typical unsafe Java Singleton

public class Singleton {

private static Singleton instance = null;

private String someProperty = “SOME_SINGLETON”;

private Singleton() {

}

public static Singleton getInstance() {

if (instance == null) {

instance = new Singleton();

}

return instance;

}

public String getSomeProperty() {

return someProperty;

}

public String appendSomethingToProperty(String something) {

return someProperty + something;

}

}

// A simple Kotlin Singleton

object Singleton {

val someProperty:String = “SOME_SINGLETON”

fun appendSomethingToProperty(something:String) = someProperty + something

}

O que se segue?

Se, através deste texto, consegui influenciar-vos a testar Kotlin, aqui ficam alguns locais onde podem experimentar e que servem como apoio:

  • Kotlin koans são uma série de pequenos desafios online e são uma ótima forma de começar a explorar a superfície desta linguagem;
  • Kotlinlang.org;
  • Kotlin for Android Developers é um livro de Antonio Leiva, e é uma excelente fonte de informação tanto sobre Kotlin como sobre Android em geral;
  • Kotlin in Action é outro livro, de Dimitry Jemerov e Svetlana Isakova, muito bom para que os Java developers possam crescer na linguagem Kotlin;
  • Kotlin for Java Developers é uma webtalk de Venkat Subramanian, e é um ótimo primer para Kotlin;
  • Kotlin Puzzlers de Anton Keks é uma viagem aos aspetos não tão fáceis de Kotlin.

João Gonçalves

Mobile Consultant, Xpand IT

João GonçalvesKotlin e um futuro (ainda mais) brilhante
read more

eXperience Agile 2018: Saiba o que pode esperar deste evento totalmente dedicado a práticas Agile

O evento eXperience Agile 2018 – antigo Scrum Day – é um evento que tem como objetivo promover o debate sobre práticas Agile, bem como fomentar o networking e a partilha de insights entre profissionais da área das TI. Sob o mote Improving Through People, este ano o eXperience Agile pretende difundir a ideia de que as práticas Agile melhoram o ambiente de trabalho e ajudam as organizações a crescer através da confiança que depositam no talento dos seus colaboradores e na abertura que existe para que estes possam partilhar o seu feedback.

Ana PaneiroeXperience Agile 2018: Saiba o que pode esperar deste evento totalmente dedicado a práticas Agile
read more

Os 8 melhores livros sobre DevOps e Agile

DevOps é uma cultura. É a cultura cujo ADN é constituído pela colaboração, pela comunicação entre equipas e pela agilidade no desenvolvimento de software. É, portanto, a cultura que permite uma simbiose perfeita entre o trabalho dos Devs e o trabalho das equipas de Operações.

Ana PaneiroOs 8 melhores livros sobre DevOps e Agile
read more