Category Archives: Technology

Posts related to technology in general.

No, not Shellshocked

Kerika, Technology,

The announcement by CERT yesterday that there is a vulnerability in the Bourne Shell (more commonly known as “bash”) wasn’t great news for anyone running any variant of Unix, which includes Linux and MacOS.

Linux is very widely used for modern Web servers, particularly those running on Amazon Web Services — like Kerika does.

There are a number of variants of Linux out there, which makes things a little harder whenever a vulnerability is announced: you have to make sure your particular variant of Linux is patched quickly.

Luckily, this problem was fixed as fast as the notorious Heartbleed bug: within a couple of hours of the report of Shellshock, Amazon and Google (and, most likely, every other cloud services provider out there) started installing patches, and so the Software-as-a-Service (SaaS) world got back into good shape very quickly.

In our own case, we use Ubuntu Linux, and they were equally swift in issuing a patch for Shellshock which we installed yesterday.

On a side-note, we are less enthusiastic about Apple’s announcement that “the vast majority of users are not at risk“.

That’s true only in a literal sense: the vast majority of Mac users don’t ever use the Terminal program to access the shell, and a lot of permissions on Macs are locked down by default (and most users never bother exploring all their administrative privileges).

But, in a practical sense this bland statement from Apple understates the actual risk faced by Mac users: a significant majority of startups use Mac for their software development, which means a critical set of Mac users are still sitting exposed!

The sooner Apple fixes this bug, the better is will be for the startup world.

How to install Kerika on a Google Apps Domain

Kerika, Technology

Since our last released, when we upgraded our integration with Google Apps Marketplace to use the OAuth 2.0 protocol, a number of folks have written in to ask about how they should install and authorize Kerika for their premium Google domains (i.e. Google Apps for Business, Google Apps for Nonprofits, etc.)

Here’s a step-by-step guide for the Google Apps Administrator in your organization:

First, login to admin.google.com with your Google ID. Your screen will look like this:

Google Admin Console
Google Admin Console

On the right side of the screen, you will see a link for Google Apps Marketplace, in the area marked Tools:

Go to Google Apps Marketplace
Go to Google Apps Marketplace

When you click on the “Google Apps Marketplace” link, you will be presented with a search box that looks like this:

Searching for Kerika
Searching for Kerika

Type in “Kerika” in the search area, and you will find us!

Adding Kerika
Adding Kerika

Once Kerika shows up, click on the blue “Install App” button:

Installing Kerika
Installing Kerika

Click on the blue Continue button, and you will be asked to authorize Kerika for your Google Apps domain:

Authorizing Kerika
Authorizing Kerika

And that’s it! Your final confirmation message will show:

All Done
All Done

And at this point Kerika will have been authorized for your entire Google Apps domain. Individual users will be able to sign up without going through any of this hassle.

If you have any difficulties or questions with this, please email us at support@kerika.com

Google was flaky for 2 hours today!

Kerika, Technology

Between the hours of 9AM and 11AM PST, Google’s authentication service — which we used to sign in users of Kerika+Google — kept having problems that affected people at random.

It was a tough morning for us, dealing with the flood of “504 System Timeout” errors coming back from Google, and feeling helpless that we couldn’t provide the kind of high-quality user experience that is at the core of the Kerika brand.

The problems finally went away by themselves, but a total of 31 Kerika users were affected and we are reaching out to each of them individually to apologize for the inconvenience, and explain what happened.

This is one of those situations where Kerika cannot do anything to fix the problem: if you signed up as a Kerika+Google user, when you try to login to Kerika you are automatically redirected to Google’s authentication service, which then comes back to Kerika to give us your identity information.

Then, we use the identity information to log you into the correct Kerika account.

Normally, all this happens really fast: you click on the Sign In button at Kerika, Kerika redirects your browser to Google, Google responds immediately, and within a couple of seconds you are logged into Kerika.

It all happens so fast and smoothly, 99.999% of the time, that most people are completely unaware that their browser was even redirected to Google in the first place — it’s something you might notice only if you have a very slow WiFi connection, and you are paying close attention to your browser’s status bar.

But every once in a while, Google won’t respond when you get redirected there by Kerika. In that case we retry again several times, and then finally Kerika does a “timeout”: it gives up.

(This problem has happened before, and as software developers ourselves, we are, of course, very sympathetic to other software companies that experience occasional bugs and hiccups, but Google can be irksome in their lack of transparency.)

