Posts by Steve Smith

Note: This is a repost of our previous announcement. However if you don't have it already, the Bitbucket NPM add-on is now available in the Atlassian Marketplace.

(Update: The NPM add-on is now available in the Atlassian Marketplace. See the updated version of this post for more details.)

core.async is powerful but can be long-winded. Macros are terse but hard to test. Metadata is informative but not well known. Let's see if we can combine all three to make something elegant.

Back in part 4 of this series we introduced two methods of accessing Bitbucket from our Atlassian Connect add-on, including via the client-side (browser) JavaScript API. However as we've written all of our server-side code in Clojure so far, it's a shame to have switch to another language. In this installment we'll take a look at ClojureScript and how we can integrate it into our project.

In part 4 of this series we added the Bitbucket UI to our add-on. Although there's more tweaks we'll do in later installments, for now we have enough to do an initial test against Bitbucket. In this post we'll show how to do this running from our development machine, and how to build and run a standalone deployment image of our add-on.

In case you missed it, last year we launched our Bitbucket Docker Hub integration as part of the Docker Hub 2.0 launch. We are now pleased to announce the next version of this add-on is now available. If you already have it installed you'll get it automatically. If you haven't already installed it see below for instructions on adding it to your account. Carry on reading for more information on this release.

In part 3 of this series we added REST and JSON capabilities to our add-on. However most Atlassian Connect add-ons will want to add some user-interface elements to the Bitbucket repository too, usually by working with data from the repository. To get this data, the add-on will need to talk to Bitbucket directly. In this installment, we'll look at a couple of ways to do this, including how to authenticate using the handshake information we received in the previous blog post.

In part 2 of this series we built upon the foundations we created in part 1 to generate a Connect descriptor. That descriptor specifies, among other things, the API that Bitbucket should call on key events in our repository and add-on lifecycle. In this installment we're going to look at how to specify and serve this API, and how to convert JSON sent to us by Bitbucket into Clojure data-structures.

In part 1 of this series we did the fundamental work of building a Twelve Factor HTTP-stack from the ground using Leiningen, Ring, Compojure, and Immutant. However, that was just the foundations, and now we're ready to start adding the necessary tooling to produce a full Atlassian Connect for Bitbucket application. This will include templating and introduce how to specify and authenticate our Connect add-on via its descriptor.

One the most exciting things about the Atlassian Connect add-on framework, for me at least, is that it removes the need to create add-ons in the language of the hosting application. With the recent release of Bitbucket support for Connect we now have the ability to not-only extend Bitbucket in any way we see fit, but to also do it in whatever language or framework we desire. This opens us up to developing for Atlassian products in Haskell, Scala, Node.js, or anything else that supports the basic protocols of the web.

In case you missed it, last month we launched our Bitbucket Docker Hub integration as part of the Docker Hub 2.0 launch. We are now pleased to announce the next version of this add-on is now available. If you already have it installed you'll get it automatically. If you haven't already installed it see below for instructions on adding it to your account. Carry on reading for more information on this release.

As part of the Docker Hub 2.0 launch we're pleased to announce integration of Docker Hub into Atlassian Bitbucket. This brings your Docker workflow together with Bitbucket to save you time and allow you to see source code stats along side your Docker repo in one place.

This June I had the pleasure of presenting a talk on continuous deployment at Devoxx UK. The video for this talk is now online. As the information in this talk may be of use to some people a full transcription of the talk and questions is below...

Bamboo provides the powerful ability to dynamically scale your build farm by launching swarms of build agents on Amazon's infrastructure. These AWS images are fully customisable, but the process is a bit involved. This post introduces a simpler method of doing this using Packer and Ansible. Read on for the details (and a ready-to-use example repository) ...

As Linus Torvalds has already pointed out, the 8th of July 2015 is the 10-year anniversary of Junio C. Hamano taking on maintenance of Git. And here at Atlassian we appreciate the excellent work he's done over that time.

The usual rumour mills are all fired up over the possibility of new Nexus 5 & 6 editions appearing this year, mostly over who would be making them. Most of the justifications given for a new Nexus 5 in particular seems to focus on either the new Android M hardware features such as fingerprint recognition and ARMv8. However, there is one hardware feature that I haven't seen discussed anywhere, and it's the one reason why I feel Google absolutely must release a new Nexus 5 model this year. That reason is simply Project Fi.

Git's push --force is destructive because it unconditionally overwrites the remote repository with whatever you have locally, possibly overwriting any changes that a team member has pushed in the meantime. However there is a better way; the option --force-with-lease can help when you do need to do a forced push but still ensure you don't overwrite other's work.

As I've mentioned before, I'm gradually working towards my grey-beard badge so for most of my programming I tend to use Emacs. However when I moved into the order-systems team I adopted IntelliJ IDEA, which is our weapon of choice for Java development at Atlassian. This is because while Emacs is a great text editor, IntelliJ takes a holistic and semantic view of your project, something that is necessary with Java's verbosity and file-based classes. In particular, its on-the-fly tracking of the project syntax tree enables complex refactoring and clean-ups, either automated or by the more brute method of just changing something and seeing what turns red in the editor.

One of the features of systemd is its ability to defer the start-up of networked applications until their services are actually requested, a process referred to as socket activation. This isn't really a new an idea; systemd borrowed the idea from launchd which has been in OS X since Tiger's release in 2005, and the venerable Unix inetd has implemented a simpler version of it since the 1980s. Socket activation has a number of advantages over scripted or event-based start-up systems; in particular it decouples the application start-up order from the service description, and can even resolve circular application dependencies. Docker containers (and other types such as systemd's nspawn or LXC) are almost exclusively network processes, so it would be useful to extend socket activation to them.

The following is a repost of an article from my personal blog that describes how to perform event-driven updates from a PostgreSQL instance to Elasticsearch. In February I will be giving a tutorial at DeveloperWeek on development and testing with Docker, and this relies heavily on the code described in this post as an example project. So for consistency I am reproducing the post here. The final version of the code that will be used in the presentation is also available; I recommend downloading it if you are attending the sesssion.

Back in December I did a webinar on some of the advantages of using git with your Bamboo pipeline, leveraging some of the Bamboo and Stash integrations to create a feed-back loop of quality control. The transcript for this webinar is now available below the fold...