Tigertech@AtlasCamp 4 NetworkedAssets

Every year more developers are coming to get involved into the Atlassian Plugin Developer community. They come to get information about the newest API changes, have the possibility to promote their plugins or ask about difficulties they have had and of course meet with other developers and Atlassians to exchange experiences. In the 8th year of AtlasCamp the community has grown from a small family of around 50 developers to 340+ developers from all over the world, Atlassians not included (also almost 50, so a total number of around 400 participants have been present). Some people are coming every year, but more than half of the participants were joining for there first ever AtlasCamp. And some have become almost more famous than Atlassians themselves. As Co-Founder Mike Cannon-Brookes put it in his welcome speech, there are more people who want a picture with Bob Swift than with himself by now.

Over the last years Europe has been settled as the place to be for the conference, because still most of the developers are coming from Europe. Prague was a great location to choose, but sadly the hotel was 7 kilometers out of town, so there was not much time to walk around the beautiful old city center of prague. But the AtlasParty on wednesday night was still a highlight, taking place directly at the waterfront of the Moldova with a great view over the beautiful charles bridge. A great atmosphere with funny talks.. and a magician or magical plugin dev from sweden doing fascinating performances, which were not including a lot of drinking but the good old string tricks 🙂

A new arrangement were the two tracks of talks this year. One track was the more technical part with insights into plugin development strategies and APIs, the other track was more general about best practices in coding. This was somehow nice, because you could choose between 2 topics in every slot, but also you were missing of course half of them and sometimes it was a hard decision. Also new were the developer breakout sessions after the main talks, in which plugin developers were intruducing into topics of their choice and from their work. These offered great insights and also a good opportunity to get into conversation with each other in small groups. The camp has become more structured and professional, for example there were almost no problems with the Wifi-connection this year and live demos were not live anymore, but all from screencasts.. which was a shame somehow, because most of the time live demos really live from the live kind of thing and the errors that can be made 🙂

Day 1 : 10.06.2015

AtlasCamp Keynote by Mike Cannon-Brookes (Co-Founder, Co-CEO at Atlassian)

After greeting the community Mike stated as the main goal for next year to unlock the potential in every team, not just dev teams.

As for the Plugins2 API he announced that there will be an official retirement by now. This doesn´t mean that the API cannot be used anymore in the future, but simply that there will be no more improvements.

The trend with Atlassian goes into the cloud solution. Today there are 26.000+ customers in the cloud, since end of 2014 more than on server instances. The benefits of this are the access to big data, the enablement of lean startups and only a single version to support. All in all there are 45.000 customers now. The marketplace has been established 3 years ago and 280.000 of all commercial licenses have been sold through the marketplace. 65 Million $ have been paid to plugin developers since and 1.800 jobs have been created in the plugin development business sector, which are more than at Atlassian itself by now.

Another big change will come with Bitbucket. Bitbucket started 2008 and 2015 there are 7M+ repositories, 3.5+ developers and 450k teams involved with it. There are already a lot of integrations. Atlassian Connect development will be new and available since today. There are new APIs, changing of webhooks, fixed setup, more data, new security issues with OAuth2. Later this year Bitbucket add-ons will be available on the marketplace as well.

The next topic were news on HipChat. HipChat has experienced a massive message growth from 1 Billion messages in 2013 to 5 Billion today. There are 70+ integrations to other services like twtter, wunderlist etc. available. Until the end of this year the Atlassian Connect Developer API for HipChat will also be available. Atlassian is introducing HipChat Cards as messages, which look better and are based on metadata. Also new will be Actions on messages, for example extensions can be written for an action to poke a reviewer or open code in bitbucket. Also there will be a new sidebar, which can be extended and new dialog views. Integrations can be made for rooms only and in the sidebar there will be an overview called Glances into the room about whats going on in the room, for example how many connected twitter messages or commits are currently present.

Atlassian Connect for Bitbucket by Tim Pettersen (Developer Advocate at Atlassian)

Tim encouraged developers to build add-ons for Bitbucket by pointing out, that the main advantage of this is, that you can build plugins for developers like youself (3.5M).

He explains that a lot of needs have to be met, that can be possible opportunities for a new plugin:

• For example deploy on playstore automatically
• Docker-integration
• Viewer directly in bitbucket
• Generate comments, build code

Atlassian converted bitbucket into a code collaboration plattform with Atlassian Connect and the following features:

