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

R: ggplot2 – Each group consist of only one observation. Do you need to adjust the group aesthetic?

Mark Needham - Fri, 01/30/2015 - 01:27

I’ve been playing around with some weather data over the last couple of days which I aggregated down to the average temperature per month over the last 4 years and stored in a CSV file.

This is what the file looks like:

$ cat /tmp/averageTemperatureByMonth.csv
"month","aveTemperature"
"January",6.02684563758389
"February",5.89380530973451
"March",7.54838709677419
"April",10.875
"May",13.3064516129032
"June",15.9666666666667
"July",18.8387096774194
"August",18.3709677419355
"September",16.2583333333333
"October",13.4596774193548
"November",9.19166666666667
"December",7.01612903225806

I wanted to create a simple line chart which would show the months of the year in ascending order with the appropriate temperature.

My first attempt was the following:

df = read.csv("/tmp/averageTemperatureByMonth.csv")
df$month = factor(df$month, month.name)
 
ggplot(aes(x = month, y = aveTemperature), data = df) + 
  geom_line( ) + 
  ggtitle("Temperature by month")

which resulted in the following error:

geom_path: Each group consist of only one observation. Do you need to adjust the group aesthetic?

My understanding is that the points don’t get joined up by default because the variable on the x axis is not a continuous one but rather a factor variable.

One way to work around this problem is to make it numeric, like so:

ggplot(aes(x = as.numeric(month), y = aveTemperature), data = df) + 
  geom_line( ) + 
  ggtitle("Temperature by month")

which results in the following chart:

2015 01 30 00 25 18

This isn’t bad but it’d be much nicer if we could have the month names along the bottom instead.

It turns out we can but we need to specify a group that each point belongs to. ggplot will then connects points which belong to the same group.

In this case we don’t really have one so we’ll define a dummy one instead:

ggplot(aes(x = month, y = aveTemperature, group=1), data = df) + 
  geom_line( ) + 
  ggtitle("Temperature by month")

And now we get the visualisation we want:

2015 01 29 23 28 23

Categories: Programming

3 P’s of Agile Centers of Excellence

photo

An Agile center of excellence (ACoE) provides support and energy to an Agile transformation within an organization. It supports through leadership, evangelization, best practices, research, support and/or training for agile and lean ideas. ACoE’s support can be categorized in three inter-related areas. These areas, the three “P’s,” are people, process and project.

People are the heart and soul of any development process. As we have noted, Agile has an enormous focus on people (remember the Agile value of valuing people over process). The ACoE provides support to people though bringing new ideas into the organization, by providing coaching, developing coaches and acting as change agents.

Agile is a set of processes, or sets of steps taken to achieve a specific end. A recipe is a process, as is a daily stand-up meeting or checking code in and out of configuration management tool. The ACoE supports Agile processes by capturing process, identifying and fostering the use of relevant metrics (collection and reporting are typically PMO functions – to be discussed in the near future), facilitating communities of practices and providing tools.

Projects are the currency of most IT organizations. At its simplest a project is an enterprise with a start and end that is organized to deliver a result. ACoEs support the performance of Agile teams at a project-level as coaches. Coaches are folks who deliver help to teams, stakeholders and other leaders within an organization so they learn how to be Agile. At the project-level, coaches help teams use and tweak processes to meet the team’s needs, provide training and support for tools and processes and help the team learn how to ask the hard questions about how the team is using Agile.

The primary goal of the ACoE is to provide practitioners with the tools, techniques and capabilities they need to be Agile. By helping teams perform, the ACoE also helps sell and maintain the Agile transformation. Both of these goals begin as an organization starts a transformation to Agile and continue to be important as teams evolve and continuously improve. The ACoE delivers value by addressing the three Ps. For example, through the role of coaching and by facilitating communities of practice, the ACoE helps to promote an environment where there is consistency of practice and where innovation can happen. While the combination of innovation and consistency might sound contradictory, coaches often act as an Agile Johnny Appleseed. ACoE coaches see how teams work, the changes that have made to the processes and why those changes were made. The ACoE can then help to spread ideas that prove to be valuable through coaching, referrals or discussion in communities of practice.


