Skip to content

Software Development Blogs: Programming, Software Testing, Agile Project Management

Methods & Tools

Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!

Feed aggregator

Announcing TensorFlow 1.0

Google Code Blog - Wed, 02/15/2017 - 20:43
Posted By: Amy McDonald Sandjideh, Technical Program Manager, TensorFlow

In just its first year, TensorFlow has helped researchers, engineers, artists, students, and many others make progress with everything from language translation to early detection of skin cancer and preventing blindness in diabetics. We're excited to see people using TensorFlow in over 6000 open-source repositories online.


Today, as part of the first annual TensorFlow Developer Summit, hosted in Mountain View and livestreamed around the world, we're announcing TensorFlow 1.0:


It's faster: TensorFlow 1.0 is incredibly fast! XLA lays the groundwork for even more performance improvements in the future, and tensorflow.org now includes tips & tricksfor tuning your models to achieve maximum speed. We'll soon publish updated implementations of several popular models to show how to take full advantage of TensorFlow 1.0 - including a 7.3x speedup on 8 GPUs for Inception v3 and 58x speedup for distributed Inception v3 training on 64 GPUs!


It's more flexible: TensorFlow 1.0 introduces a high-level API for TensorFlow, with tf.layers, tf.metrics, and tf.losses modules. We've also announced the inclusion of a new tf.keras module that provides full compatibility with Keras, another popular high-level neural networks library.


It's more production-ready than ever: TensorFlow 1.0 promises Python API stability (details here), making it easier to pick up new features without worrying about breaking your existing code.

Other highlights from TensorFlow 1.0:

  • Python APIs have been changed to resemble NumPy more closely. For this and other backwards-incompatible changes made to support API stability going forward, please use our handy migration guide and conversion script.
  • Experimental APIs for Javaand Go
  • Higher-level API modules tf.layers, tf.metrics, and tf.losses - brought over from tf.contrib.learnafter incorporating skflowand TF Slim
  • Experimental release of XLA, a domain-specific compiler for TensorFlow graphs, that targets CPUs and GPUs. XLA is rapidly evolving - expect to see more progress in upcoming releases.
  • Introduction of the TensorFlow Debugger (tfdbg), a command-line interface and API for debugging live TensorFlow programs.
  • New Android demos for object detection and localization, and camera-based image stylization.
  • Installation improvements: Python 3 docker images have been added, and TensorFlow's pip packages are now PyPI compliant. This means TensorFlow can now be installed with a simple invocation of pip install tensorflow.

We're thrilled to see the pace of development in the TensorFlow community around the world. To hear more about TensorFlow 1.0 and how it's being used, you can watch the TensorFlow Developer Summit talks on YouTube, covering recent updates from higher-level APIs to TensorFlow on mobile to our new XLA compiler, as well as the exciting ways that TensorFlow is being used:



Click herefor a link to the livestream and video playlist (individual talks will be posted online later in the day).


The TensorFlow ecosystem continues to grow with new techniques like Foldfor dynamic batching and tools like the Embedding Projector along with updatesto our existing tools like TensorFlow Serving. We're incredibly grateful to the community of contributors, educators, and researchers who have made advances in deep learning available to everyone. We look forward to working with you on forums like GitHub issues, Stack Overflow, @TensorFlow, the discuss@tensorflow.orggroup, and at future events.



Categories: Programming

Serverless Architectures

From the Editor of Methods & Tools - Wed, 02/15/2017 - 13:46
Serverless architectures have been touted as the next evolution of cloud-hosted software. Indeed, the promise of resiliency and scalability without the need for infrastructure management sounds too good to be true! But what exactly does a serverless architecture look like? And what are the trade-offs to weigh up when considering using one on your next […]

Impact of Six Additional Leadership Styles on Adopting and Sustaining Agile

Leadership Styles

Leadership Styles

Leadership style has a direct impact on an organization’s ability to adopt and sustain Agile.  Some leadership styles are more supportive and others evoke more of response that is epitomized by locking feral cats and dogs in a room (nobody wins). In a previous entry we reviewed four common leadership styles; six additional styles include:

Laissez-Faire Leadership

A laissez-faire leader is hands-off and allows group members to make the decisions. The leader using this form of leadership will monitor what is being done and will communicate with the team on a regular basis. For this form of leadership to work team members need to be experienced, have discipline and be self-starters. Mature Agile teams can exist under laissez-faire leaders; however immature Agile teams will not receive sufficient leadership and control.

People-Oriented Leadership or Relations-Oriented Leadership

People/Relationship-oriented leadership is focused on organizing, supporting and developing the people on the leader’s team. The focus on the needs of the team is generally supportive of Agile practices. If this form of leadership is taken to extreme it can cause the leader and team to lose focus on the team’s goals.

Servant Leadership

The servant leader works to empower and serve the people s/he leads. Empowerment on an Agile team is removing impediments and coaching the team so it performs to its capability using Agile practices. Servant leadership is considered the most supportive of implementing and fostering Agile teams.  As we have noted there are downsides to servant leadership; however, most problems with servant leadership stem an over focus or mismatch of goals or conflict of vision. If these excesses are controlled servant leadership is an excellent match for Agile.

Task-Oriented Leadership

Task-oriented leaders focus on one thing: getting the job done.  This form of leadership can be perceived as autocratic.  Task-oriented leaders define work, roles and then assign the work. All of the versions of Agile that embrace the principles in the Agile Manifesto are structured around the premise that the team is motivated and can self-organize to address the work they have committed to delivering.  Task-oriented leadership is at odds with Agile principles. When this form of leadership is prevalent, Agile will have a tough time taking root in this environment, even though this form of leadership can be useful in extreme emergencies.

Transactional Leadership

Transactional leadership is built on the premise that team members agree to obey their leader totally when they take a job. Bonded, indentured servitude comes to mind when considering this form of leadership. For this fealty, team members are paid.  During my high school years, I worked in a department store warehouse.  I observed the foremen using this type of leadership “on” most of my fellow workers. As the high school kid, I tended to be treated differently floating between the two groups. This type of leadership caused both sides act out against the other. This form of leadership will stifle Agile and rarely has any long-term value. 

Transformational Leadership

