EclipseCon 10 years old

by Andrew Eisenberg, April 17th, 2014

This was the tenth year of EclipseCon and my fourth time attending. I have been using the Eclipse IDE for over 12 years and so much has changed with technology and developers’ expectations. At the beginning, just having a single Java IDE that was smart enough to edit, compile, run, and debug your code was a major breakthrough. And for many years, the trend was to integrate into the IDE, with the expectation that all tools be absorbed into the IDE. Now, this trend is reversing and developers are starting to expect IDEs that can seamlessly connect to tools, allowing developers to use the tools in the way that makes the most sense for them.

The most interesting theme for me at this conference was trying to figure out how developers will be working another 10 years from now.

The future of the IDE

The Orion IDE is a prime example of this reverse-integration trend. Orion is a hosted IDE with a light-weight plugin model. One way that the plugin model allows integration with third party tools is by linking out to them in other browser pages. This allows developers to do programming tasks in the IDE, but still have easy access to external tools for deployment, testing, and monitoring. Ken Walker gave a good talk showing this, cheekily called Browser IDEs and why you don’t like them.

Another example of this is the Mylyn hosted task list, which Gunnar Wagenknecht and I introduced in our talk Unshackling Mylyn from the Desktop. The main idea is that current Mylyn task lists are restricted to working inside of a single Eclipse instance, but developers are looking to interact with tasks outside of the IDE (in the browser, on the desktop, on their phones, etc). The hosted task list provides developers with this capability using different kinds of clients that all operate on a single notion of a task list that is hosted remotely. We provide a simple API so that third parties can provide their own clients. What we presented at EclipseCon was early work and we are looking forward to showing more of this at future conferences.

Lastly, Martin Lippert and Andy Clement, my former colleagues at Pivotal, introduced Flux, a novel approach to a more flexible development environment. The main idea is that developers may want the simplicity of developing in the cloud, but also don’t want to give up the possibility to develop in a more traditional way on the desktop. Flux allows you to connect your local workspace to a cloud host that provides services like editing, compilation, and refactoring. This way, you can work in the cloud while still being able to drop down to the desktop whenever you need to. Watch the screencast.

It is still early work, but it is quite compelling and I’m looking forward to seeing how this progresses.

Java 8

It shouldn’t be surprising that the Java 8 track was the most popular at EclipseCon this year. Java 8 was released in the middle of Alex Buckley’s The Road to Lambda talk. What I thought was most interesting about this talk was that it focused on the design decisions around implementing Java 8 lambdas, why it took so long many years to do so, and why Java is now a better language because of its relatively late adoption of lambdas. I found Let’s make some 0xCAFEBABE particularly interesting with its deep dive into byte code. Lastly, API design in Java 8 showed how libraries and APIs can improve by taking advantage of new language features.

Hackathon

This year, I helped organize an Eclipse hackathon. It was a great experience. We had over 50 attendees, split roughly evenly between project committers and new contributors. The goal was for new contributors work on some real bugs in Eclipse, while being helped by project committers who guided them through the process of setting up a workspace, choosing a bug, and submitting a patch. By the end of the evening we had 7 contributions accepted to the code base. It was encouraging to see so much passion about working with open source.

Everyone's hacking!

There are plenty more photos from the event on the Eclipse Foundation’s Flickr stream.

It was truly a wonderful conference and there was so much more including 3 excellent keynotes and of course lots and lots of beer.

Now that I’m back, I need to catch up on sleep, but I’m already looking forward to next year!

Watch Tasktop webinars

Tasktop Dev 3.5 and Mylyn 3.11 Released

by Sam Davis, April 14th, 2014

Tasktop Dev 3.5 and Mylyn 3.11 are now available. These releases include some cool new features that result from the combined efforts of many people in the Mylyn community and at Tasktop.

Speaking as a Tasktop Dev and Mylyn user, I am already loving the new support for finding text in the task editor. It was originally contributed to Mylyn Incubator a few years ago, but unfortunately the implementation suffered from serious performance problems. Recently I had the pleasure of supervising a Co-op student at Tasktop, Lily Guo, as she reimplemented it with dramatically better performance and improved the UI. Thanks to her efforts this very useful feature is now released and the task editor supports searching for text within the comments, description, summary, and private notes.

Screnshot of Find in the Task Editor

