Creating Builders in Kotlin– The Results of the Kotlin Workshop

Leave a reply

At the beginning of May, I held a Kotlin workshop at Skills Matter in London. The attendees had to go through a series of exercises to get familiar with Kotlin’s language constructs and then do two larger exercises.

image

Seeing that one of Kotlin’s benefits is the ability to design nice DSL’s, I proposed that they write a JSON Builder and a Build System (i.e. the next Ant, MSBuild, Rake,…take your pick).

We divided up into groups of three people per team and each went off their own way to design their own DSL’s.

Most managed to finish both exercises, or at least finish one and start the second. We were meant to vote on the winning DSL and they’d then get a prize (namely each member of the team would get to choose a license of one of our IDE’s). Unfortunately, 30 minutes prior to ending the class, some had to leave and then I mistakenly mentioned that Beers were happening in the Slaughtered Lamb and all hell broke lose. Moral of the story: we didn’t vote.

But I’m going to keep my word. I’ve managed to collect the outcome of the different teams (or what they managed to complete). I’ve presented them below (anonymously) and leave you all to vote for which one you like the best. The winning team will then receive their prize.

Exercise JSON Builder: Create a DSL to express JSON in Kotlin and output the result to actual JSON.

Exercise BUILD Builder: Create a DSL to define Build Scripts in Kotlin

(Teams are randomly ordered and might not have resemblance with actual seating during the workshop)

Team 1 – Finished the JSON Builder

image

Team 2 – Finished the BUILD System

image

Team 3 – Finished the JSON Builder and the BUILD System

image

image

Team 4 – Finished the JSON Builder and the Build System

image

image

 

Team 5 – Have not received any entries unfortunately.

 

Voting

Realizing that some participants have submitted both, others only one, and a couple none, just vote for whatever you like the most, be it the JSON Builder or Build system.

Voting will end Thursday 6th of June at 12 pm CET.

UPDATE: VOTING NOW CLOSED

Results are in:

Winning Team, with 44% of the votes is Team 3. Close in second with 39% of the votes is Team 1.

Congrats to Team 3. Your licenses will be on the way (contact me if you’re one of the team members).

 

Thank you

I’d like to extend a thank you to all the participants for having taken part and a big shout out to Skills Matters for facilitating this workshop. You’re doing great things for the community.

Android applications with Kotlin

12 Replies

Did you know you can write applications for Android using Kotlin instead of Java? Here’s how, in one minute!

Converting to Kotlin

IntelliJ offers a series of features targeted at Android development, among these is the ability to quickly create Android Components:

NewMenu

For instance, selecting to create a new Activity will generate the corresponding XML layout, source file and update and the application manifest. Quite useful. The problem is though that the source generated is in Java, which isn’t an issue of course unless you’re working with Kotlin. However, you can easily work around this. Simply use IntelliJ’s helper to create the necessary components, then select the generated Java file in the Project window and from the Code menu click on Convert Java File to Kotlin File (there’s a different shortcut depending on your keyboard layout).

CodeMenu

All this functionality is available in both IntelliJ Ultimate as well as the free OSS IntelliJ Community Edition, the same one Android Studio is built on.

Freedom to work

5 Replies

Yahoo has called in all their remote workers. Come June, they’re either sitting at desk in Silicon Valley or they’re looking for another job.

I’d be looking for another job. Not because of having to go the office everyday, but because they’re trying to solve the wrong problem. It seems like they feel if people are bound to a schedule, working in an environment where they can be controlled, everything will sort itself out.

Were I work, people set their own schedules. Whether they’re working from home or in an office. There are no office hours, no controls, no micromanagement. And yet it works. It works because of two main cultural values: respect and care.

Respecting the individual. Caring for the individual

Respect is not limited to treating people politely. It is respecting them as individuals, it is understanding that each person is different, works in different ways, has different challenges or circumstances that need to be dealt with. However, it is more than just acknowledging it, it is doing something about it. It is caring enough to want help.

Applying these values in a work environment between employer/employee, between team members is what makes the difference. And it makes a very important difference.

