Warning: Table './devblogsdb/cache_page' is marked as crashed and last (automatic?) repair failed query: SELECT data, created, headers, expire, serialized FROM cache_page WHERE cid = 'http://www.softdevblogs.com/?q=aggregator&page=1' in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc on line 135

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 729

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 730

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 731

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 732
Software Development Blogs: Programming, Software Testing, Agile, Project Management
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
warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/common.inc on line 153.

Quote of the Day

Herding Cats - Glen Alleman - Mon, 09/26/2016 - 16:20

The essence of mathematics is to not make simple things complicated, but to make complicated things simple - Stan Gudder 

This notion that estimating is hard, estimates are a waste because they are always wrong, willfully ignores the basic mathematics of making decisions of in presence of uncertainty. The foundation of all decision-making, Probability and Statistics. Without this understanding there can be no credible information provided to the decision makers. 

Categories: Project Management

SPaMCAST 412 – XP Explained a Discussion with Steven Adams

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 412 features our discussion of XP Explained, Second Edition with Steven Adams.  It was a great talk that helped me understand why the book has (and continues to have) such a large impact on how I view Agile and software development.
Steve lives in the San Francisco Bay Area (a.k.a, Silicon Valley) where he has a successful career in software development.  Steve has worked for Hewlett Packard, Access Systems Inc,, Trilliant Inc., and Sony Mobile Communications; plus has consulted at Cisco Systems.  Steve has a computer science degree from California State University at Chico, learned software project management at Hewlett-Packard and, in 2009, started his Agile journey with Sony Ericsson.  Steve enjoys listening to technical podcasts, and SpamCast was one of the first and is a favorite!  Steve is also an avid bicyclist (road) and is on track to log over 3,500 miles in 2016.

Blog: https://sadams510.wordpress.com/
Twitter: @stevena510

Re-Read Saturday News

We begin the read/re-read of The Five Dysfunctions of a Team by Patrick Lencioni (published by Jossey-Bass).  The Five Dysfunctions of a Team is a business novel that uses a story to get important ideas across to the reader in a less threatening manner.  This week we address the introduction and some of the backstory. All of this provides the background for us to recognize the impact of poor teamwork!   

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

Next SPaMCAST

The Software Process and Measurement Cast 413 will feature our essay on Scaling Agile and Management Styles.  This essay builds on our recent discussion of servant leadership.  We will also have columns from Steve Tendon talking about another chapter in his great book Hyper Productive Knowledge Work Performance, The Tame Flow Approach and a visit to the QA Corner with Jeremy Berriault.

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 412 - XP Explained a Discussion with Steven Adams

Software Process and Measurement Cast - Sun, 09/25/2016 - 22:00

The Software Process and Measurement Cast 412 features our discussion of XP Explained, Second Edition with Steven Adams.  It was a great talk that helped me understand why the book has (and continues to have) such a large impact on how I view Agile and software development.


Steve lives in the San Francisco Bay Area (a.k.a, Silicon Valley) where he has a successful career in software development.  Steve has worked for Hewlett Packard, Access Systems Inc,, Trilliant Inc., and Sony Mobile Communications; plus has consulted at Cisco Systems.  Steve has a computer science degree from California State University at Chico, learned software project management at Hewlett-Packard and, in 2009, started his Agile journey with Sony Ericsson.  Steve enjoys listening to technical podcasts, and SpamCast was one of the first and is a favorite!  Steve is also an avid bicyclist (road) and is on track to log over 3,500 miles in 2016.

Blog: https://sadams510.wordpress.com/
Twitter: @stevena510

Re-Read Saturday News

We begin the read/re-read of The Five Dysfunctions of a Team by Patrick Lencioni (published by Jossey-Bass).  The Five Dysfunctions of a Team is a business novel that uses a story to get important ideas across to the reader in a less threatening manner.  This week we address the introduction and some of the backstory. All of this provides the background for us to recognize the impact of poor teamwork!   

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

Next SPaMCAST

The Software Process and Measurement Cast 413 will feature our essay on Scaling Agile and Management Styles.  This essay builds on our recent discussion of servant leadership.  We will also have columns from Steve Tendon talking about another chapter in his great book Hyper Productive Knowledge Work Performance, The Tame Flow Approach and a visit to the QA Corner with Jeremy Berriault.

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 412 - XP Explained a Discussion with Steven Adams

Software Process and Measurement Cast - Sun, 09/25/2016 - 22:00

The Software Process and Measurement Cast 412 features our discussion of XP Explained, Second Edition with Steven Adams.  It was a great talk that helped me understand why the book has (and continues to have) such a large impact on how I view Agile and software development.


Steve lives in the San Francisco Bay Area (a.k.a, Silicon Valley) where he has a successful career in software development.  Steve has worked for Hewlett Packard, Access Systems Inc,, Trilliant Inc., and Sony Mobile Communications; plus has consulted at Cisco Systems.  Steve has a computer science degree from California State University at Chico, learned software project management at Hewlett-Packard and, in 2009, started his Agile journey with Sony Ericsson.  Steve enjoys listening to technical podcasts, and SpamCast was one of the first and is a favorite!  Steve is also an avid bicyclist (road) and is on track to log over 3,500 miles in 2016.

Blog: https://sadams510.wordpress.com/
Twitter: @stevena510

Re-Read Saturday News

We begin the read/re-read of The Five Dysfunctions of a Team by Patrick Lencioni (published by Jossey-Bass).  The Five Dysfunctions of a Team is a business novel that uses a story to get important ideas across to the reader in a less threatening manner.  This week we address the introduction and some of the backstory. All of this provides the background for us to recognize the impact of poor teamwork!   

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