This happens so infrequently that we didn’t really have any special code in place to tell users why they were not able to login, but that’s going to change starting tomorrow: if Google’s servers are not responding fast enough, we will show a special page to the user explaining what’s happening, so they understand the situation better.

 

The new OAuth 2.0 integration with Google Apps

Technology

With our latest version, we will be using OAuth 2.0 uniformly across all the ways you could sign up for Kerika:

  • As a Google Apps for Business user, e.g. someone who has the premium (paid) version of Google Apps, and signs up at kerika.com or through the Google Apps Marketplace.
  • As a free or premium user of Box, who signs up at kerika.com or through the Box App Store.

Across all these, we are now using OAuth 2.0: the more modern, robust implementation of OAuth which lets you sign into Kerika using a Google or Box ID, without Kerika ever seeing your password!

(Background: while we were using OAuth 2.0 for people who signed up directly at Kerika.com, we had OAuth 1.0 in place for people who signed up through the Google Apps Marketplace, and we needed to make every pathway consistently work with OAuth 2.0 and completely get rid of OAuth 1.0)

This new version will affect all premium users of Google Apps:

With the old (OAuth 1.0) integration with Google, it was possible for individual users who had the premium version of Google Apps to sign up for Kerika.

With the new (OAuth 2.0) integration, the Google Apps Administrator for the domain (i.e. your company) to authorize Kerika for the entire domain.

In other words, if you are a premium user of Google Apps, your Google Apps Admin — typically someone in your IT department — will need to authorize Kerika for your domain before you can use Kerika.

This will affect you even if you are an existing user of Kerika.

The good news is that once your Google Apps Admin authorizes Kerika for your company’s domain, it won’t be necessary for individual users to authorize Kerika any more: it becomes much easier for your colleagues to sign up.

We should probably stop saying “unlimited cards”…

Kerika, Technology,

OK, so our website has long stressed the word “unlimited”, and maybe that’s not such a great idea…

Most people have boards with a few dozen cards.

Some folks have boards with a couple of hundred cards.

Very few people have boards with up to 1,000 cards.

It turned out that one of our users had a board with nearly 4,200 cards, of which over 4,000 were in the Trash.

And that’s not good! A board with several thousand cards on it is going to take a long time to load, because each card has many different attributes to it: details, chat, assignments, status, history, etc.

And when someone with a very large board uses Kerika, this can cause very unexpected loads on the servers, particularly in terms of network I/O and CPU utilization.

This is what it looks like when someone suddenly opens a board with thousands of cards on it:

CPU spikes
CPU spikes

We have talked about this before, and now we need to do something about it…

Most of the time, boards get very big because they are very old: stuff piles up in the Done column, or, as in this case, in the Trash column.

Having very large boards can impact performance: unlike, say, email which you may be accustomed to leaving piled up in your Inbox for years on end, Kerika’s cards are “live object”: even when a card is in the Done or Trash columns, it is constantly listening for updates from the server, because it could be moved out of Done or Trash at any time by someone on the team, or have some of it’s attributes changed.

For example, even though a card is “Done” or “Trashed”, it could have its details updated, or new chat added to it.

This is different from email messages, which are essentially “dead objects”: once you get an email and read it, it doesn’t update after that, so it can sit for years in your Inbox without trying to get fresh updates from the mail server.

So, when you have 4,200 cards on a single board, you have that many live objects trying to get updates from the server at the same time, and that’s not good for your browser or our server!

(Imagine your laptop trying to read and display 4,200 emails at the same time, and you will get an idea of the problem…)

Having very large boards is not a good idea from a workflow or process management perspective, and so perhaps Kerika needs to do something about it: we need to think about how we can help our users improve their workflow, while also avoiding these CPU spikes.

A couple of ideas that we are considering:

  • Start warning users when their boards are getting too big.
  • If boards hit some threshold values (which we have yet to figure out, maybe it’s 1,000 cards?) force the user to reconfigure their board so they don’t affect the quality of the service for everyone.

 

Project Info summary of your Kerika Board: a new Kerika feature

Agile & Scrum, Kanban & Lean, Technology, , ,

We are thrilled to announce a new feature in Kerika: a very useful Project Info display that summarizes of your project.

You can access this by clicking on the new Info button that appears in your Kerika toolbar, at the top-right corner of your board view:

Project Info display
Project Info display

This view is available to everyone who is part of the project team:  Project Leaders, Team Members and Visitors.

There are several sections in here: at the top is the Name and Description of the project:

Name and Description
Name and Description

The Description is a new attribute of Kerika’s boards: it lets you provide context about the project that can help orient new team members, and it can also help with your Searches in the future.