Categories: Process Management

Estimating is Risk Management

Herding Cats - Glen Alleman - Thu, 01/29/2015 - 18:06

Risk Management is about many things - but it is first and foremost about estimating future outcomes. 

Suppose one of you wants to build a tower. Will he not first sit down and estimate the cost to see if he has enough money to complete it? For if he lays the foundation and is not able to finish it, everyone who sees it will ridicule him saying, "This fellow began to build and was not able to finish." - Luke 14:28-30

To manage the risk of not enough money, not enough time, the probability of unacceptable outcomes we need to estimate. It's as simple as that and as complex as that.

Risk management is essential for development and production of products and services because key information about cost schedule, and technical performance are uncertain and many times unknown until later in the project.

Proceeding to spend other peoples money in the presence of these uncertainties is not only bad management, it's bad economics - the microeconomics of decision making requires estimating the impacts of any decision - the opportunity cost of that decision.

Risk management is concerned with the outcome of future events, whose exact outcome is unknown, and with how to deal with these uncertainties as a range of possible outcomes. - Effective Risk Management: Some Keys to Success, 2nd Edition, Edmund H. Conrow.

So when you here we can make decisions about the future without estimating ask yourself, did that speaker ever read about risk management. And as Tim Lister says

Risk Management is How Adults Manage Projects

Related articles Probability and Statistics of Project Work Qualitative Risk Management and Quantitative Risk Management Decision Making in the Presence of Uncertainty All The World's A Random Process Your Project Needs a Budget and Other Things
Categories: Project Management

Some Personal Questions About Programming

Making the Complex Simple - John Sonmez - Thu, 01/29/2015 - 16:00

In this video, I answer some questions from Pluralsight about my career and my views on programming.

The post Some Personal Questions About Programming appeared first on Simple Programmer.

Categories: Programming

What Development & Test Managers do in Agile Organizations

Is there room for functional managers, such as development and test managers, in agile organizations? Maybe. It depends on whether they take the role of an agile manager.

If you have organized as a feature teams-based organization, the functional managers (development, test, analysis, whatever) can take these responsibilities:

  • Develop trusting relationships with the people on the project team, and in their function.
  • Provide coaching and mentoring opportunities for people.
  • Provide communities of practice for the people.
  • Remove obstacles for the people and team.
  • Start and nurture the hiring effort whenever you need to hire new people.
  • Help people with career development.
  • Provide feedback to people, and help people learn how to provide feedback (meta-feedback).
  • Provide coaching and meta-coaching when people want it.
  • Help the organization understand its capacity and make decisions about the project portfolio.
  • Help influence the rest of the organization with the agile culture.

Functional managers are champions for the team, and shepherds for the process. They are servant leaders.

Here’s what functional managers do not do:

  • Have status conversations. If the team is agile, the team understands its status. If you need help seeing their board, that’s a problem the team needs to solve. If they need help seeing their status, they need to change their board or their process for updating each other.
  • Move people on or off teams, once you or the team establishes itself.
  • Ask people to do something the team has not committed to, or that the product owner has not added to the kanban board. That’s right. “Your” team doesn’t work for you; the team works for the product owner.
  • Micromanage any part of the project work. Or, manage any part of the project work.

What does this mean? It means that the team members are leaders. Agile pushes responsibility into the teams, and away from traditional management. Agile requires leadership at all levels.

Agile challenges managers to recreate their jobs. An agile transformation requires managers work in an agile way, and work differently than before.

If you want to learn more about the role of leaders and managers in agile, join Gil Broza and me at The Influential Agile Leader, either in San Francisco or London this year. We still have an early bird price until mid-February. Don’t miss this opportunity to help your agile transition and your career.

Categories: Project Management

Live Webinar with JetBrains: Software Architecture as Code

Coding the Architecture - Simon Brown - Thu, 01/29/2015 - 14:17