A transformation leader inspires his (or her) team based on a shared vision of the future. This type of leader communicates (early and often) and they lead with enthusiasm, even though they tend to delegate responsibility throughout the team.  This form of leadership provides vision and then supports that vision by empowers others around them. This form of leadership is perfect for establishing Agile but in the long run is difficult to sustain the same levels of passion for a single transactional event.

There is no single perfect leadership style.  Often different leadership styles are used depending on context.  Highly Agile organizations often mix servant leadership styles with transformational.  The transformational style being used to tackle major changes within the organization while the day-to-day leadership style is more akin to servant leadership.  Even organizations with highly participative leadership styles may adopt more autocratic task-leadership styles in periods of great crisis in which consensus would take too long to develop. What is different from less mature or less participative organizations is that you very quickly retreat from this style when the crisis passes and they generally don’t feel good about the event. In order to get a sense how styles shift, ask a few people in that organization to tell you a story about the last crisis the team was involved in and then listen to the answer.  The stories that are told about major events are often very enlightening.

As a reminder, a comparison of the ten leadership styles review is shown above. The styles with the most filled in Harvey Balls are typically the most conducive to adopting and staying Agile.

The prevalent leadership style of an organization can impact both the ability to adopt Agile and then the ability to sustain Agile.  Autocratic, task-oriented and transactional leadership styles are as close to anti-Agile as can be.  While Agile might exist in protected pockets in organizations that these styles are prevalent they will not prosper. Instead, consider adopting kanban or Scrumban without the Agile principles in these environments and then slowly sell change by exposing bottlenecks and constraints.   

 


Categories: Process Management

SE-Radio Episode 282: Donny Nadolny on Debugging Distributed Systems

Donny Nadolny of PagerDuty joins Robert Blumen to tell the story of debugging an issue that PagerDuty encountered when they set up a Zookeeper cluster that spanned across two geographically separated datacenters in different regions.  The debugging process took them through multiple levels of the stack starting with their application, the implementation of the Zookeeper […]
Categories: Programming

Hey, Join My New Project!

NOOP.NL - Jurgen Appelo - Tue, 02/14/2017 - 20:24

I am going to challenge you.

I want to see you do things you’ve never done before. I want you to learn, experiment, fail beautifully, and then try again. And I want to see you make progress in areas that few people in the world have explored.

I am talking about my new project.
You are welcome to join.

Why are you checking your Facebook or Twitter streams multiple times per day? Is it because you were sent to a social media workshop by your manager? Or because these companies are smartly targeting your intrinsic motivators?

What has caused millions of people to start running, exercising, and monitoring their calorie intakes? Was there a government campaign promoting healthier lifestyles? Or is it because thousands of apps, smartphones and wearables have made it a lot more fun?

What convinced me to switch from taxis to ridesharing, from radio stations to streaming music, and from workstations to tablets and notebooks? Is it because it’s part of someone else’s change program? Or because I wanted a more convenient work-life?

I’m sure you get my point.

People don’t change because they’re told to change. People change because smart companies make them want to change. It usually involves techniques borrowed from gamification, behavioral economics, and habitualization.

Consider a fitness tracker, for example. I run three times per week because the metrics of the fitness tracker on my smartphone have gamified the exercises so that I’m competing against myself. By showing me statistics, and comparing those with others, the tracker uses “nudges” borrowed from behavioral economics to influence my behaviors further. And by reinforcing the good behaviors with various triggers and rewards, the app has turned my regular exercises into habits.

Games, nudges, and habits.
That’s how people change.

We now live in a time where manuals, workshops, promotion campaigns, and change programs are not sufficient anymore to achieve organizational change. To really understand and influence people, we can now use smartphones, wearables, big data, artificial intelligence, and a healthy dose of applied psychology and sociology.

Do you find that fascinating?
Let’s try and improve organizations in a more modern way.

JOIN ME

The post Hey, Join My New Project! appeared first on NOOP.NL.

Categories: Project Management

New OnDemand Course - Scrum Overview

10x Software Development - Steve McConnell - Tue, 02/14/2017 - 18:23

Hello, Steve McConnell here. We are always updating our Construx OnDemand training, and I’m happy to announce a new course: Scrum Overview. Scrum enables software development teams to address complex adaptive problems, and in this course you’ll learn Scrum’s elements—its roles, events, and artifacts—as well as their purpose: how they’re all bound together to make Scrum hum. In short, you’ll learn what’s different about Scrum and what makes it so effective.

With the myriad Scrum courses available today, why would you take a course called Scrum Overview? If you’re a nontechnical stakeholder, such as an executive or sales and marketing staff or even a product owner, you might find value in getting an introduction to Scrum without diving into all the details, and the context that’s set in this course can very valuable. Even if you are a practitioner and you expect to get into the in’s and out’s of Scrum on a daily basis, it can useful to start with the context of Scrum so that you understand its full scope before diving into all those implementation details. Either way this can be a valuable introduction and overview of Scrum.

Your instructor in this course is Jenny Stuart. Jenny has been Vice President of Consulting at Construx for more than 10 years, and in that role she has overseen Construx’s work in implementing Scrum, and implementing Agile practices more generally, in organizations throughout North America and around the world. Jenny has worked effectively with individual contributors on Scrum teams, with Scrum Masters, and with executives who are supporting Scrum at the organizational level, and she has learned numerous lessons about how to support Scrum effectively by working at all those different levels. You’re in good hands with Jenny as the leader of this course.

  • Here’s the top-level outline for the course:
  • Introduction
  • The Scrum Framework
  • Scrum Roles
  • Requirements in Scrum
  • Agile Estimation
  • Plan a Sprint
  • Execute a Sprint
  • Wrap Up a Sprint
  • Adoption Pitfalls
  • Conclusion
If you want to go deeper with Scrum, follow this course with Construx OnDemand’s Scrum Boot Camp, which will teach you what you need to know to become certified in Scrum.

If you’re a Scrum Product Owner or want to become one, Product Owner Boot Camp drills down into the details you need to successfully plan releases, reflect stakeholder priorities, ensure the team builds the right product, and communicate with project stakeholders.

For more on developing requirements in Agile scenarios such as Scrum, see Agile Requirements Boot Camp, which teaches you how to use story mapping to define project scope, write user stories, size stories (agile estimation), and develop acceptance criteria for user stories.

Try Construx OnDemand for free today (no credit card required), and enjoy the course!

New OnDemand Course - Scrum Overview

10x Software Development - Steve McConnell - Tue, 02/14/2017 - 18:23