• There is the traditional web integration with REST and webhooks.
• Addons can be installed directly from the bitbucket UI.
• An Iframe will run in the UI.
• Addings in the leftside menu will be possible
• Iframe with Javascript bridge, dialogs, messages in bitbucket
• API is just HTTP

Afterwards Tim introduces an example add-on, which shows the content of a repository in a neat format and explains the steps he followed building the plugin and their benefits.

• Changes in the Connect.json: descriptor key,name, description, baseurl, modules
• Include js.file from host for javascript bridge with script in head
• Make requests as the current user with OAuth connection
• Update plugin at your end without user having to do anything
• Parts that are needed: Atlassian-connect.js, AP javascript library, Add on lifecycle, JWT authentification

Bitbucket plugins will soon be in the marketplace.

Tim explains that the difference that you have in add-on development for Bitbucket in contrast to development for JIRA or confluence, is that you have different contexts for the plugin. It can be for a team or an account or a personal context.

Afterwards he mentions some statistics. Most code in Bitbucket is closed source (93%). There are much more branches than forks (96%) and much more git users (87%) than mercurial (13%). But still those are huge numbers for which it is worth developing, because 13% of 7.000.000+ repos are still 910.000. As for languages, there are around 22% using php, java 15%, but all other languages are used as well.

Tim recommends the following SaaS Dev Tools: Cloudcannon, aerobatic, codacy, rollbar, wakatime. He appeals to think of something you need as a developer, how to solve your own problems.

Devdocs & 5 minutes quick start at developer.atlassian.com/bitbucket

https://developer.atlassian.com/blog/2015/06/atlassian-connect-for-bitbucket-a-new-way-to-extend-your-workflow-in-the-cloud/

HipChat: Connecting to (allthethings) by Tanguy Crusson (Product Manager at Atlassian)

First of all Tanguy introduces the HipChat team which includes around 130 people in Sydney, San Francisco and Austin.

Afterward he explains what has been shipped in the last year: all devices support, hipchat server, integrations with jira, confluence, bitbucket, stash, twitter, googledrive, googlehangouts, wunderlist..

He states that all of this was possible because they use HipChat as a team tool as well. They have for example people join in to videoconferences from other services and a lot of other integrations. He presented how they use HipChat at Atlassian:

• confluence notifications into HipChat (for example: page created)
• jira notifications (for example: issue status change)
• bitbucket notifications (for example: pushed code, pull request merged)
• stash and github (the same)
• bamboo notifications (for example: build is broken, also possible for jenkins and other)
• room to discuss deployments
• room for tweets from users as a source of inspiration
• jira issues createable in chat
• issue mentioned in x rooms
• hot rooms to solve a bug
• botlab., to give karma to your team

Afterwards he explains about how integrations can be build for HipChat. There are different ways:

1. build-your-own-wizard:  build add-on over UI, has restrictions, no REST API, no marketplace, globally, configurable
2. token-based integration: user goes to addon site gets token and installs the add-on, no REST API, webhooks, globally, configurable
3. Hipchat addon: user installs and configures plugin, json file descriptor, json web token to authenticate hipchat, shared secret, every hour you need to refresh the token, lasts for one hour, frameworks do this for you (node.js, koa for java, python, ruby, .net)

Atlassian connect for hipchat clients is coming soon. Current problems are:

• Tendency to spam rooms, decide whats important
• See object from jira without changing context
• Trigger actions from HipChat

3 new features are coming up:

• Cards: post card to rest endpoint and it is displayed in chat, or URL to data you want to display
• Actions: put into descriptor with location and url, target view
• Glances: overview over whats going on in the room, webPanel in descriptor, panel in right side bar in iframe, proper sandboxing

Confessions of an automation addict by Holly Cummins (Software Engineer at IBM)

Holly comes as an external speaker from IBM. She states herself as as an automation addict and talks about how best to automate things. She admits that there are advantages and disadvantages in automation, but humans have always been automating things over time from the spinning weel to the washing mashine and the computer. Holly states that we automate because we are lazy and we automate for sustainability. Her principles therefore are: do a task once. do it a second time and take notes. do it a third time and automate. The more of you there are, the more it is worth investing in automation. For Holly it is important to automate something because you care about it. You care that it happens at all. You should automate to improve the outcome rather than to save effort and because you care that things get done right. But also you should automate because its fun 🙂

There are also reasons why its sometimes not a good idea to automate. For example: no time! Its not worth it to spend all the time on automation instead of the task and also a lot of time supporting and maintaining the automation. The following questions should therefore be answered: Who can maintain this automation? who can manage this automation? will it be robust? what if things change? How much will it cost? How do i define success? have i got completion creteria? It is also dumb to automate dumb things. Automation allows us to do dumb things and computers don´t always get it right.