The Name and Description of a project can be modified at any time by Project Leader or Account Owner.

Next up is the Summary of the project:

Summary
Summary

The summary varies by the type of board (Whiteboards, Task Boards or Scrum Boards), but it provides useful information in all cases:

  • It tells you when the board was first created, and by whom.
  • It tells you when the board was last updated, and by whom.
  • And for Task Boards and Scrum Boards it tells you how many cards are done, and how many remain.

Since each card typically represents a work item, this is a quick way to find out how much work remains on a board, without having to count up all the cards in each column.

For Task Boards and Scrum Boards, this view also shows you how many cards are due today, due tomorrow, and overdue.

And for Scrum Boards, it shows you how many cards are in the Backlog that you are using, so you get a sense for how far along you are with the overall project, not just the current Sprint.

All Kerika Task Boards and Scrum Boards now have support for Work-In-Progress Limits: these can be turned on or off by the Project Leader or Account Owner:

Settings
Settings

Another huge new change: we are making it super easy to switch a board from being a Kanban Board to a Scrum Board, and back again.

Task Boards and Scrum Boards also have a new auto-numbering feature that can help you manage very large boards, e.g. if you are using Kerika for an internal Help Desk.

For both Tasks Boards and Scrum Boards, there is now a great new Export feature that lets you export cards from a board in CSV or HTML formats:

Export
Export

And, finally, you now have the option to make individual projects open to the public to view (but not change): a handy feature for open-source and volunteer-based projects like WIKISPEED:

Privacy
Privacy

Why we haven’t published our API (yet)

Kerika, Technology

We are sometimes asked (usually by our more techie users) whether Kerika has a published API.

The short answer is “No”; the longer answer is “Not yet.”

We do have a server API, of course, that the Kerika front-end client application itself uses, but it is a very proprietary and non-standard API at present.

This is largely because of an early decision we made to use CometD for our real-time client-server communications.

CometD is a form of a long-poll architecture, but our implementation, unfortunately, is not very standard, in part because we built an “API generator” a long time ago that allows us to create new APIs fairly quickly using metadata descriptions of the desired features.

This was helpful when we were first getting started, but, quite honestly, it isn’t an approach that makes a lot of sense any more and we have migrated away from using that API generator.

But, because of our history/legacy code, we currently have a mix of auto-generated APIs and newer API, and this isn’t really something that we want to publish and support for external third-party development.

We plan to redo our API this year to make it more standard and easier for third-party developers to use, at which point we will publish it and start encouraging more platform development around Kerika.

Using Kerika with Git

Kerika, Technology,

We often get asked if Kerika has an integration with Git.  The short answer is “No”, but the longer answer is more nuanced…

We use Git ourselves for managing our own source code and other software assets.

Git was designed from the git go (ha!) to be used by distributed teams, having originated with the Linux kernel team, perhaps the most important distributed team in the whole world, so it made perfect sense for us to use it: it works across operating systems, and a number of simple GUIs are now available for managing your various source-code branches.

We simply embed the git references within cards on our project boards: sometimes in the chat conversation attached to a card, but more often within the card’s details.

Here’s an actual example of a bug that we fixed recently:

Example of Git integration
Example of Git integration

We use multiple Git branches at the same time, because we put every individual feature into a separate branch.

That’s not a fixed rule within Git itself; it’s just our own team’s practice, since it makes it easier for us to stick with a 2-week Sprint cycle: at the end of every 2 weeks we can see which features are complete, and pull these git branches together to build a new release.

So while Kerika doesn’t have a direct integration with Git, it’s pretty easy to use Kerika alongside Git, or other source management systems.

 

True Tales from our Customers: Adding Kerika Spice to a presentation

Agile & Scrum, Kanban & Lean, Kerika, Technology, , , , ,

One of our users wrote in last night with this great story, which we wanted to share with you…

I did a one hour webinar for the software company (Software AG) that we develop all of our software with as they were impressed with the way we were using their software development environment (NaturalOne).

I threw a little Kerika spice into my presentation as it has become such an important part of our development environment and I actually used it to prepare my presentation.

Instead of preparing the presentation by myself I used a Kerika project and had my software developers contribute cards and instructions in the areas that they specialized.

While I was doing a live presentation I was referring to the cards on my other monitor and swiping them to the ‘Done’ column as I completed them.

I know you like to hear stories about how people use your software and this worked very well for this presentation.  It was recorded and I will send you a link to it once it is published.  It might put you to sleep at night, except for the Kerika part.