Another long-awaited feature in this release is task-based breakpoint management, which extends the concept of task context to include Java breakpoints. This was implemented as part of a Google Summer of Code project by Sebastian Schmidt, a graduate student at Technical University Munich. It provides several important benefits for Java developers. First, the debugger will not stop at breakpoints that aren’t related to the active task. Second, only breakpoints created while the task was active will appear in the IDE – when working on a task, the breakpoints view and Java editors are no longer cluttered with dozens of irrelevant breakpoints. Because the breakpoints related to a task are only present while that task is active, there is no need to delete or disable these breakpoints – which often contain valuable information such as which lines of code and which runtime conditions trigger a defect – when a task is complete. Finally, breakpoints can be shared with other developers as part of task context.

Screenshot of the context preview page showing breakpoints in the context

In a single view, the Hudson/Jenkins connector provides quick access to status information about selected builds across multiple build servers, even when you are offline. This includes information about build status, build stability, and test failures. But one thing I realized was missing was a quick summary of how many builds are passing, unstable, and failing. This information is now displayed at the top of the Builds view and, when the view is minimized, in a tooltip, making it really easy to tell when there’s a change in the number of failing or unstable builds.

Screenshot of builds view showing summary of build statuses

This release also includes a number of bug fixes and enhancements to the Gerrit connector. Among them are support for comparing images, buttons for navigating to the next/previous inline comment in the compare editor, and a code review dashboard that lets you see which of your changes have been reviewed and whether they have passing or failing builds. The connector also remembers your previous votes on a patch set, so that posting additional comments doesn’t reset your vote. Thanks to Jacques Bouthillier and Guy Perron from Ericsson for their work on comment navigation and the dashboard.

Screenshot of the Code Review Dashboard

To help you prioritize the tasks you are responsible for, a “Show only my tasks” filter has been added to the task list, and the tooltip uses the gold person icon to accentuate those tasks.

Screenshot of the task list showing the new filter button

Tasktop Dev 3.5 is built on Mylyn 3.11, including all of the above features. This release includes a number of bug fixes as well as support for VersionOne 2013. We have also upgraded Tasktop Dev for Visual Studio to support Visual Studio 2013, bringing the benefits of a unified task list to users of that IDE.

For more information, see Tasktop Dev New & Noteworthy and Mylyn New & Noteworthy, or try out Tasktop Dev and Mylyn for yourself.

Watch Tasktop webinars

Tasktop Sync 3.5 released: VersionOne, Zendesk, links get sync

by Mik Kersten, April 1st, 2014

We’re at the ALM Forum this week, where the hot topic is how to scale Agile and DevOps deployments.  What Scott Ambler made clear in his opening keynote is that there isn’t a single Agile best practice that spans the various sizes, domains, business processes that we find across organizations. While the practices and vendor tools implementing them vary greatly, the principles are consistent.  Short iterations, automation, real-time collaboration and end-to-end traceability are critical to an effective software lifecycle.  These principles are relatively easy for individual teams and startups to adopt.  The massive challenge that mid-size and large organizations are faced with is how to reap the benefits of Agile at scale.

While December’s Tasktop Sync 3.0 release extended our support to DevOps, the 3.5 release is all about supporting Agile at scale. Sync is now the lifecycle integration infrastructure for 5 of the top 25 world banks and powers many of the world’s largest Agile deployments.  The larger the scale of the deployment, the more problematic the disconnects between tools and processes become.  With Sync 3.5, we are introducing a new capability to our software lifecycle bus called Artifact Relationship Management.  This provides the last mile of integration needed for large scale Agile.  In addition to synchronizing the artifacts that make up your lifecycle, we now synchronize the relationships between those artifacts.  The result is end-to-end traceability and for best-of-breed and heterogeneous Agile deployments.  Which is pretty much every sizeable Agile deployment.

The internal workings of Artifact Relationship Management are complex due to the different kinds of relationships that make up your software lifecycle architecture.  For example, a requirement can be in a hierarchy, a folder, depend on an internal item or an external item, as well as being connected to tests, builds or source changes in other tools.  While it took 3 PhDs to untangle the various scenarios that enable Sync to federate relationships across tools, as with the rest of Sync, all of this functionality is now easy to configure for your administrators and completely transparent to your end users.  Whether you’re working with traditional requirements managements and Water-Scrum-Fall, or deploying new methodologies for large-sale Agile such as the Scaled Agile Framework (SAFe) or Disciplined Agile Delivery (DAD), you will now have end-to-end visibility, traceability, and collaboration across your best-of-breed tool stack.