I'm doing a live and free webinar with Trisha Gee and the other fine people over at JetBrains on February 12th at 15:00 GMT. The topic is "software architecture as code" and I'll be talking about/showing how you can create a software architecture model in code, rather than drawing static diagrams in tools such as Microsoft Visio.

Over the past few years, I've been distilling software architecture down to its essence, helping organisations adopt a lightweight style of software architecture that complements agile approaches. This includes doing "just enough" up front design to understand the significant structural elements of the software, some lightweight sketches to communicate that vision to the team, identifying the highest priority risks and mitigating them with concrete experiments. Software architecture is inherently about technical leadership, stacking the odds of success in your favour and ensuring that everybody is heading in the same direction.

But it's 2015 and, with so much technology at our disposal, we're still manually drawing software architecture diagrams in tools like Microsoft Visio. Furthermore, these diagrams often don't reflect the implementation in code, and vice versa. This session will look at why this happens and how to resolve the conflict between software architecture and code through the use of architecturally-evident coding styles and the representation of software architecture models as code.

Please sign-up here if you'd like to join us.

Categories: Architecture

Join Me on My Private Virtual Street Team in February!

NOOP.NL - Jurgen Appelo - Thu, 01/29/2015 - 09:26
Michal Moitk

Do you want to join me on my Virtual Street Team in February?

As my Virtual Street Team member you get:

Exclusive access to me via a private channel
Several exclusive on-line chats with me
A free Kindle or ePub copy of the #Workout book
Free signed copies of the book and my previous two books

The post Join Me on My Private Virtual Street Team in February! appeared first on NOOP.NL.

Categories: Project Management

Instagram Strategy to Radically Reduce Traffic: Kill all the spambots!

RIP to my fallen robot followers on Instagram, if there's a heaven for robot instagram users, you guys are in there

— alldaychubbyboy (@Allday)

How do you scale to handle increased user traffic? Have less traffic. No, this is not a koan. The best way to deal with traffic is not to have it. 

In a two day span Instagram disappeared 18.9 million users or more than 29 percent of their "followers." Justin Bieber lost 3.5 million followers (15 percent), Kim Kardashian lost 1.3 million followers (5.5 percent), Rihanna lost 1.2 million followers.

Instagram explains this dramatic reckoning was achieved by "removing deactivated spam accounts and accounts that violated its community guidelines." 

In an age when high user counts and tantalizing engagement metrics are more valuable than bitcoins, this can't have been an easy decision, but it was made after being bought by Facebook.

Why? Gabe Madway, an Instagram spokesman, tells us why: We totally get that it’s uncomfortable for people. The overall goal is we want it to be perceived that the people following you are real.

Uncomfortable is an understatement. A BuzzFeed article nicely captured some of the anger, here's just one example (could be NSFW):

Categories: Architecture

Building the Perfect Schedule

Herding Cats - Glen Alleman - Wed, 01/28/2015 - 16:30

Plans are critical, a schedule to implement that plan comes next. With the Plan, the sequence of the work is needed to assure the value to the customer is delivered in the proper order. That order is an order because the business (or the mission) usually can't accept all the features and functions at once. So the Plan is the top level sequence, and the schedule is the next level down.

Building the perfect schedule (v6) from Glen Alleman Related articles Your Project Needs a Budget and Other Things Qualitative Risk Management and Quantitative Risk Management
Categories: Project Management

Don’t Let the Incompetent Keep You Waiting

NOOP.NL - Jurgen Appelo - Wed, 01/28/2015 - 16:20
clock

I don’t like it when people keep me waiting.

I reply to all emails within 24 hours. I pay my bills within two weeks, often within days. Last week, when one of my team members needed credit card information that I didn’t have with me, I did my best to send it within an hour. Web orders for my book? I validate shipping addresses within hours, and we send people’s orders within 48 hours. Invoices? I usually send them twice per month, or earlier when people ask for them.

The post Don’t Let the Incompetent Keep You Waiting appeared first on NOOP.NL.

Categories: Project Management

Testing on the Toilet: Change-Detector Tests Considered Harmful