An employee needing flexible hours can either be faced by an employer who makes excuses about why it won’t work out or someone that is willing to help accomodate the employee. Helping this person out shows them that their employer cares enough about them as an individual. And if there is respect, this behaviour then becomes reciprocal.

These values needs to be applied to all aspects: between colleagues, teams, an individual’s work, the collective work, the project and on a more global scale, the goals of the company.

The culture of mistrust.

It is the feeling of respect and caring for each other, and the things we do that builds up and creates a relationship of trust.

Mistrust on the other hand emerges  as soon as you ask someone to clock in/out. When you ask them for detailed daily reports, you’re saying that you’re not sure if they’ve actually been working all day.  When you micromanage, you’re telling them, that not only do you not trust them, but you don’t respect them enough to be more than an insignificant cog in the machinery.

This creates tension. It leads to parties disrespecting each other. And as this happens, people stop caring. Why care about something you don’t respect? As a result, efficiency drops. Employers lose. Teams lose. The company loses. The individual loses.

It becomes another 9 to 5 job for a pay check.

Perks don’t buy respect 

A spokesperson for Yahoo writes:

[Marissa] Mayer is happy to give Yahoo employees standard Silicon Valley benefits like free food and free smartphones…”

Free donuts, constant flow of coffee and sodas are great. But if there is no respect, it means very little. Perks alone don’t buy respect or fulfil individuals. They are the icing on the cake. But there needs to be a cake.

Taking freedom away from people by forcing them into a 9 to 5 schedule on-site and then saying you’ll give them a mobile phone is not going to solve anything.

Care for people. Respect them. Give them the freedom to work. They’ll give you their best.

Automatically Building Pull Requests from GitHub with TeamCity

16 Replies

Scenario

You’re running an OSS project* and someone makes a pull request. You’ve got two choices:

  • Merge and Pray
  • Pull to local branch, build, run tests and merge if all OK

What do you do? Well, what is it going to be?

Dealing with Pull Request

I know what I’d like to do, and GitHub makes it so so tempting:

Merge Pull Request

But unfortunately I go with the second option.

That’s a pain, specially if you do a quick code-review and things look decent. Yet you still need to make sure that it builds and all tests pass.

Well, luckily for me, and my ability to continuously interfere in conversations, I found out that there is a better way. And what’s even nicer, is that it’s also possible with TeamCity.

*This applies to non-OSS too

Automatically Building All Pull Requests

What I want to do is have TeamCity automatically build all Pull Requests for me of my main repository, and notify me if it is successful. And I want this to happen without me having to configure every single fork as a repository in TeamCity, because like that, it wouldn’t be manageable. Here’s a diagram explaining it:

TC Flow Diagram

This will drastically improve the workflow since we no longer have to manually create a local branch of the pull request, check it, build it and only then merge it.

Configuring TeamCity

Setting up TeamCity to do this is really simple. It actually only requires one thing: configuring the Branch Specification under the VCS root:

TC Git Config

Let’s see what this means and why it works. When a pull request is made, GitHub automatically creates a reference that holds the pull request as well as one that is a merge with the master branch. What we’re saying to TeamCity is to monitor this branch, in addition to the main branch. In this syntax, pull refers to the pull request. The * refers to ANY pull request, and the merge indicates that we’re interested in the pull request merged with the master branch. This means that when TeamCity builds, it will build the branch that was merged. If we want to build the branch, without merging, we could use the following:

+:refs/pull/*/head

So to recap, adding merge builds the result of the merge, and adding head, just the pull request without the merge.

The result of these builds show up in TeamCity like so:

TC Result 1

where the number denotes the pull request. Now, we can actually make this a bit nicer by allowing us to see whether the particular request was the result of a merge or just the branch itself. For that, we can specify the following in the Branch Specification

TC Alt Config

with TeamCity now indicating whether this was a merge or head:

TC Result 2

In addition, TeamCity also provides us with a Dropdown, where we can filter all the different pull requests:

Filter

Seeing notifications on the Pull Request

As this is a normal build, like any other build, we can configure TeamCity to receive notifications via email, tray icon, etc, both on successful builds as well as failed builds. However, there is one other thing that we can do: see the result of the build on the Pull Request page on GitHub. In order for this to happen, we do need to install a plugin for TeamCity which currently doesn’t ship out of the box. This plugin, written by Eugene Petrenko uses some hooks GitHub provides to add notification information on the Pull Request page.

To install it, download the plugin as a zip file and place it in the plugins folder of the server and restart the server.

Once that’s installed, we can now display build status information on the GitHub pull request by adding a Build Feature to our Build Steps:

Build Feature

and filling in some simple configuration parameters:

image

And with that, we can see the status on the Pull Request page on GitHub.

image

* If you’re running your OSS project on TeamCity at CodeBetter, you now have this plugin available.

Summary

Although my example was based on TeamCity 8.0 which is currently in EAP, this feature also works with TeamCity 7.1.3+ (and even previously covered by others). The examples are also based on OSS projects, but you can apply the same workflow to private repositories also, hopefully making things a little bit easier.

Extension Function Literals in Kotlin or How to enforce restrictions in your DSL

Leave a reply

Take a look at the following code, an example of a specification written using spek

In this code, given, on and it are all functions.

Kotlin allows top-level functions to be defined (without the need for them to belong to a class). As such, we could merely declare these functions in a single file as below:

At first sight it might not seem like a bad approach, but it is. The problem is that you cannot prevent someone from calling the code like so:

or even:

or any other weird combination for that matter.

This means that we would now have to put in additional runtime checks to verify that things are called in the correct manner; context has been set up before the action, the action has been executed before the assertions and so on and so forth. Pain.

Extension Function Literals

We’ve already seen that Kotin has extension functions, similar to C#. We’ve also seen that we can define extension functions as function literals:

Combining this with high-order functions, that is a function that takes a function as a parameter, we can do:

given is still a top-level function. However, the diference is that on and it are no longer top-level. Instead, we’re creating three different classes: Given, On and It.

Let’s take a look at the Given class. This class has a method that takes two parameters: a string, which is the description and a second parameter which is the extension function literal we’ve been talking about:

The parameter is an extension function on the On class, which takes no parameters and returns no value (Unit in Kotlin – void).

We repeat the same pattern with the On and It classes. By doing this, we now enforce a certain flow at compile time and prohibit out of order usage.

You can see also in the code, that the It class contains a series of assertion methods, exactly where they belong.

Summary

We can see that with some simple extension function literals, we can easily impose a series of restrictions on our DSL’s. Of course, in this case, the example is quite straightforward but the same thing can be applied to designing other DSL’s such as HTML builders et al.

[Thanks to @orangy for highlighting the issue and refactoring of Spek to this]

Making +1 mean what it really means

2 Replies

On YouTrack, you can vote for issues. There’s a button right at the top, beneath the title. It’s quite big. It doesn’t say “Vote” but it’s still pretty apparent

Vote Button

The problem is, that not everybody seems to see the button. In addition, in a world of Like and +1, what tends to happen is that we end up with a lot of comments like this:

NewImage

So how should we fix it? Make the vote button bigger? Place a couple here and there? I asked this question on Twitter a few days ago and one of the more common responses was:

“Can’t you add a feature to YouTrack to make +1 add a vote?”

Workflows save the day…again

Well, good news is that we can. But the even better news is that we don’t need to add a feature, and consequently you don’t need to wait for us to ship this feature if you’re also encountering this problem. We can actually solve this using Workflows. If you’re not familiar with workflows, think of it as a way to get YouTrack to pretty much do whatever you want.

The workflow is actually quite simple:

Workflow

With a simple rule like the above, attached as workflow to your project, any +1 comment will now be interpreted as a vote and a nice message displayed to the user.

Message on Vote

Just write the workflow, upload it to the server and attach it.

Shipping out of the box

As of YouTrack 4.2, this workflow will already ship out of the box. Until then, and using your current version of YouTrack, you can create the workflow, attach it and you’re good to go.