RequirementsTraceabilitySLIpattern

We are also very pleased to announce Sync support for our partners VersionOne and Zendesk.  This means that we now have support for all of the market-leading Agile tools, and we have also made significant improvements to our support for Atlassian JIRA Agile, Bugzilla, CA Clarity Agile, IBM Rational Team Concert (RTC), Rally, Microsoft Team Foundation Server (TFS) and ThoughtWorks Mingle.  Adding to our other integrations, our Integration Factory is now continually testing 220 different versions of the Agile, ALM and DevOps tools that we support.

zendesk-versionone

Finally, Sync now has a new desktop and mobile device friendly Web UI. While Sync Studio provides the rich Eclipse-based configuration environment that allows Agile ALM tool administrators to easily deploy Sync purely through configuration, the Web UI provides you with a metrics of what Sync is doing, such as the number of synchronizations and artifact creations that are spanning systems.  Now that Sync has become a core part of the organizations’ Agile and DevOps infrastructure, these metrics provide a quick way to manage your Software Lifecycle Integration infrastructure as it evolves.

For more on the release, see New & Noteworthy

Watch Tasktop webinars

When it comes to Software Delivery, The E in Email Stands for Evil

by Dave West, March 27th, 2014

Dr Evil - Photo courtesy of New Line Media Most organizations will experience failed software projects. They won’t necessarily crash and burn, but they will fail to deliver the value the customer wants. In other words, the software projects will not deliver an appropriate level of quality for the time and resources invested.

The extent of failed software projects is calculated every year in the Standish Chaos report– reporting software failure as 61% in 2013. There are many reasons for that kind of project failure rate. They range from poor requirements processes, to badly managed deployment, and a collection of other issues. Many authors have written about this, from the industry changing first work by Fred Brooks, The Mythical Man Month, to more recent works by the Agile and lean communities, but I don’t wish to re-hash these ideas here. I do, however, want to point out something that causes much trouble, pain and confusion in software projects– Email when used as a primary collaboration and process tool.

Imagine the following situation…

A tester discovers a bug, he documents this bug in his tool of choice (for this example, HP Quality Center), but because it is an important and interesting bug, he also sends an email to three developers who have worked with him on previous bugs. One of those developers replies directly to our tester with notes. The tester replies, adding a business analyst who is no longer involved in this app. Said analyst forwards the email to another business analyst who replies to the tester and yet another developer. The tester, business analyst and developers all agree on a solution, but the tester does not document this in Quality Center. That night, a CSV comes out of Quality Center and is converted into a spreadsheet by the project manager who allocates the bugs to the team. The special bug that the tester and colleagues were working on is allocated to a different developer, someone not involved in the email discussion. This developer talks to a whole different set of people to build a resolution. Sounds far-fetched? It’s not. I have seen much more complex communication networks created on projects. They resulted in confusion and a general disconnect between teams. And this issue is exacerbated across the departmental boundaries of QA, Dev, the PMO and operations because email is a poor way to collaborate. Why? because the “TO” and “CC” lists vary depending on whom the sender knows. And the original bug is just a memory by the 2nd or 3rd reply. Email isolates teams rather than uniting them. In fact, I would go one step further. If email has become one of the primary ways your project team collaborates/works, I would say email has become Evil, from a project success point of view.

To quote Wikipedia, ‘Evil, in its most general context, is taken as the absence of that which ascribed as being good.’ This description accurately describes email when it’s used to drive development, resolve issues or communicate progress. Most email begins with good intentions–adding additional people, replying out of your goodness of heart–but after the first few replies, it descends into layers of confusion, miscommunication and errors.

Email is evil because it:

  1. Does not automatically go to the right people
  2. Does not always include all the right information
  3. Is easy to drop and add new people, adding to confusion
  4. Is not stored, indexed or reference-able after the fact (unless you are the NSA, but that is a whole different blog post ;) )
  5. Holds no status or meta-data that allows for quick search or filtering

Maybe labeling email evil is a bit dramatic, but you get the idea. Email can easily, if not effectively managed, cause problems in your software projects. For that reason, we should reduce our reliance on using email to drive real work.

If you doubt your reliance on email, answer the following question: Can you stop using email for project related activities for one week and instead use your systems, processes and tools to get the work done?

If your answer is no, what can you do instead?