Hello, Steve McConnell here. We are always updating our Construx OnDemand training, and I’m happy to announce a new course: Scrum Overview. Scrum enables software development teams to address complex adaptive problems, and in this course you’ll learn Scrum’s elements—its roles, events, and artifacts—as well as their purpose: how they’re all bound together to make Scrum hum. In short, you’ll learn what’s different about Scrum and what makes it so effective.

With the myriad Scrum courses available today, why would you take a course called Scrum Overview? If you’re a nontechnical stakeholder, such as an executive or sales and marketing staff or even a product owner, you might find value in getting an introduction to Scrum without diving into all the details, and the context that’s set in this course can very valuable. Even if you are a practitioner and you expect to get into the in’s and out’s of Scrum on a daily basis, it can useful to start with the context of Scrum so that you understand its full scope before diving into all those implementation details. Either way this can be a valuable introduction and overview of Scrum.

Your instructor in this course is Jenny Stuart. Jenny has been Vice President of Consulting at Construx for more than 10 years, and in that role she has overseen Construx’s work in implementing Scrum, and implementing Agile practices more generally, in organizations throughout North America and around the world. Jenny has worked effectively with individual contributors on Scrum teams, with Scrum Masters, and with executives who are supporting Scrum at the organizational level, and she has learned numerous lessons about how to support Scrum effectively by working at all those different levels. You’re in good hands with Jenny as the leader of this course.

  • Here’s the top-level outline for the course:
  • Introduction
  • The Scrum Framework
  • Scrum Roles
  • Requirements in Scrum
  • Agile Estimation
  • Plan a Sprint
  • Execute a Sprint
  • Wrap Up a Sprint
  • Adoption Pitfalls
  • Conclusion
If you want to go deeper with Scrum, follow this course with Construx OnDemand’s Scrum Boot Camp, which will teach you what you need to know to become certified in Scrum.

If you’re a Scrum Product Owner or want to become one, Product Owner Boot Camp drills down into the details you need to successfully plan releases, reflect stakeholder priorities, ensure the team builds the right product, and communicate with project stakeholders.

For more on developing requirements in Agile scenarios such as Scrum, see Agile Requirements Boot Camp, which teaches you how to use story mapping to define project scope, write user stories, size stories (agile estimation), and develop acceptance criteria for user stories.

Try Construx OnDemand for free today (no credit card required), and enjoy the course!

Sponsored Post: Aerospike, GoCardless, Auth0, InnoGames, Contentful, Stream, Scalyr, VividCortex, MemSQL, InMemory.Net, Zohocorp

Who's Hiring?
  • GoCardless is building the payments network for the internet. We’re looking for DevOps Engineers to help scale our infrastructure so that the thousands of businesses using our service across Europe can take payments. You will be part of a small team that sets the direction of the GoCardless core stack. You will think through all the moving pieces and issues that can arise, and collaborate with every other team to drive engineering efforts in the company. Please apply here.

  • InnoGames is looking for Site Reliability Engineers. Do you not only want to play games, but help building them? Join InnoGames in Hamburg, one of the worldwide leading developers and publishers of online games. You are the kind of person who leaves systems in a better state than they were before. You want to hack on our internal tools based on django/python, as well as improving the stability of our 5000+ Debian VMs. Orchestration with Puppet is your passion and you would rather automate stuff than touch it twice. Relational Database Management Systems aren't a black hole for you? Then apply here!

  • Contentful is looking for a JavaScript BackEnd Engineer to join our team in their mission of getting new users - professional developers - started on our platform within the shortest time possible. We are a fun and diverse family of over 100 people from 35 nations with offices in Berlin and San Francisco, backed by top VCs (Benchmark, Trinity, Balderton, Point Nine), growing at an amazing pace. We are working on a content management developer platform that enables web and mobile developers to manage, integrate, and deliver digital content to any kind of device or service that can connect to an API. See job description.
Fun and Informative Events
  • DBTA Roundtable Webinar: Fast Data: The Key Ingredients to Real-Time Success. Thursday February 23, 2017 | 11:00 AM Pacific Time. Join Stephen Faig, Research Director Unisphere Research and DBTA, as he hosts a roundtable discussion covering new technologies that are coming to the forefront to facilitate real-time analytics, including in-memory platforms, self-service BI tools and all-flash storage arrays. Brian Bulkowski, CTO and Co-Founder of Aerospike, will be speaking along with presenters from Attunity and Hazelcast. Learn more and register.

  • Your event here!
Cool Products and Services
  • Working on a software product? Clubhouse is a project management tool that helps software teams plan, build, and deploy their products with ease. Try it free today or learn why thousands of teams use Clubhouse as a Trello alternative or JIRA alternative.

  • A note for .NET developers: You know the pain of troubleshooting errors with limited time, limited information, and limited tools. Log management, exception tracking, and monitoring solutions can help, but many of them treat the .NET platform as an afterthought. You should learn about Loupe...Loupe is a .NET logging and monitoring solution made for the .NET platform from day one. It helps you find and fix problems fast by tracking performance metrics, capturing errors in your .NET software, identifying which errors are causing the greatest impact, and pinpointing root causes. Learn more and try it free today.

  • Auth0 is the easiest way to add secure authentication to any app/website. With 40+ SDKs for most languages and frameworks (PHP, Java, .NET, Angular, Node, etc), you can integrate social, 2FA, SSO, and passwordless login in minutes. Sign up for a free 22 day trial. No credit card required. Get Started Now.

  • Build, scale and personalize your news feeds and activity streams with getstream.io. Try the API now in this 5 minute interactive tutorial. Stream is free up to 3 million feed updates so it's easy to get started. Client libraries are available for Node, Ruby, Python, PHP, Go, Java and .NET. Stream is currently also hiring Devops and Python/Go developers in Amsterdam. More than 400 companies rely on Stream for their production feed infrastructure, this includes apps with 30 million users. With your help we'd like to ad a few zeros to that number. Check out the job opening on AngelList.

  • Scalyr is a lightning-fast log management and operational data platform.  It's a tool (actually, multiple tools) that your entire team will love.  Get visibility into your production issues without juggling multiple tabs and different services -- all of your logs, server metrics and alerts are in your browser and at your fingertips. .  Loved and used by teams at Codecademy, ReturnPath, Grab, and InsideSales. Learn more today or see why Scalyr is a great alternative to Splunk.

  • InMemory.Net provides a Dot Net native in memory database for analysing large amounts of data. It runs natively on .Net, and provides a native .Net, COM & ODBC apis for integration. It also has an easy to use language for importing data, and supports standard SQL for querying data. http://InMemory.Net

  • VividCortex is a SaaS database monitoring product that provides the best way for organizations to improve their database performance, efficiency, and uptime. Currently supporting MySQL, PostgreSQL, Redis, MongoDB, and Amazon Aurora database types, it's a secure, cloud-hosted platform that eliminates businesses' most critical visibility gap. VividCortex uses patented algorithms to analyze and surface relevant insights, so users can proactively fix future performance problems before they impact customers.

  • MemSQL provides a distributed in-memory database for high value data. It's designed to handle extreme data ingest and store the data for real-time, streaming and historical analysis using SQL. MemSQL also cost effectively supports both application and ad-hoc queries concurrently across all data. Start a free 30 day trial here: http://www.memsql.com/

  • ManageEngine Applications Manager : Monitor physical, virtual and Cloud Applications.

  • www.site24x7.com : Monitor End User Experience from a global monitoring network. 

