The Case of the Disappearing Slack Notifications

We happened to notice that slack messages that we were used to getting were no longer showing up. This is a walk through of how they were setup, what we figured out, and what our next steps are.

Getting an app to send slack notifications

To start with you need to configure an Incoming Webhook, the essence of which involves:

• creating a Slack app
• getting the app approved
• enabling Incoming Webhooks
• then add a webhook by specifying a channel messages are sent to

Next you need to have your app generate a JSON message and post it to the url provided by the webhook. Then, violá, you have a notification in slack from your application.

So why did we stop getting some of our notifications?

We noticed that we no longer were getting notifications when some of or processes failed. We'd get success messages, so we knew some notifications were working fine, just not some of the failures.

What happens when a message is sent to a non-existant webhook?

It seems that slack has several error response. This doesn't help much if the apps aren't expecting this. So this is one thing to improve, but why would a webhook that was working start returning "no_service"?

We have had changes on the team and one notification was put together by an intern working on our team who's account was recently deactivated...

So what happens when your account is deactivated?

Slack provides some details on this, with a small teasing statement:

Apps the members set up may be disabled. You can manage and re-enable these apps if you'd like to reconnect them.

Following the link in that statement, but isn't as precise as we'd like:

...some apps they've installed (whether third-party or custom) will automatically disable. Some features remain active (bot users, slash commands, incoming webhooks, etc.), but apps that require member-specific permissions will disable entriely.

Finally, after a bit more digging some details were found in the Installing apps section of Managing Slack apps. Under the "A pleasant vacation from unexpected uninstallation" it notes how apps will not be automatically uninstalled if they limit their scope, but then it mentions a caveat:

One caveat: this exception doesn't apply to the folks who created an app or were added as an App Collaborator. When they leave, the app is still uninstalled.

So that explains why our notifications went away. Though I'm not sure how to avoid or alert on that.

Maybe collaborators?

My first thought was adding other team members to the collaborators so that more people could do the work, but the previous section implies that it might also delete it. Regardless, that's a stop gap at best.

Maybe notification on deletion?

I'm not sure who manages removing slack users, but I'm curious if it is possible to notify their former team of the apps that will be deactivated?

At least, Admins and Owners of our slack Workspace are able to reenable apps that have been deacivated.  So if we remember who set it up or to ask if anything recently got deactivated after someone has left..

Next steps

1. Improve the error handling when posting a slack message.
2. Add alerting if our apps cannot post a slack message (not just a log message).
3. Follow up with Slack Workspace Admins / Management on:
   
   1. If they can find apps owned by deactivated users
      
      • Unfortunately, they can only see the list of deactivated apps in chronological order.
   2. If we can get notified of apps that were deactivated when an account is inactivated.
      
      • The Slack Admins weren't aware of this process so more digging needs to happen to figure this out.
   3. Also worth asking these questions of Slack if I can find out where to ask them. 

Rearranging Desk to Change Behavior

Recently a coworker made the suggestion that while we talk a lot on our team we could do better.  Sometimes don’t pair as much as we could and end up working in silos.

So he took a look at desk arrangements that were suggested for pairing and proposed arranging our desks in a square.  The purpose be to help with conversations with the people on either side of you.  We talked about it some and there was some concerns with foot room and if we’d be looking at each other, but in the end we all felt it would be worth trying.

So we moved our desks to this:

One of the other things we wanted to explore is a way to pair without needing to bring my laptop and chair around the desks and throw away our ergonomics.  I’d used screenhero in the past, which allowed for sharing the mice and keyboard on shared screens.  Turns out join.me, which is provided for us by our company, has that exact feature.  So we’re hoping to pair using this as a way to help increase communication even while we’re in the same room.

We’re still new to this arrangement, but so far I’ve noticed a distinct improvement in my ability to hear everyone else.

We've made use of join.me a couple times, but getting into isn't as quick or seamless as we'd like.

Concerned with HIP sprints

During our planning I very often hear maintenance or architecture work come up and immediately be deferred with "that's a HIP sprint item."  Ultimately this feels like a cop out.  Granted that's not what the Scaled Agile Framework (SAFe) is going for with it's advocation of them.  It seems more of a place for preparing for a release and dealing with those things that can't be done before hand.

Granted my company is mostly focused on updates to existing applications and adding features to them.  (That's not to say that new things are being developed, just that the number of brand new things is less than existing.)  So while we'll occasionally have those items it seems that should be some stories in your iteration instead of the focus of an entire iteration.  Though even if it took over an iteration - does it need a special name?

I guess it's making me think this is a situation that some teams have found themselves in where they need a HIP sprint and it's being generalized as a rule to help protect others.  In the end I feel it flies in the face of sustainable pace since it gives a dumping ground for things that should be done in each sprint.  Granted we're supposed to have a mix of these items in each sprint already, but it seems the HIP sprint provides the illusion of a crutch to fall back on.  (To be sure - there's some coaching that is needed to ensure that we're not too focused on product development with no regard for keeping the system working.) 

I'm certainly giving short shrift to a topic that has had some thoughtful discussion, but it's something that's currently on my mind.

Fumbling at Finding things with Selenium

Finding things with Selenium

At it's root this is easy enough.  Just call findElement() on the driver and give it some matching - we've been using css selector - and viola.  Then I wanted it to be visible - so just call .isDisplayed() on the element, but I kept getting false.

I should note that I was adding this to some functional tests being run against our hybrid mobile application.  So I could track down the css styles viewing it in a browser I'm not sure how to map the Selenium element I'm getting in our tests to the same thing.  (Any pointers would be appreciated. :))  This left me fumbling around wondering why I wasn't matching what I was seeing in the browser.