Next SPaMCAST

The Software Process and Measurement Cast 413 will feature our essay on Scaling Agile and Management Styles.  This essay builds on our recent discussion of servant leadership.  We will also have columns from Steve Tendon talking about another chapter in his great book Hyper Productive Knowledge Work Performance, The Tame Flow Approach and a visit to the QA Corner with Jeremy Berriault.

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

Five Dysfunctions of a Team, Patrick Lencioni:  Re-Read Week 1

The Five Dysfunctions of a Team Cover

The “Book” during unboxing!

Today we begin the read of  The Five Dysfunctions of a Team by Patrick Lencioni (Jossey-Bass, Copyright 2002, 33rd printing) as part of our Re-Read Saturday feature. This book uses a business novel approach to make his points. As I noted as we completed the re-read of XP Explained, Steve Adams suggested this book. This is a first read for me.  Please buy a copy and read along.  When we are done I will invite anyone that has contributed to the discussion to appear on the Software Process and Measurement Cast for a wrap-up discussion.

The book includes an introduction, two major sections, and 4 additional chapters. The two sections are titled:

  1.    The Fable.  The fable has five parts noted in the table of contents; however, it is made up of a large number of subsections.
  2.    The Model with three parts.

I suspect that we will read the book over 12 -13 weeks, each week representing a review of roughly 20 – 30 pages (depending on breaks in the book and the need to discuss the Lencioni’s ideas). Now without further ado…

Introduction

In the introduction, Lencioni begins by throwing down the gauntlet that teamwork is the ultimate competitive advantage.  In his mind, it is such an advantage because it is rare.  If I hold up the evidence I see in my career as the norm Lencioni hits the mark; real teamwork is not easy and often conflicts with what many of the perceived tenants of the dog-eat-dog hierarchical work environment.

Lencioni goes on to suggest that teams because they’re made up of people, are dysfunctional by nature. Teams often reflect all of the dysfunctions of the people in and around the team.  That said, the basic premise of the book is “that building a strong team is both possible and remarkably simple.”  However, at the same time is hard to create and care for a strong team.  Strong teams require that we overcome behavioral tendencies that disrupt the ability of people to work together.

Lencioni concludes the introduction with a great ‘why should I read this book’ hook: the idea that we are interested in teams because the real power of teamwork is that you achieve more than individuals could do alone.

Section 1: The Fable

Quick Notes: The Fable section is composed of 45 subsections.  Each section ranges from one page to 90 pages.  For example, the first section is called Luck and is a one pager.  The first few sections are an exposition to build upon later in the book.

Luck introduces basic plot premise of the Fable, which Lencioni uses to illustrate the five dysfunctions of a team. DecisionTech is in trouble (if you did not know what a struggling firm looked like in 2002, by 2016 I am sure you have seen one or more them). The Board of Directors, lead by the Chairman, has decided to bring in an outsider, Kathryn Peterson, as the new CEO.  The Chairman of the Board is her primary supporter. 

Part one: Underachievement 

This section continues the exposition and provides sections that include background on the main players in the overall morality play. (Section titles are in bold)

Backstory – DecisionTech began as well funded startup with a hand-picked executive team, nicknamed “the staff” by the rest of the firm. The executive team was much akin to an all-star team.  The firm started off with a great attitude.  The beginning mentally painted the picture of the infamous emotional cycle of change many endeavors seem to face.  By the two-year anniversary, the initial CEO and co-founder, Jeff Shanley was asked to step down but not to leave (warning bells, anyone?). The management team had developed into a toxic morass with people holding on the potential payout of going public. No one was unhappy that Jeff was moved aside.

Kathryn – The other executives of DecisionTech had significant problems with Kathryn’s lack of experience in high tech and the culture of the firms she had been with. That said everyone recognized that the Chairman of the Board was known to have good instincts.  He personally assured the rest of the Board that she would succeed. In reality, DecisionTech was at the edge of the cliff and just changing people without address the real issues was not going to solve the problem. The last sentence in this section: “she (Kathryn) had an amazing gift for building teams” foreshadows the main theme of the book.

Grumblings – In the first few weeks of Kathryn’s term as president, she did or at least was perceived to do nothing other than schedule a series of off-site executive meetings.  People complained about being asked to be away from the office and not being able to control the agenda.

Observations – The title of this section is critical and goes a long way to explaining Kathryn’s behavior that set off grumblings.  Observing DescionTech for two weeks provided Kathryn with an understanding of just how dysfunctional her executive team was and how big a challenge it would be to sort things despite her vast experience.

The next section establishes the background of the individuals (this is not a team, yet) on the executive team.  These first few sections provide a basis for the raison d’être of the book.  Lencioni has painted a picture of a start-up that began with great expectations and an all-star cast of players to staff the executive level. There is no indication that the executive team worked well or played well together.  The lack of teamwork had brought the firm to the brink of failure.

Buy a copy of  The Five Dysfunctions of a Team and read along.  Using the link will help support the blog, podcast and most importantly the author of  The Five Dysfunctions of a Team.

 


Categories: Process Management

Where Are We Going, Doesn't Much Matter It Seems

Herding Cats - Glen Alleman - Sat, 09/24/2016 - 17:15