If any of these items interest you there's a full description of each sponsor below...

Categories: Architecture

Three Questions to Ask when Being Micromanaged

Mike Cohn's Blog - Tue, 02/14/2017 - 16:00

One of the foundational principles of agile and Scrum is a belief in the power of self-organizing teams. This makes a micromanaging boss, ScrumMaster or product owner a particularly difficult problem for agile teams.

I’ve found asking three questions helpful in dealing with micromanagers.

Who?

The first question is Who? Who is being micromanaged? If you are being micromanaged but the rest of the team is not, this tells you it is your own performance that someone is worried about. If so, you’ll need to improve your own performance and that stakeholder’s view of your performance.

But if your entire team is being micromanaged, the behavior is just part of who that stakeholder is.

To determine whether it’s just you or your entire team being micromanaged, spend a sprint or two noting what types of things draw the micromanager’s attention. Log all micromanaging activities so you can look back at the data and determine who is being micromanaged.

When?

A log of micromanagement activity will also help you answer the second question: When is the micromanaging occurring?

Does the stakeholder micromanage shortly before or after a meeting? For example, a product owner might leave their customer call every Tuesday feeling stressed and more inclined to micromanage. Or a Scrum Master might be prone to micromanage the day before the monthly meeting with the engineering VP.

Some people are more prone to micromanage at a specific time of day. A boss early in my career was particularly prone to micromanaging before his first cup of coffee.

Others may be more prone to micromanagement at specific times during an iteration. Perhaps the person you’re dealing with is most prone to micromanaging during the last few days of the iteration when he or she gets nervous about whether everything will get done. Again, log this type of information so you can later look for patterns.

I use a spreadsheet with the following columns:

Date: The actual date (e.g., March 8, 2017). This usually won’t help identify patterns but can be useful if you look back on the data and need to remember what might have been going on in the organization at the time.

Day of Week: Sometimes micromanaging occurs most frequently on certain days (e.g. Friday) so note the day of the week.

Day of the Sprint: To help see if micromanaging occurs most frequently at certain points within a sprint, note the number of days into the sprint when the micromanaging occurred. For example “Day 3” or perhaps “7 / 10” to indicate it occurred on day seven of a ten-day sprint.

Time: Note the time of day when the micromanaging occurred (e.g., 10:15 A.M.)

Who Was Being Micromanaged: Note whether it was you personally, the entire team, or perhaps a teammate being micromanaged.

What Was Being Micromanaged: Note the issue in this column.

Context: Note whether the micromanaging coincided with anything else occurring within the sprint, project or organization. Did it occur right before or after a meeting? Which meeting? What was occurring during the iteration overall?

Notes: Include anything additional worth remembering about the incident. You can see a sample in the following table.

 

Date

Day of
week

Day of
Sprint Time Micromanager Who? What? Context Notes March 8 Wed 6

10:30

Anne me Story about adding data sources    

Anne asked me for the 3rd time in two days how this was going.

March 8

Wed 6 2:15 Arie team Next week’s new client launch  

Arie emailed the full team to remind everyone how important the new client launch is

 

March 8
 

Thurs 6 9:28 Anne teammate  

Story about Salesforce integration

While en route to daily scrum, Anne asked me to tell Ashish

to see her sometime about the story he’s working on for her.  

Ashish has been providing her a daily update already as she requested.

 

Why?

After you’ve logged a couple of weeks of micromanaging activities, it’s time to ask the third question: Why is the micromanaging happening?

Scan your log looking for patterns. See if there are triggers that create the micromanagement. Perhaps your product owner micromanages you after her weekly meeting with her boss.

Perhaps your line manager is prone to micromanaging at the end of the month when he has to prepare a report for his boss.

Based on the patterns you see, try to identify conversations that may be worth having with whoever is micromanaging. You’re unlikely to get far by merely saying, “Please stop micromanaging.” Instead, talk to micromanagers in an attempt to learn what concerns them that they’re behaving as they are.

Once you’ve identified some of the triggers for micromanaging, it’s time to anticipate and eliminate those triggers.

Anticipate and Eliminate

If you can anticipate micromanaging behavior by noticing when it occurs, work to eliminate the trigger. Often you can do this by proactively providing information to the micromanager.

For example, if you know your product owner gets stressed and micromanages after a weekly meeting with her boss, schedule a meeting with your product owner ahead of that meeting. Be sure your product owner is well informed and prepared for her meeting.

Proactively provide information to stakeholders who are prone to micromanagement. Try to do it just in time so they have (and remember) the information in advance of whatever triggers them.

Avoid creating burdensome new processes for yourself. But you can assert control over a stakeholder (or boss) relationship by proactively providing information rather than waiting to be asked for it and then being forced to provide it on someone else’s schedule.

Some People Are Incurable

By following the advice here, you won’t always be able to eliminate micromanagement. Some stakeholders are incurable micromanagers. But the tips here will help you take greater control over most situations and generally make them more tolerable.

How Have You Handled a Micromanager?

What’s your worst story of being micromanaged? How did you handle the situation? Please leave your thoughts in the comments below.

 

Get Your Free Micromanagement Log

Start tracking to help eliminate micromanagement

Download Now!