Google Testing Blog - Wed, 01/28/2015 - 01:43
by Alex Eagle

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.


You have just finished refactoring some code without modifying its behavior. Then you run the tests before committing and… a bunch of unit tests are failing. While fixing the tests, you get a sense that you are wasting time by mechanically applying the same transformation to many tests. Maybe you introduced a parameter in a method, and now must update 100 callers of that method in tests to pass an empty string.

What does it look like to write tests mechanically? Here is an absurd but obvious way:
// Production code:
def abs(i: Int)
return (i < 0) ? i * -1 : i

// Test code:
for (line: String in File(prod_source).read_lines())
switch (line.number)
1: assert line.content equals def abs(i: Int)
2: assert line.content equals return (i < 0) ? i * -1 : i

That test is clearly not useful: it contains an exact copy of the code under test and acts like a checksum. A correct or incorrect program is equally likely to pass a test that is a derivative of the code under test. No one is really writing tests like that, but how different is it from this next example?
// Production code:
def process(w: Work)
firstPart.process(w)
secondPart.process(w)

// Test code:
part1 = mock(FirstPart)
part2 = mock(SecondPart)
w = Work()
Processor(part1, part2).process(w)
verify_in_order
was_called part1.process(w)
was_called part2.process(w)

It is tempting to write a test like this because it requires little thought and will run quickly. This is a change-detector test—it is a transformation of the same information in the code under test—and it breaks in response to any change to the production code, without verifying correct behavior of either the original or modified production code.

Change detectors provide negative value, since the tests do not catch any defects, and the added maintenance cost slows down development. These tests should be re-written or deleted.

Categories: Testing & QA

Two Factors Make Agile Centers of Excellence Different

Process or People Focused?

Process or People Focused?

 

An Agile center of excellence (ACoE) typically refers to a team that provides thought leadership to support or sustain the transformation to an agile organization. That can include providing leadership, evangelization, best practices, research, support and/or training for a focus area. An ACoE is similar to (but not the same as) engineering process groups (EPGs or SEPGs) that have been used to support and sustain organizational transformations such as the CMMI. The two most significant differences between SEPG/EPG and ACoE centers are the concept of controlling process and the ACoE’s focus on people. Groups like SEPGs and EPGs are primarily focused on implementing and controlling the process, even though most process improvement models understand the relationship between people, process and tools. Many SEPGs and EPGs views process as the most significant short-term variable. Processes could be changed, people trained to support the process and perhaps even new tools purchased to support the process, but the process was the driver.

The four values and 14 principles of the Agile Manifesto provide teams with a basis for self-organization and self-management. Agile techniques, such as retrospectives, provide a feedback loop that helps teams to regulate their performance by changing how they work. Both the manifesto and techniques create an expectation that teams will have some degree of control over how they work. This type of process self-determination is at odds with a group that defines, manages and controls a standard processes, even if that group listens to their customers which is exactly what most SEPGs and EPGs.  This type of behavior tends to depress innovation while fostering command and control management styles that are at odds with agile. An ACoE supports process innovation through coaching, collection and communication of best practices, and facilitating communities of practice.

ACoE typically have a people-first approach to fostering an agile transformation and then sustaining that transformation. As with process control, the Agile Manifesto and Agile techniques (including coaching) generate a natural focus on people. The general thought process is that if you influence people, behavior will follow. The alternate, process-focused perspective is that influencing process will influence behavior.  One of the four values in the Agile Manifesto states “we have come to value individuals and interactions over process and tools.” While that value does not say that we doe not value processes if does mean that to be truly agile we need to put people first.

All organizational transformation models recognize that people are an important component when generating change. Agile centers of excellence take a people-first approach that eschews the rigid process control of other transformation frameworks. ACoEs provide thought leadership and coaching to support teams.  Those team take the knowledge for the ACoE and use techniques like retrospectives to tune how they work. Team drive the improvements  in order to improve their performance. Earlier in my career I fell prey to the conceit that a methodologist could tell people how work (too many Industrial Engineering classes), but I learned later that a methodologist/coach needs to work with teams to unlock their potential by giving them the tools to decide how to work.


