Artifactory User Plugins in 5 Screenshots or Less

Actually, less (only 4).

Remember the blog post about user plugins? How easy and fast is it to add or change functionality in Artifactory? When you went skeptic, like "come on, it's nice in the blog post, but how useful it really is?" Here's real live example from today:

This morning (~09:30 AM in Netanya, Israel) I found new search results for "#artifactory" term in Twitter:

Isn't it a perfect use case for a user plugin? It is! Developer Advocate power to the rescue, and 3 hours later (inc. coffee, meetings, etc.) it's done:

The user plugins are open source, hosted on GitHub, waiting for you to fork them. This one took 20 lines of code:

Sascha saw it on her morning (07:00 AM, she starts early!), ready to rock:

Mission accomplished.

So, here we go, brand new and useful Artifactory feature, delivered to the user in less than 9 hours.
I told you, user plugins rock.

Beat the binary repository developer (a.k.a. User Plugins)

From our experience with thousands of Artifactory users we know one thing for sure: we don't know better. Every organization does its ALM differently: artifact approval flow, snapshot retention policies, build-to-release flow, governance, needed metadata and much, much more - they are all different. We definitely have some ideas on how the build and deploy process should look, but there are so many things that make your process unique. And that's good. After all, you aren't paid for working within the ideal deployment cycle, but for solving a business problem. At least I hope so.

Acknowledging the fact that we don't know better complicates our lives as creators of a binary repository... and not only by hurting our ego. We want to give you the perfect tool for the job, but how can we do it without dictating to you what your job is? The solution is well known - extensions, a.k.a. add-ons, user plugins, you name it.

"OMG!", you might say. "Code! Joy-joy! Finally, an excuse to hack around!" Or "OMG! Code! It's your job to code those things into your product, not mine!" Look, either way, we don't have much choice, do we? When it comes to customizations, you have to tell Artifactory what you want it to do. We can only try to do our best to make it simple for you. So, we developed a simple DSL.

In this post, I'll show you how easy it is to customize Artifactory with user plugins. Here's the story: you want to prevent downloading of deprecated artifacts. The deprecation information is attached as custom metadata to the artifacts by some quality-assurance mechanism.

Let's say, for example, the artifacts to be banned from download are marked with property "deprecated=true". Artifactory allows you react (with code) to various events in the system. You can find the list of available callbacks in the User Plugins documentation. So, we are going to write Download plugin and the callback we are looking for is the altResponse. In this callback, we can provide an alternative response instead of the one Artifactory was asked for. Here's the code:

 1 download {
 2     altResponse { request, responseRepoPath ->
 3         def deprecated = repositories.getProperties(responseRepoPath)

.getFirst('deprecated')

 4         if (deprecated && deprecated.toBoolean()) {
 5             status = 403
 6             message = 'This artifact was deprecated, please use some 

alternative.'
 7             log.warn "Request was made for deprecated artifact: 

$responseRepoPath.";
 8         }
 9     }
10 }

10 lines of code. That’s all. Let's examine them:

• It's Groovy! If you are into it, good for you, enjoy! If you aren't, don't worry. It's amost like Java, so you'll read it without problems and will be productive from day 0.
• It's super-simple. 

Here we go, line by line:

1. Declares that it's a Download plugin.
2. Defines the callback type we want (altResponse). When we are implementing alternative response Artifactory provides us with 2 objects:
• The request, instance of org.artifactory.request.Request. It encapsulates the information about incoming request, such as client details and the information requested
• And responseRepoPath, instance of org.artifactory.repo.RepoPath. It encapsulates the information about the artifact to be returned.
3. We want to get the first value of 'deprecated' property, if defined on the artifact represented by responseRepoPath.
4. If the value exists and it is 'true', 1 or 'y' (as declared by toBoolean()) ...
5. set return code to 403 (Forbidden) and
6. set the correct error message and
7. - optionally - issue warning to the Artifactory log.

Well, that's all. Now, when you saw that the dragon of user plugins isn't so scary, just think about the unique ways you could automate your delivery cycle, apply regulations and checks, or provide your corporate users with better Artifactory experience. Here are some samples and community contributed plugins to ignite your imagination.

Enjoy your build!

JavaOne - Next year in Vegas?