Ideally, use the tools you are meant to be using to manage the artifacts they are meant to manage. For example, a tester shouldn’t need to email anyone. The defects he identifies should be automatically visible to the right group of developers, project managers and fellow testers. Everyone should be able to collaborate on that defect in real time–with no need to send an email, or update a spreadsheet. In fact, testers and their developer colleagues should not have to leave the comfort of their tools of choice to manage their work. Comments, descriptions and status should be available to everyone in the tool they’re using.

Admittedly, the company I work for develops integration software. So I come from that world, but even if you build integrations yourself or use tools that are tightly integrated, the value of working in your tool of choice while the lifecycle is automatically managed through notification the correct people and capturing all collaboration in the context of one set of data, is massive. Miscommunication, misunderstanding and general disconnects among teams and disciplines have a huge and negative impact on projects. How many times have you thought a problem was resolved when it wasn’t because you were ‘out of the loop?’ We would find it unacceptable if our e-retailer or bank didn’t share information across processes, but we accept that our software delivery lifecycle is disconnected and relies on manual processes like email and spreadsheets. This problem is only made more acute with the adoption of Agile methods, lean thinking and dev-ops–movements that encourage smaller batch sizes, faster feedback and more team collaboration.

I encourage you to do two things:

  1. Measure the amount of time/work you are spending/doing in email
  2. Replace that with integration or use of common tools

It is time to use email for what it is intended, sending out happy hour notifications and deciding what pizza to buy at lunch.

Watch Tasktop webinars

Business DevOps is really what we want…

by Dave West, January 8th, 2014

I remember the famous blog by Mike Gualtieri, an analyst at Forrester stating, “I don’t want DevOps, I want NoOps,” creating a passionate debate in the DevOps community about the importance and value of operations. After reading all the comments, it seemed that the solution was a sensible one: Organizations need balance – releasing software requires the skills of both operations and development. For some organizations, this means developers taking on more of the deployment burdens. For others, it’s operations creating automation that is used by developers. And in some companies, it’s Agile teams including operations specialists that focus on both deployment and operations. The bottom line is that DevOps calls for a balanced, thought-through discussion about the role of operations and development. It also calls for collaboration between these two groups.

But hang on a minute – aren’t we missing someone from this discussion? DevOps has focused on connecting development and operations – but mostly in terms of the technical, discipline-oriented work – such as defining techniques that allow builds, deployments, installs and configurations to work seamlessly. DevOps has even promoted the idea that the developer’s work management tools and the organization’s service desks should be integrated. But what DevOPs often misses is that it takes a village (or small city) to deliver software, and a key set of people called “managers” need to also be involved. We need to connect portfolio management to the practice of DevOps – we need to make DevOps, BusDevOps (Business-Dev-Ops).

OK – I can hear the skeptic saying “why do management need to be involved?” Well, “management,” specifically portfolio management and the PMO, are responsible for making strategic investment decisions. They are also, in many organizations, responsible for the financial management of projects/ programs and portfolios. Thus, the process and work done by DevOps need to be managed, and more importantly, reported on by the PMO. This management might be as granular as deciding which trouble tickets to work on, or as macro as seeing the aggregated ticket cost grow and shrink over time and allocating resources accordingly. Depending on your organization, the governance and oversight provided by the PMO needs to be integrated into the process of DevOps allowing improved reporting and decision-making.

We’re bringing Business DevOps together

As part of the Sync 3.0 release we added ServiceNow and JIRA ServiceDesk connectors. These connectors allow tickets to be integrated into both ALM and PMO processes. For example, a service ticket in ServiceNow can generate work items in Clarity, which then are planned in Rally, allocated in TFS to be worked on, and tested in HP QC – all the time being the same “single source of the truth” even if living in many systems. Thus, consistent reporting, collaboration and workflow can be executed against this artifact in real time. With Tasktop Sync 3.0 we allow comments to stream seamlessly from different systems allowing developers, operations, project managers and testers to freely collaborate without leaving the comfort of their own tool. In addition to collaboration by integrating the data across discipline and application boundary, software delivery professionals can generate reports in the system that makes sense to them and of course, get cross discipline and artifact traceability. Integration between operations, development and portfolio management gives organizations the information infrastructure to be more efficient, collaborative and replace the need for manual processes and email and spreadsheets. In fact, one of our missions at Tasktop is to replace the need for email and spreadsheets on software delivery projects and this is just another example of how we can replace those tools.