Categories: Process Management

Turning Editorials into Root Cause Analysis (Update)

Herding Cats - Glen Alleman - Tue, 01/27/2015 - 23:50

When we read about a big IT problem, like...

Screen Shot 2015-01-26 at 7.24.24 PM

The first impulse is to use this information to support some or other position, like here's an example of estimate driven bad management. Without the logical conclusion of finding the actual Root Cause of the problem, as shown in the IDA report. Other examples usually start with bogus Standish data. Take a look on page iv below to see the real root cause, and see if Not Estimating would have been able to address the issues with ECSS? Not likley. 

Screen Shot 2015-01-26 at 7.14.04 PM

This document seems to not load everytime, refresh the page if it doesn't

So we're back to the same place we always seem to come to. Domain and knowledge of the domain, before conjecturing any solution to any problem and the conjectured solution that occurs outside the domain of experience. 

For those not able to read the details here's a summary from the final section.

Screen Shot 2015-01-27 at 1.53.38 PM

The notion of some that "estimates" are the root cause of the problems and that making decision in the absence of Estimates is the solution to the problem based on un-informed opinion.

So down load the report, read it in it's entirety, then assess other opinions in the light of actually reading the Root Cause Analysis, then drawing conclusions from the actual data and its analysis by the professionals tasked by the sponsors of the RCA who are accountable for looking after the money and the measurable outcomes.

And then the quote that says it all...

"Everyone is entitled to his own opinion, but not his own facts." - Daniel Patrick Moynihan 

 

Related articles Taxonomy of Logical Fallacies
Categories: Project Management

Improvements in Xamarin.Forms 1.3

Eric.Weblog() - Eric Sink - Tue, 01/27/2015 - 19:00

Back in November I wrote a blog entry about performance problems resulting from the design of the layout system in Xamarin.Forms. I am pleased to report that things took a big step forward with the recent release of version 1.3.

Reviewing the problem

In a nutshell, the Layout classes do too much. They contain functionality to make sure everything gets updated whenever something changes. In principle, this is good, since we obviously don't want stale stuff on the screen. But in practice, there are many cases where the built-in update code ends up being slower than necessary.

For example, suppose I'm going to add ten child views to a layout. With the built-in update code, a layout cycle will get triggered ten times, once for each child view I add. Worse, if I'm trying to do any kind of subview recycling, the odds are high that I want to add a child view while I am processing a layout cycle. This will trigger a recursive layout cycle, resulting in the end of civilization as we know it.

Instead, what I want is one layout cycle which happens after all ten child views have been added.

The solution I proposed

IMHO, the best design for this kind of problem is to have multiple layers:

  • The Low-Level layer models child view relationships only. It provides a way for a View to be inside another View, but it doesn't give much more than that. In iOS terms, this is UIView.addSubView.

  • The High-Level layer (which is built on the functionality provided by the layers below it) has Views which actively manage their child views. In iOS terms, an example of this would be UICollectionView.

  • In the Middle, it would make sense to have a layer which provides things which are common to all (or nearly all) of the stuff in the High-Level layer, to avoid code duplication.

Xamarin.Forms has the High-Level layer and the Middle layer, but it does not have the Low-Level layer. So I proposed creating it.

I didn't get exactly what I wanted, but...

The solution in Xamarin.Forms 1.3

In Xamarin.Forms 1.3, the Middle layer is still the lowest thing we've got. However, there are new capabilities which allow the Middle layer to pretend like it is a Low-Level layer. It still has a bunch of built-in update code, but now that code can be turned off. :-)

The important new capabilities are:

  • ShouldInvalidateOnChildAdded
  • ShouldInvalidateOnChildRemoved
  • OnChildMeasureInvalidated

By returning false from my override of ShouldInvalidateOnChildAdded() and ShouldInvalidateOnChildRemoved(), I can have a Layout which doesn't do any automatic updates when I add or remove children.