Chesire Cat“Would you tell me, please, which way I ought to go from here?”
“That depends a good deal on where you want to get to,” said the Cat.
“I don’t much care where–” said Alice.
“Then it doesn’t matter which way you go,” said the Cat.
“–so long as I get SOMEWHERE,” Alice added as an explanation.
“Oh, you’re sure to do that,” said the Cat, “if you only walk long enough.”

(Alice’s Adventures in Wonderland, Chapter 6)

When we hear

The idea behind the #NoEstimates approach to software development isn't to eliminate estimates but, rather, to explore other ways to solve problems without specifically asking, 'How long will it take?'

We first need to ask by what principle of decision making in the presence of uncertainty, what kind of business project has no interest in how long will it take? The answer seems to be a de minimis project. 

Because in the real world not Wonderland with Unicorns, those paying have some sense of where they want to go, how much they are willing to pay, how long they are willing to wait to get there, and what value will be produced by their investment. De Minimis projects have no concern for those answers.

And those spending that customers money appear not very interested in applying known solutions, instead are answering with the Cheshire Cat's words, since the No Estimates advocates appear to live in Wonderland.

For those interested in learning how to produce credible Estimates and make decisions in the presence of uncertainty, here's some starting places that have served me well:

  • How to Measure Anything, Douglas Hubbard.
  • The Flaw of Averages - Why We Underestimate Risk in the Face of Uncertainty, Sam L. Savage.
  • Forecasting and Simulating Software Development Projects: Effective Modeling of Kanban and Scrum Projects Using Monte Carlo Simulation, Troy Magennis.
  • Decision Analysis for Management Judgement, Paul Goodwin and George Wright.

There are many dozens of other books, and 100's of papers describing how to make estimates in the presence of uncertainty. 

After you do some reading and you hear someone say, estimates are hard, estimates are guesses, estimates are always wrong. estimates are a waste, we can decide with estimates, you'll know they didn't read any of these, haven't a clue what they're talking about, and just making things up as the go. Just like the cat

Related articles Flaw of Averages The Reason We Plan, Schedule, Measure, and Correct Essential Reading List for Managing Other People's Money The Flaw of Empirical Data Used to Make Decisions About the Future Making Decisions In The Presence of Uncertainty Decision Making in the Presence of Uncertainty Why Guessing is not Estimating and Estimating is not Guessing IT Risk Management
Categories: Project Management

Risk Tolerance

This is a risk I'm willing to take.

This is a risk I’m willing to take.

A risk is the potential or exposure to danger, harm or loss. The concept of risk is understandable to everyone involved in delivering work, at least a basic level. We understand that “stuff” can happen when we least expect it to happen, in a project or in our individual lives.  The question is whether any specific risk or the accumulation of risks is worth taking action to avoid.  Which risks are perceived to be so daunting that they need to be actively avoided is based on personal and organizational perspectives and biases.  The technical term for this behavior is risk tolerance.  In response to Internal and External Risk, Matt Williams commented:

“An important step that I think often gets overlooked is the act of defining a risk tolerance.”

While many teams (or organizations) may have an intuitive sense of their risk tolerance, I think it’s helpful to have an explicit, conscious discussion about risk tolerance.”

We can define risk tolerance in simple terms as how much value are we willing to lose if a risk materializes.  The impact of a risk materializing and becoming an issue can range from rework, a reduction in returns, shifting positive perceptions or a compliance failure. A reflection of risk tolerance, in the financial markets, is the difference between the rates of return for a financial instrument (e.g. stocks, bonds, and others) and another financial instrument (such as a treasury bond). In finance the higher the risk the higher the return is required to balance.

If risk tolerance is important for the governance of software development and maintenance projects we need a mechanism to define tolerable and intolerable risks before we decide how to ROAM risks.  Assessing risk tolerance is an evaluation of the willingness to take on risks and how much “exposure” from threats from outside the company are acceptable.

In a further comment Mr. Williams went on:

“I think risk tolerance is very context-specific.

It depends in part on the organization – its size, culture, mission, etc. – in part on the project and its specific nature, and in part on the nature of the risk itself.”

Every person and organization has a different level of risk tolerance.  We can visualize risk tolerance in a chart as a curve. Risk tolerance is a balance between probability the probability a risk occurs and the impact that will be realized if it does occur.  In most software development and maintenance efforts defining the risk/tolerance curve is an implicit rather than explicit act.  The issue is that a team’s or organization’s level of  risk tolerance will cause different behaviors.  Risk avoiders, teams or organizations that fear the impact of risks, will tend to do more research or analysis before committing to a direction.  Risk takers tend to try approaches and then pivot if needed.

Risk tolerance affects how everyone in an organization behaves.  Rarely, however, does everyone in an organization have the same tolerance towards risk.  Defining or at least developing an understanding of a team’s risk tolerance isn’t merely an academic discussion.  Differences in risk tolerance can generate tensions and risks of its own, therefore at the very least teams need in the words of Mr. Williams, “have an explicit, conscious discussion.”

Current Risk Arc:

Internal and External Risks

Incorporating the Idea of External Risk into Agile Efforts

Risk Tolerance (Current)

Measuring Risk Tolerance

******

 


Categories: Process Management

Business Dysfunction, Malfunction and Strategy

Herding Cats - Glen Alleman - Thu, 09/22/2016 - 20:03

Mike Cottmeyer posted

This is an interesting article that misses the point of what's going on. Companies have too much management because they are poorly architected and not organized around value producing assets. When you don't have sufficient encapsulation, you end up with too much orchestration. Management is not the problem. It's a symptom of the problem. Firing, or redeploying managers, without fixing the underlying organizational issues will fail cause you to faster and harder. The solution is to refactor the organizational architecture, increasing encapsulation, and then redeploy managers as you are able to reduce the need for them.