The creation of the ServiceNow connector was driven by customer demand. When looking at these customers there were two things that unified them:

  1. Increase the lifecycle feedback – Agility highlights the importance and value of feedback. For projects, getting feedback early allows problems to be uncovered earlier and corrective decisions to be made earlier. Though the adoption of Agile methods is widespread, most organizations still suffer from a disconnect between operations, development and the project office.
  2. The need for delivery speed – For many organizations software is crucial for their survival and success. Getting new features and products to market earlier has real impact on the bottom line. But as delivery cadence increased, many of the manual processes that glue together the different disciplines start to break. And while data exchange needs to happen in real time, spreadsheets and email actually start to fracture communication, rather than enable it.

Many organizations talk about Agility, but without automated feedback, Agility really only resides within the boundary of the development team. By connecting development, operations and project managers, organizations have the chance to effectively break down the barriers between those groups, moving to one integrated agile process without assuming that having one process means needing only one tool (which for many organizations is just impossible).

A call to action for Business DevOps

The idea that the way to increase Agility is to reduce the number of disciplines and replace everything with a super developer who can manage the team, work with the business, write great code, test it and then manage its deployment and support, is a pipe dream. Even the most capable developers cannot do everything and specialist practitioners, using the tools that make sense to them, will always be the reality. But that does not mean you have to give up on the dream, organizations can better integrate these groups and disciplines. By focusing on information federation rather than control all groups involved in development can get a better view of what is happening.

Here is a three step program for business DevOps:

  1. Understand the information flow of the primary artifacts – for example, how does a ticket flow through the process from operations to the project office and then into development and test.
  2. Understand the transitions between the artifacts – for example when does a ticket become a new user story or defect and what information would make sense to share across those artifact boundaries.
  3. Replace spreadsheets and manual processes that connect the disciplines today.  Connect up the end tools or adopt a software lifecycle integration business such as Tasktop Sync to make the transition smooth and happen in real time.

Watch Tasktop webinars

Tasktop Sync 3.0 released, service desks get support

by Mik Kersten, December 10th, 2013

Open source projects have it good. Their issue tracker serves as the single system of record for all development, support, quality management and planning activity. The result is a theoretical ideal in terms of a connected software lifecycle. For example, every vote that a user makes for a particular bug is immediately visible to developers. As soon as a new feature is added, users watching the corresponding task are automatically prompted to try the latest build and report back. This kind of real-time connectivity between users, developers and project leaders makes for an incredibly efficient build-measure-learn loop, which explains why so many open source project are able to deliver so much value so quickly. Having lived it day-to-day, it continues to inspire me in wanting to bring these benefits to software delivery in the large, where these benefits can make a tremendous difference.

Tasktop Sync 3.0: Defect Unification

The problem is that this open source project management approach doesn’t scale to the enterprise. It’s fine when you’ve got one stakeholder playing multiple roles. For example, on Mylyn I played the role of developer, product manager, tester, and support desk. I spent so much of my time triaging and commenting on bug reports that, in order to help me get through the tickets fast enough to have enough time for coding, I ended up adding features to Mylyn to make it work as a developer’s inbox for triaging tickets. The experience of other open source projects leads that I know is very similar, in that a tremendous portion of their time is spent triaging and responding to users. This direct touch with end users enables open source developers leverage the collective wisdom of their community so quickly.

However, the developer’s issue tracker does not scale to meet the demands of commercial software support, such the need for SLAs and ITIL processes. So a separate help desk tool is required, once that separation is made, real-time collaboration between the developer and support team stops, and reverts to inefficient channels such as email and meetings. The result is a chasm between the people who are user facing and those who are developing the application. The knowledge of the customer’s experience gets siloed into the help desk and voice of the customer gets diffused by the time that the next sprint planning session comes around. Given the increasingly primary role that the service desk plays in the software lifecycle, as evidenced by the amazing growth of ServiceNow, we need to fix this.

Tasktop Sync 3.0: ITSM