Micromanagement Log cover

Azure Functions imperative bindings

Xebia Blog - Tue, 02/14/2017 - 13:09

The standard input and output bindings in Azure Functions are written in a declarative pattern using the function.json. When defining input and output declarative, you do not have the option to change some of the bindings properties like the name or make multiple outputs from one input. An imperative binding can do this for you. In […]

The post Azure Functions imperative bindings appeared first on Xebia Blog.

Created an open source VSTS build & release task for Azure Web App Virtual File System

Xebia Blog - Tue, 02/14/2017 - 08:15

I’ve created a new VSTS Build & Release task to help you interact with the (VFS) Virtual File System API (Part of KUDU API of your Azure Web App). Currently this task can only be used to delete specific files or directories from the web app during your build or release workflow. It will be […]

The post Created an open source VSTS build & release task for Azure Web App Virtual File System appeared first on Xebia Blog.

I’ve Had Enough

NOOP.NL - Jurgen Appelo - Mon, 02/13/2017 - 18:50

I can’t take it anymore.

I’ve had enough of people asking me how they can improve their team, while none of the team members are willing to run any experiments and learn from their failures.

I’ve had enough of organizations that want to scale with agile, while the change programs that managers roll out are still mainly about cutting costs and optimizing profits.

I’ve had enough of politicians promising change and making things better, while the policies of their parties are all about scaremongering and protectionism.

I firmly believe that most people are good. They usually mean well. But more often than not, group performance is abysmal. Progress stalls because teams, organizations, and political parties lack a systemic approach to purposeful evolution. I fear that, in most cases, the whole is less than the sum of the parts. In other words, great people, terrible systems.

Can we help improve those groups?

I’m sure we can. But history proves that writing books, running workshops, and organizing conferences are not enough to achieve sustainable improvement. And despite their heroic efforts, coaches and consultants often see their hard-earned results evaporate after yet another idiotic organizational system failure.

I am convinced that the solution is staring us straight in the eyes. The very reason that teams, organizations, and political systems perform badly is that the world is changing faster and faster. Have you ever seen the adoption rates of smartphones, social networks, or streaming media? Did you see how fast people are learning to use wearables and robots?

Anyone who claims that “people resist change” is just flaunting his or her incompetence.

They key to improving collaboration and performance across teams, organizations and other groups is understanding how some human behaviors are adopted at a rate that is similar to a global epidemic. If you have a good idea, and people aren’t picking it up, it doesn’t mean that they resist the change. It also doesn’t mean that your idea is wrong. It just means that there is no platform enabling the idea to go viral.

I’ve had enough of good people wasting their time in bad teams and organizations. I’ve had enough of fantastic books, workshops, conferences, coaches, and consultants achieving only temporary performance fixes. We need a platform that allows good ideas to spread across teams and organizations at Internet-speed. And like the adoption rates of new technologies, we need that platform to make any behavioral changes sustainable.

I want the whole to be more than the sum of the parts. There should be a platform that helps people grow awesome systems.

Do you want to build that platform with me?

JOIN ME

The post I’ve Had Enough appeared first on NOOP.NL.

Categories: Project Management

Part 3 of Thinking Serverless —  Dealing with Data and Workflow Issues

This is a guest repost by Ken Fromm, a 3x tech co-founder — Vivid Studios, Loomia, and Iron.io. Here's Part 1 and 2

This post is the third of a four-part series of that will dive into developing applications in a serverless way. These insights are derived from several years working with hundreds of developers while they built and operated serverless applications and functions. The platform was the serverless platform from Iron.io but these lessons can also apply to AWS LambdaGoogle Cloud FunctionsAzure Functions, and IBM’s OpenWhisk project.

Serverless Processing — Data Diagram

Thinking Serverless! The Data
Categories: Architecture

Discomfort as a Tool for Change

Google Testing Blog - Mon, 02/13/2017 - 17:53
by Dave Gladfelter (SETI, Google Drive)
IntroductionThe SETI (Software Engineer, Tools and Infrastructure) role at Google is a strange one in that there's no obvious reason why it should exist. The SWEs (Software Engineers) on a project understand its problems best, and understanding a problem is most of the way to fixing it. How can SETIs bring unique value to a project when SWEs have more on-the-ground experience with their impediments?

The answer is scope. A SWE is rewarded for being an expert in their particular area and domain and is highly motivated to make optimizations to their carved-out space. SETIs (and Test Engineers and EngProdin general) identify and solve product-wide problems.

Product-wide problems frequently arise because local optimizations don't necessarily add up to product-wide optimizations. The reason may be the limits of attention, blind spots, or mis-aligned incentives, but a group of SWEs each optimizing for their own sub-projects will not achieve product-wide maxima.

Often SETIs and Test Engineers (TEs) know what behavior they'd like to see, such as more integration tests. We may even have management's ear and convince them to mandate such tests. However, in the absence of incentives, it's unlikely that the decisions SWEs make in response to such mandates will add up to the behavior we desire. Mandates around methods/practices are often ineffective. For example, a mandate of documentation for each public method on an interface often results in "method foo does foo."

The best way to create product-wide efficiencies is to change the way the team or process works in ways that will (initially) be uncomfortable for the engineering team, but that pays dividends that can't be achieved any other way. SETIs and TEs must work to identify the blind spots and negative interactions between engineering teams and change the environment in ways that align engineering teams' incentives. When properly incentivized, SWEs will make optimal decisions enhanced by product-wide vision rather than micro-management.
Common Product-Wide ProblemsHard-to-use APIsOne common example of local optimizations resulting in cross-team de-optimization is documentation and ease-of-use of internal APIs. The team that implements an internal API is not rewarded for making it easy to use except in the most oblique ways. Clients are compelled to use the internal APIs provided to them, so the API owner has a monopoly and will set the price of using it at "you must read all the code and debug it yourself" in the absence of incentives or (rare) heroes.
Big, slow releasesAnother example is large and slow releases. Without EngProd help or external pressure, teams will gravitate to the slowest, biggest release possible.

This makes sense from the position of any individual SWE: releases are painful, you have to ensure that there are no UI and API regressions, watch traffic and error rates for some time, and re-learn and use tools and processes that are complex and specific to releases.