The root cause of this dysfunction is the lack of line of sight traceability for Why the firm is in business to how the firm fulfills the strategy needed to deliver on that WHY.

Here's one way that has been shown over the years to connect the dots between Why and How and critically importantly, how the projectize the work efforts needed to implement the strategy.

Notes on balanced scorecard from Glen Alleman With Balanced Scorecard concepts from this briefing, go read Execution: The Discipline of Getting Things Done, then you'll have a foundation for correcting and even avoid what Mike talks about Related articles Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing Deadlines Always Matter
Categories: Project Management

Google VR SDK graduates out of beta

Google Code Blog - Thu, 09/22/2016 - 18:00

Posted by Nathan Martz, Product Manager, Google VR

At Google I/O, we announced Daydream—Google's platform for high quality, mobile virtual reality—and released early developer resources to get the community started with building for Daydream. Since then, the team has been hard at work, listening to feedback and evolving these resources into a suite of powerful developer tools.

Today, we are proud to announce that the Google VR SDK 1.0 with support for Daydream has graduated out of beta, and is now available on the Daydream developer site. Our updated SDK simplifies common VR development tasks so you can focus on building immersive, interactive mobile VR applications for Daydream-ready phones and headsets, and supports integrated asynchronous reprojection, high fidelity spatialized audio, and interactions using the Daydream controller.

To make it even easier to start developing with the Google VR SDK 1.0, we’ve partnered with Unity and Unreal so you can use the game engines and tools you’re already familiar with. We’ve also updated the site with full documentation, reference sample apps, and tutorials.

Native Unity integration

This release marks the debut of native Daydream integration in Unity, which enables Daydream developers to take full advantage of all of Unity’s optimizations in VR rendering. It also adds support for features like head tracking, deep linking, and easy Android manifest configuration. Many Daydream launch apps are already working with the newest integration features, and you can now download the new Unity binary here and the Daydream plugin here.

Native UE4 integration

We’ve made significant improvements to our UE4 native integration that will help developers build better production-quality Daydream apps. The latest version introduces Daydream controller support in the editor, a neck model, new rendering optimizations, and much more. UE4 developers can download the source here.

Get started today

While the first Daydream-ready phones and headset are coming this fall, you can start developing high-quality Daydream apps right now with the Google VR SDK 1.0 and the DIY developer kit.

We’re also opening applications to our Daydream Access Program (DAP) so we can work closely with even more developers building great content for Daydream. Submit your Daydream app proposal to apply to be part of our DAP.

When you create content for the Daydream platform, you know your apps will work seamlessly across every Daydream-ready phone and headset. Daydream is just getting started, and we’re looking forward to working together to help you build new immersive, interactive VR experiences. Stay tuned for more information about Daydream-ready phones and the Daydream headset and controller coming soon.

Categories: Programming

Testing on the Toilet: What Makes a Good End-to-End Test?

Google Testing Blog - Wed, 09/21/2016 - 23:59
by Adam Bender

This article was adapted from a Google Testing on the Toilet (TotT) episode. You can download a printer-friendly version of this TotT episode and post it in your office.

An end-to-end test tests your entire system from one end to the other, treating everything in between as a black box. End-to-end tests can catch bugs that manifest across your entire system. In addition to unit and integration tests, they are a critical part of a balanced testing diet, providing confidence about the health of your system in a near production state. Unfortunately, end-to-end tests are slower, more flaky, and more expensive to maintain than unit or integration tests. Consider carefully whether an end-to-end test is warranted, and if so, how best to write one.

Let's consider how an end-to-end test might work for the following "login flow":



In order to be cost effective, an end-to-end test should focus on aspects of your system that cannot be reliably evaluated with smaller tests, such as resource allocation, concurrency issues and API compatibility. More specifically:
  • For each important use case, there should be one corresponding end-to-end test. This should include one test for each important class of error. The goal is the keep your total end-to-end count low.
  • Be prepared to allocate at least one week a quarter per test to keep your end-to-end tests stable in the face of issues like slow and flaky dependencies or minor UI changes.
  • Focus your efforts on verifying overall system behavior instead of specific implementation details; for example, when testing login behavior, verify that the process succeeds independent of the exact messages or visual layouts, which may change frequently.
  • Make your end-to-end test easy to debug by providing an overview-level log file, documenting common test failure modes, and preserving all relevant system state information (e.g.: screenshots, database snapshots, etc.).
End-to-end tests also come with some important caveats:
  • System components that are owned by other teams may change unexpectedly, and break your tests. This increases overall maintenance cost, but can highlight incompatible changes
  • It may be more difficult to make an end-to-end test fully hermetic; leftover test data may alter future tests and/or production systems. Where possible keep your test data ephemeral.
  • An end-to-end test often necessitates multiple test doubles (fakes or stubs) for underlying dependencies; they can, however, have a high maintenance burden as they drift from the real implementations over time.
Categories: Testing & QA

Increased account security via OAuth 2.0 token revocation

Google Code Blog - Wed, 09/21/2016 - 23:35
Originally posted on Google Apps Developers Blog

Posted by Michael Winser, Product Lead, Google Apps and Wesley Chun, Developer Advocate, Google Apps