Our goal with Software Lifecycle Integration is to unify the ALM stack while allowing software stakeholders to use the systems that make them most productive. With today’s Tasktop Sync 3.0 announcement, we are very happy to reveal that the Sync bus now supports ITSM artifacts such as tickets and problems, and can connect service desk tools to the large and growing number of Agile and ALM tools that we support. Tasktop Sync makes it possible to extend the popular Defect Unification SLI pattern to the service desk, meaning that tickets matching specific criteria, such as those marked as problems, are automatically created as issues in the issue tracker or defects in the quality management system, and synchronized bidirectionally from that point on. For example, if the defect is Synced to IBM’s RTC, developers can schedule them onto a sprint, and the support team will instantly know that it has been assigned. And as soon as it’s completed, the workflow transition will happen on the service desk indicating that the fix is ready to review or deploy to the customer. Comments and activity streams are federated in real-time. And then it’s smiles all around.

We are launching two service desk integrations with Sync 3.0. Our integration for ServiceNow integration is fully certified by ServiceNow, and will support the many uses of the ServiceNow platform ranging across its ITSM and lifecycle capabilities. We are also launching support for Atlassian’s recently announced JIRA Service Desk, which builds on our comprehensive support of JIRA versions including the latest JIRA 6.1. And as usual, there will be more to come so please let us know what other support desks you would like to see integrated.

ServiceNow Visualizer

Connecting the help desk and bridging the task management gap between Dev and Ops is the most exciting Sync 3.0 news in terms of our mission to scale the efficiency of open source development to the enterprise software lifecycle. In other news, we’re releasing new template support for inheriting and extending mappings, making it dramatically easier to manage large numbers of of projects with different schemas. For those customers using Rally and Serena Business Manager, we’re very happy to announce the GA of those Sync connectors along with the Tasktop Dev connector for developers accessing Serena from Eclipse and Visual Studio. We’ve also extended the Sync bus to support time tracking federation between Agile and PPM, enabling time on task to flow between your Agile system and CA Clarity.

Sync 3.0: Example

Finally, the big news for both ALM vendors and customers is a beta program of the new Tasktop Connector SDK. You may think that SDKs should be old news given that Tasktop created and maintained the Mylyn SDK, which became one of the most extended SDKs on Eclipse. But it turns out that in order to support the real-time lifecycle bus architecture of Sync, an entirely new integration extensibility layer had to be created in order to support robust and easy-to-implement 3rd party extensibility. Along with it we created a bridge to support Mylyn connectors, so if you created one of those you’ll have a head start. If you’re interested in being an early adopter partner of the SDK, please get in touch.

Tasktop Sync 3.0 Bus

We’re thrilled that the tremendous customer demand that we saw for connecting the service desk ships today, and look forward to bringing the voice of the customer into the enterprise software lifecycle.

Want to learn more about Tasktop Sync 3.0? Register for an upcoming webinar:

When: Thursday, January 23rd, 2010: 12 noon ET
Presented by: Mik Kersten, CEO of Tastkop
Register now: Webinar – Introducing Tasktop Sync 3.0

Watch Tasktop webinars

Mylyn 3.10 Released

by Sam Davis, November 18th, 2013

We are happy to announce that Mylyn 3.10 has been released. This release includes a number of enhancements to improve the user experience as well as support for the latest versions of Gerrit and Hudson.

In June, Eclipse upgraded to Gerrit 2.6 in order to support a new, more streamlined IP process. This makes it much easier for committers to accept contributions to Eclipse. Unfortunately, the Gerrit connector did not support Gerrit 2.6 at that time, so Eclipse contributors had to use the Gerrit web UI. Thanks to the efforts of Tomasz Zarna and others, we were able to support Gerrit 2.6 in a service release, Mylyn 3.9.1, which was released as part of Kepler SR1. Mylyn 3.10 includes this support for Gerrit 2.6 and also supports Gerrit 2.7.

In Mylyn 3.10, we released some enhancements to the task list and task editor, including addressing some shortcomings that have bothered me personally for a long time. To improve the initial experience for new Mylyn users on Windows, by default, attachments are now opened with the Eclipse editor for that file type if one is present, or with the system editor if not, instead of opening in a web browser. This removes an unnecessary and annoying window switch and browser prompt. Without needing to configure anything, you can open attachments without leaving the IDE.

On many occasions, I have marked a task read and then immediately regretted it. Sometimes I’ve even marked several incoming tasks or a whole query read, and then realized I should have looked at the incomings more carefully first. Until now, there was no way of knowing which tasks I had marked read, meaning that I would never know what incomings I had missed. Now, I’ll be able to easily undo marking the tasks read by using the standard undo/redo mechanism.