Multiple teams will naturally gravitate to having one big release so that all of these costs can be bundled into one operation for "efficiency." The result is that engineers don't get feedback on features for weeks and versioning of APIs and data stores is ignored (since all the parts of the system are bundled together into one big release). This greatly slows down developer and feature velocity and greatly increases risks of cascading failures when the release fails.
How EngProd fixes product-wide problemsSETIs can nibble around the edges of these kinds of problems by writing tools and automation. TEs can create easy-to-use test environments that facilitate isolating and debugging faults in integration and ambiguities in APIs. We can use fancy technologies to sample live traffic and ensure that new versions of systems behave the same as previous versions. We can review design docs to ensure that they have an appropriate test plan. Often these actions do have real value. However, these are not the best way to align incentives to create a product-wide solution. Facilitating engineering teams' fruitful collaboration (and dis-incentivizing negative interactions) gives EngProd a multiplier that is hard to achieve with only tooling and automation.

Heroes are few and far between so we must turn to incentives, which is where discomfort comes in. Continuity is comfortable and change is painful. EngProd looks at how to change the problem so that teams are incentivized to work together fruitfully and disincentivized (discomforted) to pursue local optimizations exclusively.

So how does EngProd align incentives? Certainly there is a place for optimizing for optimal behaviors, such as easy-to-use integration environments. However, incentivizing optimal behaviors via negative feedback should not be overlooked. Each problem is different, so let's look at how to address the two examples above:
Incentivizing easy-to-use APIsEngineers will make the things they're incentivized to make. For APIs, make teams incentivized to provide integration help in the form of fakes. EngProd works with team leads to ensure there are explicit objectives to provide Fakes for their APIs as part of the rollout.

Fakesare as-simple-as-possible implementations of a service that still can be used to do pre-submit testing of client interactions with the system. They don't replace integration tests, but they reduce the likelihood of finding errors in subsequent integration test runs by an order of magnitude.
Furthermore, have some subset of the same client-owned and server-owned tests run against the fakes (for quick presubmit testing) as well as the real implementation (for continuous integration testing) and work with management to make it the responsibility of the Fake owner to debug any discrepancies for either the client- or the server-owned tests.

This reverses the pain! API owners, who are in a position to make APIs better, are now the ones experiencing negative incentives when APIs are not easy to use. Previously, when clients felt the pain, they had no recourse other than to file easily-ignored bugs ("Closed: working as intended") or contribute changes to the API owners' codebase, hurting their own performance with distractions.

This will incentivize API owners to design APIs to be as simple as possible with as few side-effects as possible, and to provide high-quality fakes that make it easy for clients to integrate with the API. Some teams will certainly not like this change at first, but I have seen API teams come to the realization that this is the best choice for the larger effort and implement these practices despite their cost to the team in the short run.

Helping management set engineering team objectives may not seem like a typical SETI responsibility, but although management is responsible for setting performance incentives and objectives, they are not well-positioned to understand how the low-level decisions of different teams create harmful interactions and lower cross-team performance, so they need SETI and TE guidance to create an environment that encourages optimal behaviors.
Fast, small releasesBeing forced to release more frequently than is required by feature deployment requirements has many beneficial side-effects that make release velocity a goal unto itself. SETIs and TEs faced with big, slow releases work with management to mandate a move to a set of smaller, more frequent releases. As release velocity is ratcheted up, negative behaviours such as too much manual testing or too much internal coupling become more painful, and many optimal behaviors are incentivized.
Less coupling between systemsWhen software is released together, it is easy to treat the seams between different components as implementation details. Resulting systems becoming so intertwined (coupled) that responsibilities between them are completely and randomly mixed and their interactions are too complex for any one person to understand. When two components are released separately and at different times, different versions of them must be compatible with one another. Engineers who were previously complacent about this fragility will become fearful of failed releases due to implicit contract changes. They will change their behavior in beneficial ways such as defining the contract between components explicitly and creating regression testing for it. The result is a system composed of robust, self-contained, more easily understood components.
Better/More automated testingManual testing becomes more painful as release velocity is ramped up. This will incentivize automated regression, UI and performance tests. This makes the team more agile and able to catch defects sooner and more cheaply.
Faster feedbackWhen incremental feature changes can be released to dogfood or other beta channels more frequently, user interaction designers and product managers get much faster feedback about what paths lead to better user engagement and experience than in big, slow releases where an entire feature is deployed simultaneously. This results in a better product.
ConclusionThe SETIs and TEs optimize interactions between teams and create fixes for product-wide, cross-team problems in order to improve engineering productivity and velocity. There are many worthwhile projects that EngProd can do using broad knowledge of the system and expertise in refactoring, automation and testing, such as creating test fixtures that enable continuous integration testing or identifying and combining duplicative tests or tools.

That said, the biggest problem that EngProd is positioned to solve is to break the chain of local optimizations resulting in cross-team de-optimizations. To that end, discomfort is a tool that can incentivize engineers to find solutions that are optimal for the entire product. We should look for and advocate for these transformative changes.
Categories: Testing & QA

Discomfort as a Tool for Change

Google Testing Blog - Mon, 02/13/2017 - 17:53
by Dave Gladfelter (SETI, Google Drive)
IntroductionThe SETI (Software Engineer, Tools and Infrastructure) role at Google is a strange one in that there's no obvious reason why it should exist. The SWEs (Software Engineers) on a project understand its problems best, and understanding a problem is most of the way to fixing it. How can SETIs bring unique value to a project when SWEs have more on-the-ground experience with their impediments?

The answer is scope. A SWE is rewarded for being an expert in their particular area and domain and is highly motivated to make optimizations to their carved-out space. SETIs (and Test Engineers and EngProdin general) identify and solve product-wide problems.

Product-wide problems frequently arise because local optimizations don't necessarily add up to product-wide optimizations. The reason may be the limits of attention, blind spots, or mis-aligned incentives, but a group of SWEs each optimizing for their own sub-projects will not achieve product-wide maxima.

Often SETIs and Test Engineers (TEs) know what behavior they'd like to see, such as more integration tests. We may even have management's ear and convince them to mandate such tests. However, in the absence of incentives, it's unlikely that the decisions SWEs make in response to such mandates will add up to the behavior we desire. Mandates around methods/practices are often ineffective. For example, a mandate of documentation for each public method on an interface often results in "method foo does foo."