Last week, we clarified the expectations and responsibilities when accessing Google user data via OAuth 2.0. Today, we’re announcing that in order to better protect users, we are increasing account security for enterprise Gmail users effective October 5, 2016. At this time, a new policy will take effect whereby users in a Google Apps domain, while changing their passwords on or after this date, will result in the revocation of the OAuth 2.0 tokens of apps that access their mailboxes using Gmail-based authorization scopes. Please note that users will not notice any specific changes on this date and their applications will continue to work. It is only when a user changes their password from that point moving forward that their Gmail-related tokens become invalid.

Developers should modify their applications to handle HTTP 400 or 401 error codes resulting from revoked tokens and prompt their users to go through the OAuth flow again to re-authorize those apps, such that they can access the user’s mailbox again (additional details below). Late last year, we announceda similar, planned change to our security policy that impacted a broader set of authorization scopes. We later decidednot to move forward with that change for Apps customers and began working on a less impactful update as described above.

What is a revoked token?

A revoked OAuth 2.0 token no longer provides access to a user’s resources. Any attempt to use a revoked token in API calls will result in an error. Any existing token strings will no longer have any value and should be discarded. Applications accessing Google APIs should be modified to handle failed API calls.

Token revocation itself is not a new feature. Users have always been able to revoke access to applications in Security Checkup, and Google Apps admins have the ability to do the same in the Admin console. In addition, tokens that were not used for extended periods of time have always been subject to expiration or revocation. This change in our security policy will likely increase the rate of revoked tokens that applications see, since in some cases the process will now take place automatically.

What APIs and scopes are impacted?

To achieve the security benefits of this policy change with minimal admin confusion and end-user disruption, we’ve decided to limit its application to mail scopes only and to exclude Apps Script tokens. Apps installed via the Google Apps Marketplace are also not subject to the token revocation. Once this change is in effect, third-party mail apps like Apple Mail and Thunderbird―as well as other applications that use multiple scopes that include at least one mail scope―will stop accessing data upon password reset until a new OAuth 2.0 token has been granted. Your application will need to detect this scenario, notify the user that your application has lost access to their account data, and prompt them to go through the OAuth 2.0 flow again.

Mobile mail applications are also included in this policy change. For example, users who use the native mail application on iOS will have to re-authorize with their Google account credentials when their password has been changed. This new behavior for third-party mail apps on mobile aligns with the current behavior of the Gmail apps on iOS and Android, which also require re-authorization upon password reset.

How can I determine if my token was revoked?

Both short-lived access tokens and long-lived refresh tokens will be revoked when a user changes their password. Using a revoked access token to access an API or to generate a new access token will result in either HTTP 400 or 401 errors. If your application uses a library to access the API or handle the OAuth flow, then these errors will likely be thrown as exceptions. Consult the library’s documentation for information on how to catch these exceptions. NOTE: because HTTP 400 errors may be caused by a variety of reasons, expect the payload from a 400 due to a revoked token to be similar to the following:

{
"error_description": "Token has been revoked.",
"error": "invalid_grant"
}

How should my application handle revoked tokens?

This change emphasizes that token revocation should be considered a normal condition, not an error scenario. Your application should expect and detect the condition, and your UI should be optimized for restoring tokens.

To ensure that your application works correctly, we recommend doing the following:

  • Add error handling code around API calls and token refreshes that can detect revoked tokens.
  • Upon detecting a revoked token, disable any application features that rely on Google API access until the user can re-authorize your application. For example, suspend any recurring background jobs that sync data with a Google API which may be affected.
  • Notify the user that access has been revoked and prompt them to re-authorize access to their resources.
    • If your app interacts directly with the user, you will need to prompt the user to re-authorize, i.e., send an email to the user and/or show them an alert the next time they open your application.
    • However, if your app runs independently of the user, say a background app that uses the Gmail API, you'll need to notify the user through email or some other mechanism.
    • Provide a streamlined UI for re-authorizing access. Avoid having users navigate through your application to find the original setting.
    • Note that revoked tokens will result in similar error messages regardless of how the token was revoked. Your messaging should not assume that the token was revoked due to a password change.

If your application uses incremental authorization to accrue multiple scopes in the same token, you should track which features and scopes a given user has enabled. The end result is that if your app requested and obtained authorization for multiple scopes, and at least one of them is a mail scope, that token will be revoked, meaning you will need to prompt your user to re-authorize for all scopes originally granted.

Many applications use tokens to perform background or server-to-server API calls. Users expect this background activity to continue reliably. Since this policy change also affects those apps, this makes prompt notification requesting re-authorization even more important.

What is the timeline for this change?

To summarize, properly configured applications should be expected to handle invalid tokens in general, whether they be from expiration, non-existence, and revocation as normal conditions. We encourage developers to make any necessary changes to give their users the best experience possible. The policy change is planned to take effect on October 5, 2016.

Please see this Help Center article and FAQ for more details and the full list of mail scopes. Moving forward, any additional scopes to be added to the policy will be communicated in advance. We will provide those details as they become available.

Categories: Programming

Launchpad Build Event Series - Sub-Saharan Africa

Google Code Blog - Wed, 09/21/2016 - 21:23
Posted by Mercy Orangi, Developer Ecosystem Community Manager

Back in May at Google I/O, we announced the expansion Firebase, a mobile platform that enables you to quickly develop high-quality applications, grow your user base and earn more money. To help developers better understand the range of features in Firebase, our Developer Relations team in Sub-Saharan Africa will be hosting the Launchpad Build Event Series in Sub-Saharan Africa The first leg will be held in Lagos (22nd Sep), followed by Nairobi (26th Sep) and finally Cape Town (29th Sep).