I like to think of user interface design as a delicate balance of providing useful information and affordances without creating clutter or overwhelming users. Unfortunately, this means saying “no” to a lot of cool ideas. But one of the great things about working on an open source project is that anyone can voice their opinions, and it really does help to determine which features get released. After some debate on bugs and code reviews, some important information has been added to the task list and task editor to make it more readily available:

At the top of the task editor, just below the summary, the date of the last comment is displayed, allowing users to quickly judge the relevance of the task without scrolling down to the end of the comments.
The task list decorates tasks that have private notes with a yellow pencil icon, so that you don’t need to open the task editor to find out if there are notes.
The task list tooltip now indicates how many incoming and outgoing tasks each query or date bin contains.

In addition to supporting Hudson 3.1, the Hudson/Jenkins connector now allows you to quickly open a build in the web UI if you need information that is not available through the connector. When clicking a link to a build, the build editor opens immediately while the build is downloaded in the background. Users can click the “Open with Web Browser” button in the toolbar to access the Hudson/Jenkins web UI.

Finally, I think heavy Gerrit users will really appreciate this small change: when adding an inline comment to a review, it’s now possible to resize the dialog, and to select text in the compare editor and copy it without having to close the dialog and discard your comment.

You can find more information about the Mylyn 3.10 release in the New & Noteworthy. You can get the release here.

Watch Tasktop webinars

Mylyn 3.9: Improved Code Review Tooling

by Steffen Pingel, October 3rd, 2013

Two years ago I claimed that contributing to Eclipse is a tedious process and I’m happy to say that this no longer holds true. The migration from CVS to Git last year and the adoption of Gerrit for code reviews by many Eclipse projects, combined with the arrival of contributor license agreements (CLAs), has made it incredibly easy to contribute to Eclipse.

Gerrit is great news for contributors since anyone with an Eclipse.org account can now propose changes as Git commits. It’s no longer necessary to attach patches in Bugzilla; changes can be pushed directly to Gerrit. In Gerrit it’s easy to work with the changes and, if the CLA has been signed, merging contributed changes only takes committers a few clicks.

I have highlighted in previous posts how the Mylyn Gerrit Connector integrates code reviews in the IDE. When Eclipse.org added CLAs and upgraded to Gerrit 2.6 (which the Mylyn connector didn’t support at the time), I realized how much I rely on the seamless Eclipse integration. Thanks to Tomasz Zarna contributed over 20 changes and didn’t shy away from using the browser Gerrit 2.6 is now supported in the latest Mylyn service release and will soon be available as part of Kepler SR1.

In addition to supporting the latest Gerrit, Bugzilla and Hudson version, Mylyn, and the Gerrit the connector in particular, have seen a number of improvements in the last major release. The code review editors are now complemented by a Review navigator. The navigator view shows all comments in a structured view that simplifies keeping track of parallel discussion streams as code review progress.

Global comments are now embedded in the review editor, with support for spell checking, and comments can be saved as drafts and edited offline. Conveniently, the editor now also supports all patch set operations including rebase.

The Mylyn New & Noteworthy has an overview of all enhancements in the latest release which is available here.

Watch Tasktop webinars

Cheers from Tasktop Boston’s New Office!

by Katelyn Alfano, September 27th, 2013

Finally Tasktop Boston has an office!

As a company in the “growth phase” Tasktop has remote employees all over the world, which is particularly beneficial in terms of our customer meetings, speaking engagements, and conference participation. Tasktop is pretty unique in that sense; we are able to pursue numerous international opportunities even though we are only a company of about 60 people. But we are at the point where we are starting to think about which of our remote locations makes the most sense for brick-and-mortar expansion.

Boston was a pretty obvious choice for several reasons. While we are headquartered in Vancouver, many of our customers are on Eastern Standard Time. Here we are also able to act as the “middle time zone” if you will, for our colleagues and customers in Europe. Boston is also known for its association with start-ups and tech companies. It is a unique environment; the city and suburbs are very supportive of small companies’ growth, and local employees tend to be ambitious and energetic and definitely practice the “work hard, play hard” mentality.  Based off that alone, Boston was a perfect cultural fit for our small company! We’ve grown to four employees out here in the past year. We are not a big group (yet), but with that kind of growth, I’m sure there will be more Boston Tasktopians soon!