The best way to create product-wide efficiencies is to change the way the team or process works in ways that will (initially) be uncomfortable for the engineering team, but that pays dividends that can't be achieved any other way. SETIs and TEs must work to identify the blind spots and negative interactions between engineering teams and change the environment in ways that align engineering teams' incentives. When properly incentivized, SWEs will make optimal decisions enhanced by product-wide vision rather than micro-management.
Common Product-Wide ProblemsHard-to-use APIsOne common example of local optimizations resulting in cross-team de-optimization is documentation and ease-of-use of internal APIs. The team that implements an internal API is not rewarded for making it easy to use except in the most oblique ways. Clients are compelled to use the internal APIs provided to them, so the API owner has a monopoly and will set the price of using it at "you must read all the code and debug it yourself" in the absence of incentives or (rare) heroes.
Big, slow releasesAnother example is large and slow releases. Without EngProd help or external pressure, teams will gravitate to the slowest, biggest release possible.

This makes sense from the position of any individual SWE: releases are painful, you have to ensure that there are no UI and API regressions, watch traffic and error rates for some time, and re-learn and use tools and processes that are complex and specific to releases.

Multiple teams will naturally gravitate to having one big release so that all of these costs can be bundled into one operation for "efficiency." The result is that engineers don't get feedback on features for weeks and versioning of APIs and data stores is ignored (since all the parts of the system are bundled together into one big release). This greatly slows down developer and feature velocity and greatly increases risks of cascading failures when the release fails.
How EngProd fixes product-wide problemsSETIs can nibble around the edges of these kinds of problems by writing tools and automation. TEs can create easy-to-use test environments that facilitate isolating and debugging faults in integration and ambiguities in APIs. We can use fancy technologies to sample live traffic and ensure that new versions of systems behave the same as previous versions. We can review design docs to ensure that they have an appropriate test plan. Often these actions do have real value. However, these are not the best way to align incentives to create a product-wide solution. Facilitating engineering teams' fruitful collaboration (and dis-incentivizing negative interactions) gives EngProd a multiplier that is hard to achieve with only tooling and automation.

Heroes are few and far between so we must turn to incentives, which is where discomfort comes in. Continuity is comfortable and change is painful. EngProd looks at how to change the problem so that teams are incentivized to work together fruitfully and disincentivized (discomforted) to pursue local optimizations exclusively.

So how does EngProd align incentives? Certainly there is a place for optimizing for optimal behaviors, such as easy-to-use integration environments. However, incentivizing optimal behaviors via negative feedback should not be overlooked. Each problem is different, so let's look at how to address the two examples above:
Incentivizing easy-to-use APIsEngineers will make the things they're incentivized to make. For APIs, make teams incentivized to provide integration help in the form of fakes. EngProd works with team leads to ensure there are explicit objectives to provide Fakes for their APIs as part of the rollout.

Fakesare as-simple-as-possible implementations of a service that still can be used to do pre-submit testing of client interactions with the system. They don't replace integration tests, but they reduce the likelihood of finding errors in subsequent integration test runs by an order of magnitude.
Furthermore, have some subset of the same client-owned and server-owned tests run against the fakes (for quick presubmit testing) as well as the real implementation (for continuous integration testing) and work with management to make it the responsibility of the Fake owner to debug any discrepancies for either the client- or the server-owned tests.

This reverses the pain! API owners, who are in a position to make APIs better, are now the ones experiencing negative incentives when APIs are not easy to use. Previously, when clients felt the pain, they had no recourse other than to file easily-ignored bugs ("Closed: working as intended") or contribute changes to the API owners' codebase, hurting their own performance with distractions.

This will incentivize API owners to design APIs to be as simple as possible with as few side-effects as possible, and to provide high-quality fakes that make it easy for clients to integrate with the API. Some teams will certainly not like this change at first, but I have seen API teams come to the realization that this is the best choice for the larger effort and implement these practices despite their cost to the team in the short run.

Helping management set engineering team objectives may not seem like a typical SETI responsibility, but although management is responsible for setting performance incentives and objectives, they are not well-positioned to understand how the low-level decisions of different teams create harmful interactions and lower cross-team performance, so they need SETI and TE guidance to create an environment that encourages optimal behaviors.
Fast, small releasesBeing forced to release more frequently than is required by feature deployment requirements has many beneficial side-effects that make release velocity a goal unto itself. SETIs and TEs faced with big, slow releases work with management to mandate a move to a set of smaller, more frequent releases. As release velocity is ratcheted up, negative behaviours such as too much manual testing or too much internal coupling become more painful, and many optimal behaviors are incentivized.
Less coupling between systemsWhen software is released together, it is easy to treat the seams between different components as implementation details. Resulting systems becoming so intertwined (coupled) that responsibilities between them are completely and randomly mixed and their interactions are too complex for any one person to understand. When two components are released separately and at different times, different versions of them must be compatible with one another. Engineers who were previously complacent about this fragility will become fearful of failed releases due to implicit contract changes. They will change their behavior in beneficial ways such as defining the contract between components explicitly and creating regression testing for it. The result is a system composed of robust, self-contained, more easily understood components.
Better/More automated testingManual testing becomes more painful as release velocity is ramped up. This will incentivize automated regression, UI and performance tests. This makes the team more agile and able to catch defects sooner and more cheaply.
Faster feedbackWhen incremental feature changes can be released to dogfood or other beta channels more frequently, user interaction designers and product managers get much faster feedback about what paths lead to better user engagement and experience than in big, slow releases where an entire feature is deployed simultaneously. This results in a better product.
ConclusionThe SETIs and TEs optimize interactions between teams and create fixes for product-wide, cross-team problems in order to improve engineering productivity and velocity. There are many worthwhile projects that EngProd can do using broad knowledge of the system and expertise in refactoring, automation and testing, such as creating test fixtures that enable continuous integration testing or identifying and combining duplicative tests or tools.

That said, the biggest problem that EngProd is positioned to solve is to break the chain of local optimizations resulting in cross-team de-optimizations. To that end, discomfort is a tool that can incentivize engineers to find solutions that are optimal for the entire product. We should look for and advocate for these transformative changes.
Categories: Testing & QA

Installing a VSTS Build agent on Mac OSX

Xebia Blog - Mon, 02/13/2017 - 16:36
Today I needed to install the VSTS Build Agent on a Mac Mini in the office so we can build the IPhone App. The great part of the new build infrastructure in VSTS is that it is Cross Platform and we CAN do that. Just download the agent and run the command provided in the interface.