Launchpad Build is an event series aimed at raising awareness, amongst intermediate and expert developers with an existing Web or Android application, around important tools available today.

At this event, engage in talks and hands-on codelabs focused on Firebase Analytics, Firebase Cloud Messaging, Firebase Crash Reporting, Firebase Test Lab, Pirate Metrics, Serverless with Firebase, Tensor Flow and much more. Through the Launchpad Build event, developers will get skills and resources necessary to start using Firebase in their applications.

This is a technical event, with multiple sessions on Firebase, facilitated by Googlers and Google Developer Experts from around the world.

For further information, visit the Launchpad Build Event Series Sub-Saharan Africa Website.

Register now: bit.ly/lpbuildssa2016

Applicants will be contacted with necessary details.

Categories: Programming

Manage Your Workshops with Workshop Butler

NOOP.NL - Jurgen Appelo - Wed, 09/21/2016 - 21:00
Workshop Butler

I am officially an investor now.

I have always been an investor. After all, I have always invested my time, energy, and resources in ideas that seemed to make sense to me. That’s what entrepreneurs do!

But now, I have taken my Lean Funding approach to invest in someone else’s idea. Actually, it is my idea as well, but I have no time to pursue it. I happily let Sergey Kotlov take our idea in a new direction and grow it into something fantastic.

Whether you organize workshops for managers, developers, marketers, or yoga students, there are always things you need to do for your classes, particularly when you work with more than one trainer:

  • Manage your trainers and their licenses
  • Publish the event schedule on your website
  • Provide info about topics, locations, and trainers
  • Process registrations online
  • Send notifications to participants
  • Process feedback and evaluations
  • Produce certificates of completion
  • and much more

Not surprisingly, Workshop Butler started its life as the back-end system for all Management 3.0 workshops worldwide. It has served the brand well, with more than 100 facilitators using the system on a regular basis.

Now, Workshop Butler has evolved to power other brands as well, including Collaboration Superpowers, Lean Change Management, and more.

If you offer classes under a brand name, with multiple trainers, various topics, and different locations, I suggest you check out the Workshop Butler public beta and get Sergey Kotlov to show you around the system.

It would make me happy. {8-)

The post Manage Your Workshops with Workshop Butler appeared first on NOOP.NL.

Categories: Project Management

Extending Web Technology with Android

Android Developers Blog - Wed, 09/21/2016 - 18:01

Developer guest post by Active Theory

Paper Planes started as a simple thought - “What if you could throw a paper plane from one screen to another?”

The heart of our concept was to bring people together from all over the world, using the power of the web - an instant connection to one another. Modern web technology, specifically JavaScript and WebGL, powered the experience on every screen.

Paper Planes was initially featured at Google I/O 2016, connecting attendees and outside viewers for 30 minutes preceding the keynote. For the public launch on International Peace Day 2016, we created an Android Experiment, which is also featured on Google Play, to augment the existing web technology with native Android Nougat features such as rich notifications when a plane is caught elsewhere in the world.

Introduction

Users create and fold their own plane while adding a stamp that is pre-filled with their location. A simple throwing gesture launches the plane into the virtual world. Users visiting the desktop website would see their planes flying into the screen.

Later, users can check back and see where their planes have been caught around the world. Each stamp on the plane reads like a passport, and a 3D Earth highlights flightpath and distance travelled.

In addition to making their own planes, users can gesture their phone like a net to catch a plane that has been thrown from elsewhere and pinch to open it, revealing where it has visited. Then they can add their own stamp, and throw it back into the flock.

WebView

We developed Paper Planes to work across devices ranging from the 50-foot screen on stage at Google I/O to desktop and mobile using the latest in web technology.

WebGL

From the stylized low-poly Earth to the flocking planes, WebGL is used to render the 3D elements that power the experience. We wrote custom GLSL shaders to light the Earth and morph targets to animate the paper as the user pinches to open or close.

WebSockets

When a user “throws” a plane a message is sent over websockets to the back-end servers where it is relayed to all desktop computers to visualize the plane taking off.

WebWorkers

The plane flocking simulation is calculated across multiple threads using WebWorkers that calculate the position of each plane and relay that information back to the main thread to be rendered by WebGL.

To create an experience that works great across platforms, we extended the web with native Android code. This enabled us to utilize the deep integration of Chromium within Android to make the view layer of the application with the web code that already existed, while adding deeper integration with the OS such as rich notifications and background services.

If you’re interested in learning more about how to bridge WebView and Java code, check out this GitHub repo for a tutorial.

Notifications

Firebase Cloud Messaging (FCM) was used to send push notifications to the Android app. When a user’s plane has been caught and thrown by someone else, a notification showing how many cities and miles it has travelled is sent to the device of the plane’s creator via FCM. Outgoing notifications are managed to ensure they are not sent too frequently to a device.

Background Service

We implemented a background service to run once a day which checks against local storage to determine when a user last visited the app. If the user hasn’t visited in over two weeks, the app sends a notification to invite the user back into the app to create a new plane.

The Communication Network

Our application runs on a network of servers on Google Cloud Platform. We used built-in geocoding headers to get approximate geographic locations for stamps and Socket.IO to connect all devices over WebSockets.

Users connect to the server nearest them, which relays messages to a single main server as well as to any desktop computers viewing the experience in that region.

Moving forward

This approach worked extremely well for us, enabling an experience that was smooth and captivating across platforms and form factors, connecting people from all over the world. Extending the web with native capabilities has proven to be a valuable avenue to deliver high quality experiences going forward. You can learn even more on the Android Experiments website.