The “office location courtship” was a unique process for me. Every office looked GREAT on paper, and when heading over for each building tour, I found myself hoping that this would be “the one” so that we could set our roots down somewhere!  I quickly realized that no office was going to be the perfect space I had pictured in my mind.  We weighed the pros and cons and learned what qualities we could and couldn’t live without. Tasktop is a pretty social company, so we wanted to be in an office with a lot of activity, and being in the midst of other start-ups would be ideal.  With some help from the City Economic Development Department, we finally found a location that fit our needs well and signed on space in the Alewife section of Cambridge, Massachusetts. Sure, we had to give up the glamour and prestige of a Harvard, Kendall, or Back Bay address. But we are still extremely close to the city and are in a brand new office, a beautiful space to call our own, and that’s all we need! Alewife is definitely an up-and-coming area, especially for tech companies, so we look forward to seeing how the area changes as the construction projects progress! Who knows, maybe we’ll look back in ten years and think, “We were working at Alewife before it was the cool place to be!”

Day One at the office was last Monday, and we moved in so seamlessly that Betty, our VP of Marketing, remarked, “I’m worried because this was just too easy.” Sure enough, on Day Two we realized that we were going to have some serious kinks with our internet. I don’t come from an IT background, but let’s just say that I’ve become pretty well-informed on internet speeds and what will and will not make you a fully-functioning employee.  We (hopefully) solved the problem earlier this week, and we are quite relieved to be able to resume business as usual.

Dave, Betty, Kristie, and Katelyn celebrate the opening of our newest office

Several “firsts” in the new office were particularly exciting for me: our first All-Company meeting in the same room together, and our first Happy Hour! Our colleagues were so excited to get the video tour and see pictures of our new space.  Tasktopians are serious team players, so I was often asked for updates on how the office search was going for us.  They are so thrilled that we were able to find such a great office space and are interested to see how we make it our own as we get comfortable. In true Tasktopian champagne-toasting fashion, we celebrated our first Happy Hour at the conclusion of our first successful week in the office.  I always look forward to these get-togethers with my colleagues because they provide a different environment to get to know each other outside of working hours.  Of course it was the highlight of my week!

I’m so happy to finally be in an office with my coworkers. I can say with absolute sincerity that I have established some great friendships with my colleagues in Vancouver and not many people can say that they have made connections like that over video conferencing alone! But after working from home for almost a year, I am thrilled to see what bigger and better things we can accomplish while sitting side by side. Tasktop Boston is about to take over the world, and you’re hearing it here first!

Watch Tasktop webinars

Enjoy more integration options with Tasktop Dev 2.8

by Wesley Coelho, September 3rd, 2013

Tasktop Dev 2.8 was released on August 8 and has several interesting enhancements to note.

This release introduces new capabilities that leverage Tasktop Sync to provide new SCM traceability capabilities across disparate tools. Imagine ACME co. has a development team that has adopted HP ALM. They’ve also adopted HP Application Lifecycle Intelligence (ALI) which includes SCM integration and Tasktop Dev (OEM’d by HP as HP ALI Dev). When ACME’s developers commit code, ALI provides full traceability between the code and defects or requirements managed with HP ALM. All is well with the world until ACME acquires a subsidiary that uses JIRA and wants to integrate it into ACME’s existing infrastructure. Now, code committed against JIRA issues is no longer visible in HP ALI reports, wreaking havoc on the unified visibility and reporting ACME had been getting from ALI.

Commit Traceability

Not to worry, ACME can restore order with Tasktop Dev 2.8 working in concert with Tasktop Sync. By synchronizing HP ALM with JIRA, each JIRA issue becomes associated with a corresponding HP defect or requirement. When committing code against a JIRA issue, Tasktop Dev 2.8 automatically inserts the corresponding HP ID into the commit message. This establishes the link between the code and the HP artifact, thereby restoring the HP ALI traceability and reporting ACME had come to rely on.

Other key improvements for Tasktop Dev 2.8 include support for Tasktop trims in Eclipse 4 such as the working set trim, web search, starred list and task timing counter.

E4 Trims

With the Gmail Connector, developers can bring messages with a given label into the integrated Task List, providing a single “inbox” that unifies both email and incoming notifications from ALM systems. For Tasktop Dev 2.8 the Gmail integration has been enhanced with the ability to jump from a given point in a Gmail message thread in the IDE to the corresponding expanded message in the browser where the full Gmail functionality is available.

Check out Tasktop Dev 2.8 or contact us about the cross-ALM source code traceability feature which is currently available as part of an Early Access release.

Watch Tasktop webinars