ReactJS/Material-UI: Cannot resolve module ‘material-ui/lib/’

Mark Needham - Sun, 02/12/2017 - 23:43

I’ve been playing around with ReactJS and the Material-UI library over the weekend and ran into this error while trying to follow one of the example from the demo application:

ERROR in ./src/app/modules/Foo.js
Module not found: Error: Cannot resolve module 'material-ui/lib/Subheader' in /Users/markneedham/neo/reactjs-test/src/app/modules
 @ ./src/app/modules/Foo.js 13:17-53
webpack: Failed to compile.

This was the component code:

import React from 'react'
import Subheader from 'material-ui/lib/Subheader'

export default React.createClass({
  render() {
    return 
    Some Text
    
  }
})

which is then rendered like this:

import Foo from './modules/Foo'
render(Foo, document.getElementById("app"))

I came across this post on Stack Overflow which seemed to describe a similar issue and led me to realise that I was actually on the wrong version of the documentation. I’m using version 0.16.7 but the demo I copied from is for version 0.15.0-alpha.1!

This is the component code that we actually want:

import React from 'react'
import Subheader from 'material-ui/Subheader'

export default React.createClass({
  render() {
    return 
    Some Text
    
  }
})

And that’s all I had to change. There are several other components that you’ll see the same error for and it looks like the change was made between the 0.14.x and 0.15.x series of the library.

The post ReactJS/Material-UI: Cannot resolve module ‘material-ui/lib/’ appeared first on Mark Needham.

Categories: Programming

SPaMCAST 430 – Project Owner, The Complicated Role, The Thinker, Constraints

SPaMCAST Logo

http://www.spamcast.net

Listen Now
Subscribe on iTunes
Check out the podcast on Google Play Music

The Software Process and Measurement Cast 430  features an essay on product owners.  The product owner role is nuanced, always complicated and sometimes hard.  The essay will help you sort things out.  

Steve Tendon brings another chapter in his Tame The Flow: Hyper-Productive Knowledge-Work Performance, The TameFlow Approach and Its Application to Scrum and Kanban, published by J Ross (buy a copy here) to the cast.  In this installment we talk about Chapter 15, Understanding the Impact of a Constraint.  In our discussion Steve schooled me a bit on constraints.

Gene Hughson brings his  Form Follows Function Blog (the same Gene, that Ryan Ripley called out on last week’s cast) to the cast this week to discuss the third in his series on leadership.  This week we discussed the antipattern Gene calls The Thinker.  Might sound good, but it isn’t.

Have you checked out Agile for Humans? If not please do.  If you are an Agile for Humans listener visiting the Software Process and Measurement Cast for the first time, WELCOME. I hope you subscribe and make us part of your weekly ritual.

Re-Read Saturday News

This week  we tackle Chapter 3 in Carol Dweck’s Mindset: The New Psychology of Success (buy your copy and read along). In Chapter 3 Dweck provides a deep dive into how mindsets affect learning and teaching.  The impact of mindsets on how we learn or how we teach is useful knowledge for anyone involved in coaching or transformation.

Every week we discuss a chapter then consider the implications of what we have “read” from the point of view of someone pursuing an organizational transformation and also how to use the material when coaching teams.  

Remember to buy a copy of Carol Dweck’s Mindset and read along!

Visit the Software Process and Measurement Cast blog to participate in this and previous re-reads.

Next SPaMCAST

In the Software Process and Measurement Cast we talk with Andrew Neitlich on leadership.  We discussed whether leadership can be learned and if tech leadership is different than other kinds of leadership.  Leadership is a core requirement for making Agile effective!

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, for you or your team.” Support SPaMCAST by buying the book here. Available in English and Chinese.


Categories: Process Management

SPaMCAST 430 - Product Owner, The Complicated Role, The Thinker, Constraints

Software Process and Measurement Cast - Sun, 02/12/2017 - 23:00

The Software Process and Measurement Cast 430  features an essay on product owners.  The product owner role is nuanced, always complicated and sometimes hard.  The essay will help you sort things out.  

Steve Tendon brings another chapter in his Tame The Flow: Hyper-Productive Knowledge-Work Performance, The TameFlow Approach and Its Application to Scrum and Kanban, published by J Ross (buy a copy here) to the cast.  In this installment we talk about Chapter 15, Understanding the Impact of a Constraint.  In our discussion Steve schooled me a bit on constraints.

Gene Hughson brings his  Form Follows Function Blog (the same Gene, that Ryan Ripley called out on last week’s cast) to the cast this week to discuss the third in his series on leadership.  This week we discussed the antipattern Gene calls The Thinker.  Might sound good, but it isn’t.

Have you checked out Agile for Humans? If not please do.  If you are an Agile for Humans listener visiting the Software Process and Measurement Cast for the first time, WELCOME. I hope you subscribe and make us part of your weekly ritual.

Re-Read Saturday News

This week  we tackle Chapter 3 in Carol Dweck’s Mindset: The New Psychology of Success (buy your copy and read along). In Chapter 3 Dweck provides a deep dive into how mindsets affect learning and teaching.  The impact of mindsets on how we learn or how we teach is useful knowledge for anyone involved in coaching or transformation.

Every week we discuss a chapter then consider the implications of what we have “read” from the point of view of someone pursuing an organizational transformation and also how to use the material when coaching teams.  

Remember to buy a copy of Carol Dweck’s Mindset and read along!

Visit the Software Process and Measurement Cast blog to participate in this and previous re-reads.

Next SPaMCAST

In the Software Process and Measurement Cast we talk with Andrew Neitlich on leadership.  We discussed whether leadership can be learned and if tech leadership is different than other kinds of leadership.  Leadership is a core requirement for making Agile effective!

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, for you or your team.” Support SPaMCAST by buying the book here. Available in English and Chinese.

Categories: Process Management

Force uninstall Visual Studio 2017 Release candidates

Xebia Blog - Sun, 02/12/2017 - 11:56

If you, like me, are stuck trying to upgrade Visual Studio 2017, then you may only get unblocked by removing everything and starting afresh. Since Visual Studio 2017 is still in Release Candidate and not final, this is something we may have to deal with from time to time. But when the "uninstall" button in […]

The post Force uninstall Visual Studio 2017 Release candidates appeared first on Xebia Blog.