Another advice from Holly is not to make it too complicate, because a clever automation isn´t so clever if only one person understands it.. and this person can get hit by a bus. She also likes to give hefty automations adorable names (Marvin, Rosie..).. this is sort of a personal style i guess. Typical usecases for automations are from her point of view: machine configuration, deployments, test environments, copyright statements.

Tools to use for automation: shell scripts, python, ruby, jenkins, bamboo, rational team concert builds, chef or puppet, ant, maven, gradle, eclipse plugins, web applications with caution.

Ratchet up your CI by Ian Grunert (Senior Developer at Atlassian)

First of all Ian pointed out that static analysis in the continuous integration process is criminally underused. As tools for this he recommends jshint, checkstyle, eslint, pylint.

Introducing static analysis is hard, because you get a lot of warnings and it feels like your team is working against you. It is possible to use page weight by plugin graph to see which problems are most important. As problematic Ian claims that regressions get lost in the error bars and performance baselining is too manual. Therefore he recommends Git-ratchet. It is a tool to ratchet measures. You can use the tool to see if a measure changes. There is no need for a storage server. The data goes with your code in git-notes and gives you the ability to add information to commits. An extra branch is used in /refs/notes/git-ratchet for notes. Like that you will have a full history of data over time. So if someone ignores warnings, because he thinks he knows what he´s doing, you still have the information in the repository about this quick hotfix.

Go to gitratchet.org to get the source for your builds.

The age of orchestration – from docker basics to cluster management by Nicola Paolucci (Developer Advocate at Atlassian)

To start Nicola lost some words about docker engines in general and how they differ from a whole virtual machine on which apps are running. Docker has its own format, interfaces to talk to other applications, a step by step built cache, where every command is cached and a registry, where you can push and share your docker machines. At Atlassian they use docker for dockerized bamboo agents and docker tasks.

The current version of Bamboo 5.9 has the following features:

• dynamic port mapping
• mounting of multiple volumes
• setting of the working directory
• adding of additional arguments

In the docker registry an official image for Stash is available. Download it to try out Stash on docker. Nicola is working hard on the subject to make other products of Atlassian follow this example. He encourages us to repeat this wish to Atlassian to make it happen earlier 🙂

He explains that at Atlassian their internal PaaS (Plattform as a service) uses 8 microservices in docker containers. There have been 6 million containers spun per month and they can scale the tasks using containers easily.

Afterwards Nicola talks about the orchestration of multiple docker containers. The level of complexity is high with this many containers. Her recommends the following orchestration frameworks: kubernetes by google and mesos from apache (master handling slaves), which are robust solutions. But you can also use dockers own orchestration. With docker compose you can link containers and put everything together in a configfile. With docker swarm you can run them on a cluster of hosts.

To show how this works Nicola presents two demonstrations. In the first demo he provisions one machine on a PaaS and pulls postgresql and stash from the registry. To delete a machine you can use docker-machine rm <nameofmachine> and its gone from digital ocean. With docker swarm a swarm master is set with swarm nodes and in this nodes are one or many containers. In the second demo he shows an orchestration with 3 machines. He provisions a docker swarm on 3 hosts and uses labels to deploy to the nodes. Starting up works with docker run swarm create. The first machine is created with docker-machine create –d digitalocean –digitalocean-access-token with the label java, and the name atlas-camp-1. The second one is created with the label database for postgresql and contains the database. The third machine is the master.  When you are using the swarm command you make sure that all commands are executed on all machines. Nicola recommands to install postgresql on one container and stash or all java apps on the other.

https://developer.atlassian.com/blog/2015/06/deploy-java-swarm-with-docker-machine/

http://de.slideshare.net/durdn/power-routines-of-experienced-git-users

Day 2: 11.06.15

Plugins 2: All Grown Up by James Winters and Alex Courtis (Senior Team Lead and Senior SaaS Developer at Atlassian)

Even though Mike has told us in his keynote, that the Plugin2-API will not be improved any further in the future, there have been a lot of things happening over the last months. Alex and James told us how they updated allthethings:

• Java 8 support
• Spring 2.5>4.1
• HttpClient 3.x > 4.4
• Bndlib 1.43 > 2.4
• Guava 11.02 > 18.0
• Spring DM 2.x >  Apache Gemini Blueprint 2.0
• Velocity 1.5, 1.6 > 1.6, 1.7
• Closure Templates (aka Soy) 2011-12-22 > 2014-