And by overriding OnChildMeasureInvalidated(), I can have a Layout which refuses to do real estate negotiations with its child views.

This is good.

How I'm using this

Because of this new stuff, an upcoming release of our DataGrid component will be even faster. Our panel layout class will look something like this:

private class myLayout : Layout<View>
{
    Func<View,Rectangle> getBox;

    public myLayout(Func<View,Rectangle> f)
    {
        getBox = f;
    }

    public void LayoutOneChild(View v)
    {
        Rectangle r = getBox (v);
        v.Layout (r);
    }

    public void LayoutAllChildren()
    {
        foreach (View v in Children) {
            LayoutOneChild (v);
        }
    }

    protected override bool ShouldInvalidateOnChildAdded (View child)
    {
        return false; // stop pestering me
    }

    protected override bool ShouldInvalidateOnChildRemoved (View child)
    {
        return false; // go away and leave me alone
    }

    protected override void OnChildMeasureInvalidated ()
    {
        // I'm ignoring you.  You'll take whatever size I want to give
        // you.  And you'll like it.
    }

    protected override void LayoutChildren (double x, double y, double width, double height)
    {
        LayoutAllChildren ();
    }
}

This Layout class is obviously very simplistic, but it merely scratches the surface of what becomes possible now that Xamarin.Forms has [something that can imitate] a Low-Level subview layer.

Kudos and thanks to the Xamarin.Forms team!

 

How a Background in Science Will Prepare Me for a Career in Software Requirements. Part I: Requirements Analysis as a Practice in Reductionism

Software Requirements Blog - Seilevel.com - Tue, 01/27/2015 - 16:30
“Reductionism: The theory that every complex phenomenon … can be explained by analyzing the simplest, most basic physical mechanisms that are in operation during the phenomenon.” Think about any software product that you have ever used. For the most part, you care about the whole of the product, which is the collective effort of all […]
Categories: Requirements

Don&#8217;t Blindly Follow

Mike Cohn's Blog - Tue, 01/27/2015 - 15:00

Don't blindly adopt anything.

Scrum is comprised of a self-organizing team that is given a challenge, and to meet that challenge, works in short, time-boxed iterations during which they meet daily to quickly synchronize their efforts.

At the start of each iteration, they meet to plan what they will accomplish. At the end, they demonstrate what has been accomplished and reflect on how well they worked together to achieve it.

That's it. Anything else—release planning, burndowns, and so on, is optional. Stick to the above and find the local optimizations that fit your environment. No expert knows more about your company than you do.

Software Development Conferences Forecast January 2015

From the Editor of Methods & Tools - Tue, 01/27/2015 - 14:37
Here is a list of software development related conferences and events on Agile ( Scrum, Lean, Kanban), software testing and software quality, software architecture, programming (Java, .NET, JavaScript, Ruby, Python, PHP) and databases (NoSQL, MySQL, etc.) that will take place in the coming weeks and that have media partnerships with the Methods & Tools software development magazine. SPTechCon, February 8-11 2015, Austin, USA Use code SHAREPOINT for a $200 conference discount off the 3 and 4-day pass NorDevCon, February 27 2015, Norwich, UK Early birds tickets until February 13. QCon London, March 2-6 2015, London, ...

Android Wear & QR Code: Putting Users through the Fast Track

Android Developers Blog - Tue, 01/27/2015 - 13:18

Posted by Hoi Lam, Developer Advocate

Rushing onto a train, entering a concert, or simply ordering a coffee, we have all seen users (or ourselves) rummaging through their wallets or mobile app trying to get the right boarding pass, ticket or loyalty card. With Android Wear and a few lines of code in your mobile app, this can all work like magic.

What’s new in the Android Support Library

While QR Code images could be attached to a notification since the first release of the Android Wear platform, developers have asked about two situations which they would like to see improve:

  1. With circular displays, it is hard for developer to know if the QR code is displayed in it’s entirety and not cropped.
  2. To conserve battery, Android Wear switches off the screen after five seconds of inactivity. However, this makes it hard for the user to ensure that the QR code is still displayed on their wrist when they reach the front of the queue.