Categories: Programming

Distributed Stand Up Meetings

Shadow

Distributed Agile teams require a different level of care and feeding than a co-located team in order to ensure that they are as effective as possible. This is even truer for a team that is working through their forming-storming-norming process. Core to making Agile-as-framework work effectively are the concepts of team and communication. Daily stand-up meetings are one the most important communication tools used in Scrum or other Agile/Lean frameworks. Techniques that are effective for making daily stand-ups work for distributed teams include:

  • Deal with the time zone issue. There are two primary options to deal with time zones. The first is to keep the team members within three or four time zones of each other. Given typical sourcing options, this tends to be difficult. A second option is to rotate the time for the stand-up meeting from sprint to sprint so that everyone loses a similar amount of sleep (share the pain option). One usable solution that can be tried when distributed teams can’t overlap is to have one team member (rotate) staying late or coming in early to overlap work times.
  • Identify and attack blockers between stand-ups. Typically, on distributed teams, all parties will not work at the same time. Team members should be counseled to communicate blockers to the team as soon as they are discovered so that something discovered late in the day in one time zone does not affect the team in a different time zone that might  be just starting to work. One group I worked with had stand-ups twice each day (at the beginning of the day and at the end of the day) to ensure continuous communication.
  • Push status outside the stand-up. A solution suggested by Matt Hauser is to have the team answer the classic three questions (What did you do yesterday? What will you do today? Is there anything blocking your progress?) on a WIKI for everyone on the team to read before the stand-up meeting. This helps focus the meeting on planning or dealing with issues.
  • Vary the question set being asked. The process of varying the question set keeps the team focused on communication rather than giving a memorized speech. For example ask:
    1. Is anyone stuck?
    2. Does anyone need help?
    3. What did not get completed yesterday?
    4. Is there anything everyone should know?

This technique can be used for non-distributed teams as well as distributed teams.

  • Make sure the meeting stays “crisp.” Stand-up meetings by definition are short and to the point. The team needs to ensure that the meeting stays as disciplined as possible. All team members should show up on time and be prepared to discuss their role in the project. Discussion includes the willingness to ask for help and to provide help to team members.
  • Ensure that everyone is standing. This is code for making sure that everyone is paying attention and staying focused. Standing is just one technique for helping team members stay focused. Other tips include banning cell phones and side conversations.
  • Use a physical status wall. While the term “distributed” screams tool usage, using a physical wall helps to focus the team. The simplicity of a physical wall takes the complexity of tool usage off the table so the focus can be on communication. Use of a physical wall in a distributed environment will mean using video to capture tasks moving on the wall (after the fact a picture can be provided to the team). If video is not available, use a tool to which EVERYONE has access. Keep tools as simple as possible.
  • Don’t stop doing stand-ups. Stand-up meetings are a critical communication and planning event, not doing stand-ups for a distributed team is an indicator that the organization should go back to project manager/plan-based methods.

Like any other distributed team meeting, having good telecommunication/video tools is not only important, it is a prerequisite. If team members can’t hear each other, they CAN’T communicate.

Stand-ups are nearly ubiquitous in Agile. I would do stand-ups even if I were not doing Agile. However, despite their simplicity, the added complexity of distributed teams can cause problems. The whole team is responsible for making the stand-up meetings work. While the Scrum master may take the lead in insuring the logistics are right or to facilitate the session when needed, everyone needs to play a role.


Categories: Process Management

Android Studio 2.2

Android Developers Blog - Tue, 09/20/2016 - 23:38

By Jamal Eason, Product Manager, Android

Android Studio 2.2 is available to download today. Previewed at Google I/O 2016, Android Studio 2.2 is the latest release of our IDE used by millions of Android developers around the world.

Packed with enhancements, this release has three major themes: speed, smarts, and Android platform support. Develop faster with features such as the new Layout Editor, which makes creating an app user interface quick and intuitive. Develop smarter with our new APK analyzer, enhanced Layout Inspector, expanded code analysis, IntelliJ’s 2016.1.3 features and much more. Lastly, as the official IDE for Android app development, Android Studio 2.2 includes support for all the latest developer features in Android 7.0 Nougat, like code completion to help you add Android platform features like Multi-Window support, Quick Settings API, or the redesigned Notifications, and of course, the built-in Android Emulator to test them all out.

In this release, we evolved the Android Frameworks and the IDE together to create the Constraint Layout. This powerful new layout manager helps you design large and complex layouts in a flat and streamlined hierarchy. The ConstraintLayout integrates into your app like a standard Android support library, and was built in parallel with the new Layout Editor.

Android Studio 2.2 includes 20+ new features across every major phase of the development process: design, develop, build, & test. From designing UIs with the new ConstraintLayout, to developing C++ code with the Android NDK, to building with the latest Jack compliers, to creating Espresso test cases for your app, Android Studio 2.2 is the update you do not want to miss. Here’s more detail on some of the top highlights:

Design

  • Layout Editor: Creating Android app user interfaces is now easier with the new user interface designer. Quickly construct the structure of your app UI with the new blueprint mode and adjust the visual attributes of each widget with new properties panel. Learn more.

Layout Editor

  • Constraint Layout: This new layout is a flexible layout manager for your app that allows you to create dynamic user interfaces without nesting multiple layouts. It is backwards compatible all the way back to Android API level 9 (Gingerbread). ConstraintLayout works best with the new Layout Editor in Android Studio 2.2. Learn more.