They now have a Plugin Lifecycle that really works: stopping a plugin is painlessly possible now. Also there is a better OSGi resolution. When disabling a consumer it will also disable the mandatory OSGi packages. If you choose this to be optional it will be reloaded. They announced that Atlassian-trusted-apps are offiicilly deprecated now, Atlassian Connect and OAuth 2LO should be used instead.

The new stuff works for new applications only, as for:

• Jira 7.0
• Confluence 5.9
• Stash 4.0

After this introduction, James and Alex were handing out tips and tricks for the new features:

• Servlet 3.0 is a dynamic servlet. For example ServiceDesk is using it to listen to license changes.
• all Atlassian-plugin.xml fragments willl be combined in one file. This announcement was followed by a lot of applause from the audience 🙂
• Be careful that Plugins2 will only be compatible with Maven 3.2. and 3.3! It is also included in the SDK.
• AMPS supports real databases, which means you can now test plugins with maven against a real database with maven profiles and you can customize the import with testdata etc.
• The upgrade to Bndlib 2.4 will be painful, if you are not using Semver.
• In maven pom you should put the versions to major, minor, micro, qualifier and use all of them.
• There is a new license API with multi product license support with the LicenseHandler interface.
• As a hint they warned to set *;resolution:=optional, because you will import all the packages in the world like that.
• To make sure that you are compatible with Guave, test it with both versions Guava 11 to 18 and try to be compatible with both.
• Also update your toolings to maven 3.3 and java 8.
• And last but not least, keep your plugin close to Bare, Bones and OSGi.

Confluence Addon Design Patterns by Sherif Mansour (Product Guy at Atlassian)

Sherif was talking about best practices in building a macro in confluence. A macro is the most common plugin-module to build in confluence. He compares it to a standard 2×2 legoblock, with which you can build anything.

He points out that 20% of the work in confluence is market specific and 80% is general collaboration and recommends to be more market specific in building a macro. Then he talks about the custom macro dialog and that it is better for some macros than the standard one and should be considered in development. As an example he shows the new jira-issues-macro. As another hint he recommends to use a rendered image placeholder, which renders an image for the macro to show the user what it does in edit mode. Also the property panel can be used for common actions in edit mode, to make quick changes inside of the panel.

Next he talks about Page and Space Blueprints. To give your macro a usecase and a context in which it can be used it can be put into a page blueprint. Page Blueprints show the user what he can do in confluence, guide him with wizards, and structure the content with index pages. More information on page blueprint templates can be found in his talk here: http://bit.ly/PageBlueprints. Index pages group all content of a particular type. You can make content reports by label and put a shortcut on the space sidebar. With the Space Blueprint wizard you can get precreated shortcut links, links to an agile board, to jira reports and you can pre-create page hierarchies. You can also  recommend only a specific type of content for a space, by delivering just specific page blueprints in a space.

As an example Sherif presents a linkedin macro, which shows the profile of a person for HR recruitment. To prepare that for the user he creates a HR Recruitment Space, with an integration of the internal HR system, creates shortcuts to the HR system, has specific blueprints for interviews and reports, adds automatic page restrictions to interviewers, includes the new linkedin macro, interviewer infos and a progress macro.

Slides from talk: https://speakerdeck.com/sherif/atlascamp-2015-what-confluence-add-on-developers-can-learn-from-lego

Get your addon in shape for Data Center by Michael Heemskerk (Architect for Stash at Atlassian)

Michael talks about the challenges that you face in preparing your plugin for datacenter. As the main challenges he states:

1. caches
2. synchronization
3. events
4. scheduling

1. Caching:

As a rule of thump Michael recommends to avoid them if you can. They are evil and will be the biggest issue, if you get weard behaviour. The atlassian-cache allows you to do cluster safe caches. Elements of the API are:

• CacheFactory
• Cache <K,V>
• CachedReference <V>
• CacheLoader<K,V>
• CacheSettings
• CacheListener

There are local caches and remote caches, which replicate to all nodes to have them in synch. And also there are hybrid caches, which is a mix, where all caches are local and each will have its own content, but sends an invalidation notification to the other nodes if the content changes, so their content gets marked as invalid.

2. Synchronistion:

The same rule of thump applies to avoid it if you can. There is an optimistic locking implemented in the database, the atlassian-beehive, which is a cluster-aware lock service (ClusterLock, ClusterLockService) and works well in most cases.