Then I thought to search for the css selector I was matching on and realized there were two of them on the page and that I need to add another part to the selector.  Not one of my proudest moments - I'd like to blame that I'm not always/often working with css and it takes a bit for my brain to get into debugging when it doesn't work off the bat.

Vagrant

So I had hoped to dig more into vagrant...and I sort of did.  I touched base with our systems team since they use puppet and I was hoping to make use of what they did to quicken things up.  Turns out they use vagrant to test out their puppet scripts, but they don't have access that they'd like to share...yet.  I'm hoping to keep poking at that and get an appropriate access created!

Exploring vagrant and volunteering

Exploring Vagrant

Recently I listened to Ruby Rogues podcast where they chat with Mitchell Hashimoto, the creator of vagrant.  Which I'm sad to say that while I've heard of it I haven't dug into at all.  (This even came up during a hackathon at my company, but I was working on something else.)

We have a dependency on another project that's fairly complex to setup and run locally.  Recently there's been some work done to puppet-ize the setup of the servers for standing up new servers.  Looking through the vagrant docs it seems that it would be easy to make use of that.  Along with the ability to control multiple boxes it seems like it should be easy to setup.  I'm looking forward to exploring this more next week.

Volunteering with Vermont Works for Women

I had the pleasure of TAing during one of the Step Up to IT classes.  It was awesome to see the enthusiasm and drive of all the attendees.  I've certainly been getting more interest in mentoring these past couple years and this was a great day for me.  I'm TAing for two other classes coming up and look forward to see how things progress.

Random Star Trek Bonus

I recently became aware of Star Trek Continues.  I'm still trying to determine how much I like it, but it certainly gets high marks for it stay true to the original series.  The first three episodes they have out are enjoyable.  Needless to say I'm keeping my eye on their latest "Kirkstarter" while I figure out if and how much I should donate. :)

Moving to Rally

Recently my company, in an effort to increase visibility of work and help organize things, has transitioned from Jira to Rally.  Not unsurprisingly we're dealing with learning how to use the new system and the differences between them.  My team likes the flexibility of being remote - at times we've had half the team working remotely - so we don't have a physical board and are keeping things all in the tool.

Here are some of the issues we're having that we have yet to find a work around:

1. Handle unfinished work from an iteration
   
   Rally gives some advice around this, but nothing that just works.  Some options and their downsides:
   
   
   1. Move the story to the new iteration.  You lose sight that it was in a previous iteration so the planned points goes down.
   2. Split the story - which by default creates a second story with the same number of points in the upcoming iteration.  Unfortunately, if you're doing any reporting like the release burnup, then this gets a double shot of points from this one story.  The suggestion in this case is to zero out the points for the left over work, which of course changes the points planned in the last sprint. 
   
   Nothing provides a solution that maintains both the closed iterations planned and actual points as well as the release burnup.
   
2. Starting and stopping an iteration
   
   It doesn't appear to allow any flexibility in the time an iteration is to close - so midnight on the day indicated is when it happens.  Historically, my team has closed the sprint after daily standup (which we do at 10:15) on the day we're planning our iterations.  Which immediately afterward we do our planning for the next iteration.  Since it's all automatic, we'd have to close things up the night before so that any reports look reasonable and aren't missing our last morning of work.  This just seems too rigid and I'm not sure what the benefit is versus our being able to indicate we're done with the iteration.
   
3. Identify what stories/features are being released
   
   Rally has introduced milestones that seemed to be a perfect fit for this.  These can be applied to portfolio items and stories.  However, I have yet to find a way to view everything it has been applied to in one view.  So while I add the milestone to everything I can't a view that will show everything that's going out in the release.
   
   Some of this I'd take as a challenge to avoid working on things that aren't going to get released, but I've learned that reality gets in the way.  So it's not impossible to figure out what's getting released I just prefer indicating it as soon as I know and having a single place where people can look at it.

Some things we've found work arounds for that we're not really satisfied about:

1. Unable to view defects on Task Board view
   
   I've honestly found Defects to be next to useless.  Maybe they work better with the test plans, but they behave differently than tasks and stories.  In the end they are work that needs to get done, but they don't work well with the rest of the system.  So this is just the biggest annoyance with them.  The Task Board view is how we do our day to day work, but defects created under a story don't show up along with the tasks on the story.
   
   Our work around for this is to stop creating defects.  This means we can't report out on things we consider defects in our own work as easily, but we'll see about figuring that out when we get a chance.
   
2. A couple of good views to work with
   
   It seems like every view is not quite all there.  You can do 90% of what you expect, but not everything.  For instance, the Task Board is great for updating tasks and progressing them.  However, viewing the parent story and adding new tasks is awkward.  The Iteration Planning view is good for putting stories into iterations and adding tasks.  However, viewing the story is awkward since it takes over the view and when you come back your location on the page is lost.
   
   Our work around for this is to open stories in a new tab.  Jira certainly isn't perfect, but I really appreciated it's plan and work views that seemed to really focus on the purposed for those views - also it's opening selected items in a sidebar view.

It's not without cause that many coaches advise finding you're own flow to things and keeping tools out of the mix as long as you can.  Because of our desire to work remotely and not wanting duplicate entry of stuff (as in update what we're using and keeping the central tool matched) we're continuing to work inside the tool.  I'm concerned with wanting to keep reporting in Rally with some of these concerns.

Appium - iOS and Android webview context

I encountered another thing I wasn't expecting with Appium related to the webview context.  For iOS the context was WEBVIEW_1, but for Android it was WEBVIEW_.  I'll confess to not having dug into the context very much and how and why it might be named.  However, I was expecting them to have the same name.  So instead of just calling AppiumDriver.context("WEBVIEW_1") I ended up looping through the available contexts and finding one that starts with "WEBVIEW" and selecting that one.