OK, my adrenaline is back to normal, and it's time for a wrap-up about JavaOne.

As the Main Event in which we participate every year, this year’s JavaOne was big for JFrog. Judge for
yourself: at JavaOne 2009 we introduced the Pro and SaaS versions of Artifactory Binaries Repository Manager at JavaOne. At JavaOne 2011 we were honored to get the Java Community hug and get the the Duke’s Choice Award, and this year we created the amazing Continuous Delivery DemoZONE.

But, let's start chronologically. In the beginning God created the heaven and the earth. Fast forward.

On September 30, one day before JavaOne 2012, the Jenkins User Conference San Francisco  took place at the Hyatt Regency Hotel. There were two tracks packed with CI talks from the industry’s leading experts and speakers and a great keynote address by Mr. Jenkins himself, Kohsuke Kawaguchi. Gareth Bowles and Brian Moyles gave unique sneak peak into highly loaded Netflix build and deployment infrastructure (built on Jenkins and Artifactory). I delivered a talk about the advanced aspects of writing user plugins (actually, a sequel to Noam's talk at Israeli Jenkins User Conference) and a short lightning talk to showcase the advantages of Artifactory (repo.jenkins-ci.org is an Artifactory instance on the cloud) to Jenkins plugins developers. Good networking and an engaged audience hosted by friends. Sounds like a great event, and it was.

But that was only a warm-up before the real thing - the Continuous Delivery DemoZONE. Yes, together
with Gradleware and CloudBees we’ve  offered our own DemoZONE right in the middle of the Exhibition Hall of JavaOne, and it was big! A picture worth a thousand words. But I'll add some words anyhow. The JFrog team, Mark Prichard of CloudBees, Hans Dockter and Peter Niederwieser of Gradleware - together and in separate showcases - demoed and ignited the audience about the greatest continuous delivery stack developers ever had. Sure thing, Artifactory, Gradle and Jenkins-CI are killer tools on their own merit, but when they come together they are unstoppable! That the Continuous Delivery DemoZONE was the most crowded booth at the Exhibition Hall proves it well.


As every year, we had the best tee around. Keeping the movie parody theme, we rocked with the Frogfather t-shirt, reminding everybody that Artifactory is an offer you can't refuse! More than thousand tees vanished in a storm. Looks like we'll have to print even more next year.

Fred Simon our Chief Architect rocked on stage with "How we took our server-side application to the Cloud and liked what we got", the story of Artifactory going to the cloud (from the technical point of view - classloaders and stuff).

Not that we had time to attend any sessions...welI, actually, we managed to sneak into some. So, first of all - James Gosling on stage throwing t-shirts. What a great nostalgic sight and what a smart move by Oracle! Thank you, guys. All you need to do to bring back the glory days is get us out of the hotel maze. If it takes moving the OpenWorld+JavaOne to Vegas - count me in!

John Ferguson Smart gave a great session "Real-World Strategies for Continuous Delivery with Maven and Jenkins" (and blogged about it at java.net), all about the good stuff in CD (including Artifactory). Our friends from CloudBees kicked with Java PaaS: The Engine for Delivering Enterprise and Mobile Applications. As usual, I enjoyed the official RockStars Guillaume Laforge and Dierk König talking about Groovy, Graeme Rocher on Grails, Kevin Nilson on HTML 5, Chris Beams and Arun Gupta discussing if (and how) Java EE and SpringSource can live together. The unstoppable Steven Chin gave 8 (eight!) talks. I won't lie claiming I attended all of them... OK, I should stop now. My boss thinks I was at the booth at all times.

So, it was an amazing ride, and now it's time to work hard and follow up on all the great user feedback we get from our users “1st hand” at the booth. Next year it will somehow be bigger again. Go figure.

P.S. Talking about a ride - some stretch limos with JFrog logos were spotted around driving some folks to the “Frogs & Friends” event, but that belongs to my next post ...

Replication! What and How.

Update Jul. 24th 2012: As of version 2.6.2  Artifactory also supports event-driven replication. Benefit from all the worlds: pull/push/event-driven!

Working in distributed teams isn’t easy. There are time zone differences, language and cultural differences, and… data distribution. When the data you need is away, you are miserable. So, let’s fix it.

Bring your data home

Let’s take binary repository, for example. Two types of binaries are stored there: your build outputs, and third-party libraries proxied from public servers. Let’s say now you are working in multi-site environment, where different teams in different locations depend on each other’s binaries. So, both of your teams access remote repositories and download their third-party libraries from public repositories (repo1, java.net, SpringSource, etc.). It looks like the other team’s repository is no different from any other remote server. But is that so? Let’s compare:

Feature / Repository Type	Any public repo	Other team’s repo
Access Frequency	Low (only on adding new or updating libraries)	High (Intra-project snapshots)
Unneeded artifacts	Many	Almost none

So, bringing one artifact at a time, on demand, is fine for a public repository, but wrong for inter-project dependencies. What’s the cure? Replication.

The idea is to bring the artifacts from a remote repository before they are actually needed, assuming the time savings on ahead of time downloads are bigger than the loss of bringing in few unneeded artifacts. Now each team has its local copy of the content. And look, it feels like backup (restore from the other server) and like high availability (if one is down, use the other), too! Once you do the replication, you get backup and HA for free!

There are two ways of doing so: either push the artifacts to a remote server when the repository content is changed (by event), or transfer all the recent changes as a batch once in a while. Let’s take a deeper look at both approaches.

Event-driven replication

This seems to be the natural way, isn’t it? Once something happened, you just send the event to the other server, and voila, both servers are up-to-date almost in real time and you always transfer the bare minimum: only what was changed. But here we go with the limitations:

• If you have an existing server, what do you do? Which events will sync all the existing data from your server to the new instance?
• If the event transfer failed without feedback, then what? You know, the network is unreliable. How can you be sure you aren’t missing events?
• What happens when there is a network split? For how long do events need to be queued until the other side reappears? Many snapshot artifacts may no longer be valid by this time.
• Event-driven replication always requires pushing data to the other server. And, as you know, pushing and firewalls don’t get along so nicely.

Quite a bunch problems to solve. You can do that or look at the other type of replication – a scheduled one.

Scheduled replication

This one is simple. Just setup the periods and one server will push data to another one. Can’t push? No problem. Pull then. This plain setup eliminates the problems of event-driven replication. Here’s how:

• Adding a new server – the replication is triggered manually.
• Transfer failed without feedback – just retry the replication.
• Pushing and firewalls aren’t getting along so nicely – since the replication can be started on any end, pull the data from the server instead of pushing it.

You can think about pull replication as your regular remote proxying repository, on steroids. Instead of patiently waiting for the user to request an artifact and only then going to the remote server to find it, your server takes action and fetches the artifacts in advance to pre-populate the cache. Once the assumptions from table above are correct, it makes sense.

Overall, scheduled replication looks impressive. Where’s the catch? Well, there are two major flaws:

• The first is timing. When using event-driven replication, the servers are synced almost immediately after a change.
• The second (and bigger) problem is determining what to transfer. Should we keep some kind of log to determine the deltas? Should we calculate the deltas during the replication? How? By change log? By file content? By file name? All those approaches have clear disadvantages. The log might be incompatible with changes on the other server, deltas by content won’t work on huge binaries, and deltas by file name won’t take copies under consideration. But here’s a nice trick: once you know the files’ checksums, delta calculation isn’t a problem anymore. You can decide if the file needs to be transferred to another server in no time!

So, to sum up: event-driven replication is (almost) immediate and the content to replicate is obvious. Scheduled replication supports both push and pull modes, is event-independent and firewall-friendly, but the content calculation might be a problem (unless you have checksums).

Replication in action
(how we did it in Artifactory)

Fortunately, we at JFrog selected the right type of binary storage from the start. Artifactory features checksum storage. This means we know the checksums for all our files at all times, and use this data in many ways, for example to prevent local file duplications. It was only natural for us to go with scheduled replication, enjoying all its benefits without suffering from its major flaw.

And, indeed, Artifactory now offers great replication support and includes the following features:

• Checksum-based content transfer. Only files with unmatched checksum are passed over the wire. It saves time and money.
• Support for both push and pull modes. To provide a firewall-friendly connection, use pull. To enforce the artifacts on another server, use push.
• Replication of metadata, not only artifacts. It includes all kinds of metadata (e.g. maven, user-created properties, etc.), and it also uses the checksum logic.
• Streaming transfer for superb performance.

You can start using the replication today. Here's a simple and intuitive user guide.

What about the replication timing, you might ask? Well, once the heavy lifting of bare-bones replication is done, adding the events triggers on top of it isn't a problem. We are working on it right now. Checksum-based storage makes it easy (again).

As you can see, checksum-based storage lets you enjoy the worlds of scheduled replication and event-driven replication without sacrificing bandwidth, latency, storage space, and computing power. Want to see for yourself? Download a trial of Artifactory Pro (actually, it takes two for replication), and take it for a ride.

Enjoy your build!

Go beyond Java with CI server and Artifactory

During the last couple of years, continuous integration (CI) and automated release management methodologies have become much stronger in non-Java builds.

Number of familiar tools are used for these methodologies, like the version control system to manages your sources, your build tool to actually build your software from sources and  your build server, which builds your software continuously using the build tool. But is there something else missing? Let's look at a simple diagram, which describes your CI process:

1. Developers fetch needed dependencies (3rd party libraries, other modules).
2. Developers write new code.
3. Code is committed to VCS.
4. Build server polls VCS for changes.
5. Once discovered, the build server builds the software: compiles it, runs tests, and assembles artifacts.
6. Built artifacts are published to QA, staging, or even directly to the end users.


As you can see, everything except stages 1 and 6 is well known and familiar. But what about those two stages? You need a dependency management mechanism for them.

In this post, we’ll illustrate the options for automated builds with dependency management in non-Java builds or when not using .NET with NuGet (use it, if you can! Here’s our take about it). The proposed solution works for any kind of build, be it C, C++, C#, iOS and Objective C, Python, or whatever.

So, let’s see how you can implement CI with dependency management for non-Java projects. Here are the options with their pros and cons:

#	Solution	Pros	Cons
1	Dependencies in VCS	- Use proven build tools - Simple setup – you use VCS anyhow	- VCS won’t fit for binary dependencies. You can read why here.
2	Build tools with built-in dependency management like Maven and Gradle	- Build tool with dependency management	- New tool to learn. Both Maven 2 and Gradle have a pretty steep learning curve. - “Adapted” from Java. While there are ways to build “native” applications with them (easier with Gradle, harder with Maven) it still feels, let’s say, artificial, imposing their new conventions.
3	Declare dependencies on builds in your build server	- Use proven build tools	- Only works for inter-project dependencies (which were built by the same build server) - Not flexible enough       - Includes/excludes       - Layout changes
4	Use shared dependencies storage, a.k.a. “repository” (FTP, file server, etc.)	- Use proven build tools	- Manual repository populating - Managing the repository

As you can see, none of the solutions are without the cons.

Here comes Artifactory

Artifactory is  a binary repository – built with binaries management in mind in terms of versioning, management, security, and build servers integration.

As such, using Artifactory completely eliminates the cons of the fourth solution. Your build can populate the repository using powerful REST API. Management is easy and streamlined.

But there’s more. By using Artifactory CI integration (for Jenkins, TeamCity and Bamboo), you can also avoid the cons of the third solution listed above. First, you can specify which artifacts you are willing to publish. They will be uploaded to Artifactory in the end of the build. Second, you can specify which dependencies your build needs. They will be downloaded from Artifactory during the run. All this simply by using build server UI.

The Artifactory Jenkins plugin, for example, defines as part of the Generic build support, a simple pattern-based language that allows you to express what artifacts from the build are going to be deployed to the repository. This includes attaching dynamic searchable properties to these artifacts upon deployment.

First, enable Generic-Artifactory Integration in the Build Environment:

Next, configure your custom deployment and resolution rules. Let's start with deployment (publishing):

In the above example, we configured the following rules for deployment. All the artifacts will be deployed from the working directory into the ‘libs-release-local' repository (configured above), maintaining the path for each file:

Pattern	Meaning
**/x64/*.dll=>x64Win	Deploys all DLLs to the 'x64Win' directory
**/*.zip=>winFiles	Deploys all zip files to the winFiles directory
unix/*.tgz	Deploys all tgz files under the unix directory to the root directory of the target repository

The plugin also controls which artifacts to resolve from the repository before the build starts. The resolution allows you to specify smart search patterns:

In the above example, we configured the following rules for dependencies resolution:

Pattern	Meaning
libs-release-local:x64Wi/*; compatibilityLevel =medium,high	Resolves the files from the x64Wi directory of the libs-release-local repository to the root of the workspace, but only if the ‘compatibilityLevel' property is set to be above medium
libs-snapshot-local:*.zip=>winFiles	Resolves all zip files from libs-snapshot-local repository to winFiles directory under the root of the workspace
libs-snapshot-local:unix/distro.tgz=>linuxFiles	Resolves the distro.tgz file from unix directory in libs-snapshot-local to linuxFiles directory under the root of the workspace
libs-release-local:**/* @winx64_build#released	This example shows dependency to artifacts produced during an earlier build that has been marked with a "released" status

From a configuration standpoint, this support for automatic dependency declaration and publishing makes it very easy to support a release flow where multiple artifacts are collected towards building the final release.

You are more than welcome to give it a try. The publishing functionality described above is available in the free open source version of Artifactory. If you want to configure dependencies resolution, go ahead and download the Pro version evaluation.

Dependency management is critical for continuous integration and rapid release. By adding Artifactory to your CI stack, you can easily overcome the lack of such functionality in your build tool, leaving the dependency resolution and artifacts deployment to the binary repository and your build server.

JFrog jumps at Devops opportunity with continuous integration repository

Analyst: Jay Lyman 

Israel-based JFrog backs the open source Artifactory repository management software, where it finds audience with both application developers and IT operations teams.

Its positioning between these two parties managing one of their common challenges in software artifacts and binaries places JFrog at the crux of the devops trend that is pulling development and IT operations together. While its Artifactory software and repository management remain somewhat unique in the industry, we see a growing list of competing vendors and categories, particularly as more development and operations center on cloud computing.

The 451 Take

JFrog and its repository management software benefit from their unique position at the crossroads of software developers and IT operations, or dev! ops, where the two come together primarily for speed and efficiency. JFrog's early all-in bet on the Jenkins continuous integration server, a fork of the Oracle-owned Hudson, appears to be paying off as the market continues to favor Jenkins. Looking ahead, it will be critical for JFrog to differentiate itself as other vendors and categories cross more over into competition. Also key will be JFrog's ability to integrate and grow with PaaS offerings in the market, but we expect we will see the company consistently here.

Context

JFrog, based in Netanya, Israel, backs the Artifactory binary repository management software, which is open source under the LGPLv3 license. The company was founded in 2008 by its current CEO Shlomi Ben Haim, its current CTO Yoav Landman and current Chief Architect Frederic Simon, all of whom haved worked in the Java and open source communities together. JFrog has about 16 employees, most of whom are engineers, and plans to have a h! eadcount of about 40 by the end of 2012. The company launched ! its first paid product Artifactory Pro at the end of 2009, starting with some key, large customers including LinkedIn and Netflix. Today, JFrog reports almost 250 paying customers and its binary repository management software running on the same number of servers. JFrog says it is currently considering venture capital investment options, but is well funded from its own income and angel investment from its launch.

Products

JFrog's Artifactory product manages binary repositories as software moves through development to testing and quality-assurance and eventually to deployment. The software sits as a proxy between other development tools used in managing software repositories and continous integration, such as Apache Ant and Maven build automation, Ivy dependency manager and Gradle project automation. Artifactory caches software artifacts so repeated downloading is not necessary. Artifactory also blocks unwanted or external requests for internal repository artif! acts, controlling how, where and by whom artifacts are deployed. This helps to manage artifacts and third-party dependencies used by developes and IT operations, which can also share repositories among different departments or teams using Artifactory. The Artifactory software itself is built on the Java Content Repository, which helps support high concurrency and data integrity, the company says. Artifactory's underlying storage, which is backup ready, also supports the attachment of searchable XML metadata and user-defined properties via JFrog's OpenMetadata technology. The software features granular permission controls that can be managed through a simple UI.

JFrog offers its Artifactory repository management software in two versions, Pro and Cloud. Artifactory Pro is an annual subscription that includes a set of paid add-ons bundled with the open source software. The Pro version, priced at $2,350 per year, includes updates, full maintenance and bug fixes as well as a growing list of add-ons for continuous integration server support, resource management, license control, search and other capabilities that go along with the repository management. The cloud version, Artifactory Online, is the same offering in SaaS form with SLA support. Users can quickly set up private repositories using the service without the typical requirements of configuring and customizing a server and access.

The newest version of the software, Artifactory 2.6, is expected in the second quarter of 2012 and is focused on customizable release management. Much of this centers on extending Artifactory management beyond pre-staging to encompass more of the software release process. The idea is to speed the time between software testing and release by maintaining consistency and manageability of software repositories.

Technology

JFrog reports that the use and proliferation of cloud computing has resulted in an enterprise software release process that requires the management of software binaries and repositories much earlier in the effort. This coincides with the trend of devops, which demands that developers and IT operations work closer together and consider each others' roles and responsibilities more thoughtfully. JFrog says that while binaries are closely tracked through testing and QA phases, they can quickly get lost once code hits production. Thus, Artifactory i! s aimed at supporting that move of software to production. JFrog says it is gaining traction with Artifactory Online because of a move by major players, including SpringSource, to put more of their development and support in the cloud.

Artifactory also integrates with a key devops technology: continous integration servers, including Bamboo , TeamCity and Jenkins. JFrog is also benefiting from its decision to support Jenkins, which is a fork of the Hudson continuous integration server from Oracle. While we saw the market supporting both servers last year, it appears there is more momentum and vitality for Jenkins currently and this appears to be contributing to traction for JFrog.

Another part of JFrog's current growth centers on its focus on application programming interfaces (APIs), which have emerged as critical for promoting communities around connectors and plug-ins. JFrog stresses the importance of giving its users and customers a stable, documented API along with examples. JFrog also highlights that APIs are a sort of common language between software developers and IT operations teams, which both work closely with APIs to make things work.

Finally, JFrog is also adding more support for .Net and the Windows world, particularly with its recently-added support for NuGet, a .Net package manager. Through an add-on, Artifactory can support and proxy NuGet packages for Visual Studio .Net applications. This is significant as we see .Net and Windows catching up in devops after trailing to mostly Linux and open source programming frameworks and languages the previous few years.

Integrations and partnership

Artifactory is commonly deployed alongside other key devops technologies, including the continuous integration servers such as Bamboo and Jenkins as well as server automation frameworks such as Chef and Puppet. The Artifactory software also works with a range of other development tools in dependency management, build and project automation and other areas. JFrog also partners with CloudBees, a PaaS provider that is centered on the Jenkins CI server.

Competition

Its work in Java and Apach! e means that JFrog is competing mostly with Sonatype, backer of the Apache Maven and its own Nexus repository management software. While JFrog supported the Jenkins fork of the Hudson CI server last year, Sonatype remained supportive of Hudson. This continues to be the case today and while the market does seem to be favoring Jenkins, the fact that Oracle still backs Hudson may intensify the competition from Sonatype. Another category of competitors comes from the code vetting and management world, where vendors such as Black Duck continue to extend further into the development process. Other competitors here include OpenLogic, Palamida and Protecode. Another area that may represent more competition for JFrog going forward is cloud monitoring and management. For example, Electric Cloud is a cloud automation and devops vendor that includes artifact management in its offerings. JFrog must also compete with use of other open source software for repository management, such as th! e Apache Archiva repository manager.

SWOT Analysis

Strengths

JFrog and its Artifactory repository management software sit at the crux of the growing devops trend in its technology and support for both software developers and IT operations.

Weaknesses

The company remains somewhat obscure and is lesser known than other vendors in the small but growing devops space.

Opportunities

The growth of devops practices and processes among both newer, Web 2.0 type users and more mainstream enterprises could provide more than enough fuel for JFrog's growth.

Threats

Other vendors, particularly those dealing with software development and deployment in the cloud, are increasingly offering similar repository managemenet features and capabilities.

QCon 2012 - Perfect as Everything in London Should Be

Update 13 Jul. 2012: The video recording of my talk was published on infoq.com

It was JFrog's second QCon London, and it just gets better. Imagine: even the London weather was perfect, not to mention the sessions, booth traffic, show organization and food (what, you say, good English food? Well, great IndoPak food, at least). Due to high demand by sponsors, the exhibition took place on two floors (as opposed to one floor last year). Our JFrog booth was located in the same place as in 2011. We’re getting used to the place and are looking forward to returning next March!

The speaker panel was extremely impressive, featuring gurus like Martin Fowler, Adrian Cockcroft (the man behind Netflix’ cloud), Dwight Merriman (co-creator of MongoDB), Damien Katz (creator of CouchDB) and Rich Hickey (creator of Clojure).

The conference started with two training days - six full-day tutorials each. From my perspective, the most interesting two tutorials were “Cloud Architecture” by Adrian Cockcroft, where he shared the architecture, best practices and decisions behind Netflix’ cloud (which Artifactory is proud to be a part of) and “Continuous Delivery” by ThoughtWorks’ Tom Sulston (that’s as close to the roots of the famous “Continuous Delivery” book as you can get). For me, the most fascinating thing in the Continuous Delivery process as ThoughtWorks sees it, is that its virtues are exactly the same as we based our Artifactory upon back in 2006: DevOps automation and rapid release cycle. We appreciated the validation of our concept.

The remaining three days of the week were all-day sessions. It’s impossible to review such a significant number of talks in one blog post, so I’ll concentrate only on the excellent keynote addresses (with one exception).

Martin’s conference-opening keynote speech was about data. The main feature of modern data is that it is bigger than you think. Polyglot storage in general and various kinds of NoSQL look like the right solution.

My favorite keynotes are usually the evening ones. A beer in your hand makes any amusing talk even more enjoyable. One named “Developers Have a Mental Disorder” I couldn’t miss! Greg Young gave a great show, funny and entertaining, about serious dilemmas in software development that we, the developers, prefer to ignore. The brightest example, of course is the downside of DRY (did you ever think about one?). By removing duplication, we increase coupling, which can be much worse.

Thursday morning’s keynote address was delivered by Rich Hickey. He spoke about the differences between “Simple” and “Easy”. Sounds pretty similar, but in fact they are very far from being the same. Antonyms to the rescue: simple vs. complex, while easy vs. hard. Now it’s clear - we need to strive to prevent and remove complexity (go simple) without being afraid of the hard. Choosing easiness may end up creating complexity. Things which are easy, but complex, include OOP, mutable state, imperative loops and frameworks (especially ORM). Things which are simple, but not necessarily easy (at least not until you get them), are LISP-ish languages, like Clojure.

My session also took place on Thursday, in relatively small room, about 70 people. I was more than happy to see that it was almost packed. I spoke about building trust in your build process by selecting the right tools for the job (of course, we consider Artifactory as one). I also spoke about the problems of DevOps in the word of Continuous Delivery in the cloud and the rapid release cycle of SaaS applications. I stressed the huge timeshare of binaries in ALM process and the importance of using a tool that really understands binaries to deal with them. That’s exactly the reason why we developed Artifactory.

Half of my session was dedicated to live demos, which went smoothly, incredible as it may sound. According to the feedback received, my talk was well accepted, and hopefully will be useful to some of the attendants for building easier and more reliable release processes. The Q&A session continued at our booth, where we repeatedly did live demonstrations and received excellent feedback each time. If you want to get a feeling of my talk, here’s the slide-deck.

Friday was the last day of the conference. It started hard with a highly technical keynote address by John Allspaw with a scary name: “Resilient Response In Complex Systems”. For someone like me, who doesn’t deal on a daily basis with Disaster Recovery, the session was astonishing. Looking behind the curtain of that kitchen reveals a totally different way of thinking and planning. It may be how individuals and teams have to perform during a disaster (e.g. personal heroism is bad even if successful; it sends the wrong message to the team), or simulating disasters on live production systems (I never could even dare to think about that). The most obvious, but still eye-opening advice that John gave is to learn from successes, not only from failures. It can give us a lot of information and happens much more frequently, no? The only organization with which I am familiar that embraces that technique is the Israeli Air Force.

To sum up, the conference was great by every measure: technical sessions, attendance, networking, Artifactory exposure, and after-show quality time. Thank you, InfoQ, for this wonderful event in London. QCon was a great starting shot for JFrog’s “Busy March”. You still can catch Fredric and Yoav giving talks on various events in US and Europe.