With the latest support library, we have added two additional methods to WearableExtender to give developers more control over how background images are displayed in notifications. These new APIs can be used in a number of scenarios, we will focus on the QR code use case in this post:

  • Ensure the image is not cropped - setHintAvoidBackgroundClipping(true)
  • With this new method, developers can ensure that the entire QR code is always visible. table, th, td { border: 1px solid black; border-collapse: collapse; } Wrong:
    setHintAvoidBackgroundClipping (false)
    // this is the Default Right:
    setHintAvoidBackgroundClipping (true)
  • Ensure the QR code is still displayed when the user gets to the front of the queue - setHintScreenTimeout(timeInMS)
  • This new method enables developers to set a timeout that makes sense for their specific use case.
Design Best Practices

We have experimented with a number of customization options with QR codes and here are some of the lessons learnt:

Dos
  • Do test with your equipment - Before deploying, test with your QR code readers to ensure that the QR code displayed on the wearable works with your equipment.
  • Do use black and white QR codes - This ensures maximum contrasts and makes it easier for the reader to read the information.
  • Do display only the core information in the text notification - Remember that less is more. Glanceability is important for wearables.
  • Do test with both round and square watches - The amount of text can be displayed on the notification varies especially dependent on the form factor (square and circular).
  • Do brand with icon - On the main notification in the Android Wear stream, developers can set a full color icon using setLargeIcon to brand your notification.
  • Do convey additional information using background - To achieve an even better result, consider setting context sensitive backgrounds through setBackground, such as a photo of the destination for the train or a picture of the stadium.
  • Do use QR codes which are 400x400 pixels or larger - In line with other background images, the recommended minimum size for QR code is 400x400 pixels.
Don'ts
  • Do not brand the QR code - The screen real estate is limited on Android Wear and using some of this for branding may result in the QR code not working correctly.
  • Do not use anything other than grey or default theme color for notification text - Although Android Wear notifications support basic text formatting such as setting text color, this should be used in moderation with the color set to default or grey. The reason is that the Holo theme for Android 4.x has a default background of black whereas Material Design theme for Android 5+ including Android Wear has a white background. This makes it hard for the colour to work for both themes. Bold and Italic are fine formatting choices.
Android Wear is for people on the move

Using QR codes on Android Wear is a very delightful experience. The information that the user needs is right on their wrist at the right time in the right place. With the new APIs, you can now unlock more doors than ever before and give users an easier time with check in on the go.

Sample code can be downloaded from this repository.

Join the discussion on

+Android Developers
Categories: Programming

I Curse My Customers

NOOP.NL - Jurgen Appelo - Tue, 01/27/2015 - 10:01
curse-my-customers

Let me tell you a little secret: Every now and then, I curse my customers. OK, it’s not really a secret, probably. I think the neighbors can hear it when I do. But that’s the way it is. I curse them.

I curse them because I care.

The post I Curse My Customers appeared first on NOOP.NL.

Categories: Project Management

Voxxed interview and 20% discount on my Parleys course

Coding the Architecture - Simon Brown - Mon, 01/26/2015 - 19:21

Voxxed have just published a short interview with me about software architecture, sketches, agile and my "Software Architecture for Developers" training course on Parleys where I answer the following questions:

  1. You're an independent consultant - have your experiences in this (sometimes challenging) field fed into your course?
  2. Who is your course aimed at? How experienced do people need to be?
  3. Do you think a good grasp of agile methodology is important for this course?
  4. Can you give us an example of the kind of sketch you'd use to visualize your architecture?
  5. What's wrong with many of the software architecture sketches that you see?
  6. Diagrams that don't reflect the code - why is this a problem?
  7. A recent article suggested young developers should avoid the agile manifesto - what's your take on this?

You can read the full interview on Voxxed and, this week, the first 100 people to sign-up to my Parleys course using this link will get a 20% discount.

Software Architecture for Developers

Categories: Architecture