3. Event-handling:

Events are created by all applications, but only triggered on the node where the event is processed and sometimes it matters that the other nodes don´t know about the event. Events are therefore node-local only. As options for node-to-node coordination the atlassian-cache (+listener) can be used or product-specific APIs.

4. Scheduling:

For scheduling use the SchedulerService as an entrypoint, configure your jobs in the jobconfigfile and then run the jobrunner.

There are also product-specific APIs for datacenter instances:

• for JIRA: ClusterMessagingService
• Confluence: ClusterEvent
• Stash: TopicService, BucketedExecutor

Using Add-ons to build Add-ons by Daniel Wester (Co-Founder at Wittified)

Daniel Wester from Wittified talked about their great plugin, which they built to have a tool to make plugin development easier. Wittified has currently 17 Add-ons on the marketplace. Every friday they use their 20% product time for innovations and came up with the Web Fragment Finder, which enables the developer to add Web Items to a webpage in an easy way.

You can use it to build a P2 Add-on as well as a Connect Add-on. There is an event inspector to find events, without checking all the documentation. The active object inspector lets you see the jar configuration and the table data. If you click on add web item, you get the actual code for creating web items. You can identify Web Items/Panels/Sections/Recources.

For Atlassian Connect the problem is that it changes every couple of weeks. With one click in the fragment finder you can install atlassian connect and get all the stuff for it. For web items you get a json blob. In managed app mode you can add a path to the configfile so you dont have to switch to the commandline anymore. You can add web panels without touching code, there is a wizard to add information and it automatically updates the descriptor. With the property inspector you can handle Issue properties (properties saved on an issue). You can also add an inline dialogue with a wizard, which is awesome for rapid prototyping.

Web technologies you should be using now by Dallas Tester (Developer evangelist at Atlassian)

Dallas Tester (yes, this is his real name ) introduced new web technologies that are worth using in plugin development. For example are web components good for sharing code between p2 and connect, but no html-imports because they will not be supported. As for custom elements he reminds to consider that all content comes from the id and the context from the name of the element itself. He recommends to bedazzle your elements, by adding a prototype, defineProperty, renderWebitems and registering them. The lifecycle of an element includes the following callbacks: createdCallback, attachedCallback (render all webitems), detachedCallback (shorttime), attributeChangedCallback. Also new is that Html templates can be defined inside templates as well and will render together.

Another hint is to use Shadow Doms, which create boundaries for css-styles and other elements and restrict them to certain web-panels.

In EcmaScript 6/2015 the following new things are defined:

• extensions to JavaScript, bable, transcure
• use of classes, subclasses with extend, constructor with super
• modules: to define dependencies within code, AMD and JS no browsersupport until now, have to use bubble or something
• promises: go away from callback hell, have that later, something is going to happen, pending > fulfilled or rejected, no retrying, needs another promise, supported by all browsers

Back to the future with web components by Jonathon Creenaune (Dev Manager at Atlassian)

Jonathan is the Dev Manager at Atlassian on AUI and ADG and intruduces news about web-components. He explains how AUI is used in web-components. Sourcecode of examples can be found in his Bitbucket account: bitbucket.org/jcreenaune

He talks about what you can depend on in CSS, because some parts are API and some are not. Therefore its always recommended to design the interface first, use web standards, make your app interface driven and insure backwards compatibility. There are frameworks which do that for you, like Backbone (Jira, Confluence, Stash), Angular and React. When you have web-components in your browser, than you dont need views.

Finishing up about web-components Jonathan states that they are ready to use, solve a bunch of problems and are coming up to you anyway.

Game of codes: the CI battle by Esther Asenjo (Bamboo Developer at Atlassian)

Esther of the Bamboo development team talked about battling with continous integration at Atlassian. The Build Infrastructure at Atlassian contains 11 bamboo instances. For the development of confluence there are 100 devs, 420 commit/day, 435 build plans, 20.000 tests. The big challanges in this are to get a green production-ready master, while having long running branches, big & slow test suites and you need a build strategy for quick feedback. Also there is user acceptance testing (Dog fooding), Monolithic Applications, plugin development (cross-compatibility pipelines) and cloud integration (cloud delivery pipeline).

Esther states that CI is a practice not a tool. The culture of green can be questioned though and she suggests that red is the new green, because if you get the errors you will not put these issues into production. She recommends to give as much feedback to the people as possible, with dashboards everywhere. You should free people to do the interesting stuff and let bamboo do the rest.