ConstraintLayout

Develop

  • Improved C++ Support: You can now use CMake or ndk-build to compile your C++ projects from Gradle. Migrating projects from CMake build systems to Android Studio is now seamless. You will also find C++ support in the new project wizard in Android Studio, plus a number of bug fixes to the C++ edit and debug experience. Learn more.

C++ Code Editing & CMake Support

  • Samples Browser: Referencing Android sample code is now even easier with Android Studio 2.2. Within the code editor window, find occurrences of your app code in Google Android sample code to help jump start your app development. Learn more.

Sample Code Menu

Build

  • Instant Run Improvements: Introduced in Android Studio 2.0, Instant Run is our major, long-term investment to make Android development as fast and lightweight. Since launch, it has significantly improved the edit, build, run iteration cycles for many developers. In this release, we have made many stability and reliability improvements to Instant Run. If you have previously disabled Instant Run, we encourage you to re-enable it and let us know if you come across further issues. (Settings → Build, Execution, Deployment → Instant Run [Windows/Linux] , Preferences → Build, Execution, Deployment → Instant Run [OS X]). For details on the fixes that we have made, see the Android Studio 2.2 release notes.

Enable Instant Run

  • APK Analyzer: Easily inspect the contents of your APKs to understand the size contribution of each component. This feature can be helpful when debugging multi-dex issues. Plus, with the APK Analyzer you can compare two versions of an APK. Learn more.

APK Analyzer

  • Build cache (Experimental): We are continuing our investments to improve build speeds with the introduction of a new experimental build cache that will help reduce both full and incremental build times. Just add android.enableBuildCache=true to your gradle.properties file. Learn more.

Build Cache Setting

Test

  • Virtual Sensors in the Android Emulator: The Android Emulator now includes a new set of virtual sensors controls. With the new UI controls, you can now test Android Sensors such as Accelerometer, Ambient Temperature, Magnetometer and more. Learn more.

Android Emulator Virtual Sensors

  • Espresso Test Recorder (Beta): The Espresso Test Recorder lets you easily create UI tests by recording interactions with your app; it then outputs the UI test code for you. You record your interactions with a device and add assertions to verify UI elements in particular snapshots of your app. Espresso Test Recorder then takes the saved recording and automatically generates a corresponding UI test. You can run the test locally, on your continuous integration server, or using Firebase Test Lab for Android. Learn more.
Espresso Test Recorder
  • GPU Debugger (Beta): The GPU Debugger is now in Beta. You can now capture a stream of OpenGL ES commands on your Android device and then replay it from inside Android Studio for analysis. You can also fully inspect the GPU state of any given OpenGL ES command to better understand and debug your graphical output. Lean more.
GPU Debugger

To recap, Android Studio 2.2 includes these major features and more:

Design

Develop

Build

Test

Learn more about Android Studio 2.2 by reviewing the release notes and the preview blog post.

Getting Started

Download

If you are using a previous version of Android Studio, you can check for updates on the Stable channel from the navigation menu (Help → Check for Update [Windows/Linux] , Android Studio → Check for Updates [OS X]). You can also download Android Studio 2.2 from the official download page. To take advantage of all the new features and improvements in Android Studio, you should also update to the Android Gradle plugin version to 2.2.0 in your current app project.

Next Release

We would like to thank all of you in the Android Developer community for your work on this release. We are grateful for your contributions, your ongoing feedback which inspired the new features in this release, and your highly active use on canary and beta builds filing bugs. We all wanted to make Android Studio 2.2 our best release yet, with many stability and performance fixes in addition to the many new features. For our next release, look for even more; we want to work hard to address feedback and keep driving up quality and stability on existing features to make you productive.

We appreciate any feedback on things you like, issues or features you would like to see. Connect with us -- the Android Studio development team -- on our Google+ page or on Twitter.


What's New in Android Studio 2.2
Categories: Programming

Acceptance Tests & Agile Teams Coaching in Methods & Tools Fall 2016 issue

From the Editor of Methods & Tools - Tue, 09/20/2016 - 13:13
Methods & Tools – the free e-magazine for software developers, testers and project managers – has published its Fall 2016 issue that discusses alternatives to acceptance tests, Agile transformation, software project estimation, Agile coaching and the following free software tools: DbFit, generjee, Mox. Methods & Tools Fall 2016 issue content: * Alternatives to Acceptance Tests […]

The Five Belts Of The Product Owner

Xebia Blog - Tue, 09/20/2016 - 08:35
One of the cool things that Europeans added to Judo is the belt system. Japanese are patient by nature, they either do or don't. In fact they distinguish only the black belt, you either have it or are progressing towards it. We need a bit more guidance to know we are on the right way,

Making Conversational Interfaces Easier to Build

Google Code Blog - Mon, 09/19/2016 - 21:30
Posted by Scott Huffman, VP of Engineering

We have been investing in the core machine learning technologies that enable natural language interfaces for years. To continue that investment, we’re excited to welcome API.AI to Google!

API.AI has a proven track record for helping developers design, build and continuously improve their conversational interfaces. Over 60,000 developers are using API.AI to build conversational experiences, for environments such as Slack, Facebook Messenger and Kik, to name just a few. API.AI offers one of the leading conversational user interface platforms and they’ll help Google empower developers to continue building great natural language interfaces.

Stay tuned for more on details on integrations into Google. And if you’re already using API.AI, keep building your conversational interfaces and if you’re not, start today!

Categories: Programming