Monthly Archives: September 2015

When you add an existing Google or Box file, we copy it into your Kerika folders

Technology, Usability,

If you use the “file picker” that’s built into Kerika to add an existing Google Drive or Box file to a card, canvas or board — for a Task Board, Scrum Board or Whiteboard — you will see a message that says the file is being copied.

This is the file picker:

File picker
File picker

Clicking on the File Picker button brings up the File Picker dialog:

Using the Box file picker
Using the Box file picker

And this is the “copying…” message that’s shown.

Copying message
Copying message

So, what’s happening?

Well, Kerika stores all your Kerika-related files in a set of special folders within your Google Drive or Box account, if you are using Kerika+Google or Kerika+Box, and these are organized neatly into folders corresponding to each of your boards.

Here’s what the folders in your Box account look like (you can learn more by reading about how Kerika integrates with Box):

It’s a similar structure if you are using Kerika with Google:

Keeping all the Kerika files together in a set of related folders makes things cleaner for you: when you look at your Google Drive or Box Account, you know exactly what’s being used by Kerika, and what’s other stuff.

And this is why we make a copy of your existing Google Drive or Box file when you use the File Picker: it enables us to put a copy into your Kerika-specific folders, where it is easier to share with the rest of your project team.

Leaving chat, and then returning

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

When you are writing a chat message, on a card or canvas on any Kerika Task Board, Scrum Board or Whiteboard, what happens if you need to leave that message in the middle and go look at something else in Kerika?

For example, suppose you are in the middle of writing a chat message, but in order to complete it, you need to go off and look at another card’s details, or maybe a file attached somewhere else on the board?

You can leave aside a chat in mid-stream, go somewhere else in Kerika, return to the chat, and pick up where you left off!

That’s because Kerika uses your browser’s local cache storage to keep your unsent message: it means your changes aren’t lost while you go look at something else in Kerika.

This is a handy usability fix we have always had in Kerika, but it may be one that folks didn’t realize existed…

Well, now you know :-)

Kerika is now a Box Pro Partner

Kerika,

We are pleased to announce that our technical collaboration with Box continues, and Kerika has now been named a “Box Pro Partner” reflecting the strong ties we have built between the two companies as we continue to integrate with Box’s cloud services :-)

Box Pro Partner
Box Pro Partner

Kerika is now a Box Pro Partner

Kerika,

We are pleased to announce that our technical collaboration with Box continues, and Kerika has now been named a “Box Pro Partner” reflecting the strong ties we have built between the two companies as we continue to integrate with Box’s cloud services :-)

Box Pro Partner
Box Pro Partner

Kerika is now a Box Pro Partner

Kerika,

We are pleased to announce that our technical collaboration with Box continues, and Kerika has now been named a “Box Pro Partner” reflecting the strong ties we have built between the two companies as we continue to integrate with Box’s cloud services :-)

Box Pro Partner
Box Pro Partner

Amazon burped a little on the weekend

Kerika, Technology,

We use a number of Amazon Web Services, including one called Simple Queue Service which Kerika uses to handle communications between our main project database server and a separate server that handles the Search function.

  • As with all search engines, Kerika’s Solr engine does a full indexing of the database only once: when the database is rebuilt for any reason (which happens very rarely), and after that it does incremental indexing which means that it only looks at changes made to individual boards, cards, and canvases.
  • Using a queue helps us manage the load of traffic going to the search engine server: in the unlikely event that a lot of people make a lot of updates to their Kerika boards at the same time, Solr won’t get overwhelmed with a sudden burst of new indexing.
  • There are lots of ways to implement queues in software — in fact, studying queuing theory is a standard course in all computer science programs — and at this point most apps, like Kerika, prefer not re-invent that particular wheel: instead, it is more cost-effective to use some standard queuing facility that’s available as part of the underlying platform.

AWS works very well in our opinion — it has very high reliability across most of its services — but like all software, it isn’t entirely infallible.

Over the weekend we observed a small handful of errors in our services logs where it looked like SQS had a temporary problem.

We cross-checked this time period with other activity on Kerika, and determined that about 7 Kerika boards may have been affected: not in terms of any data loss or corruption on the board itself, but in terms of some changes not being updated in the search index.

Now, 7 boards is a tiny portion of the entire Kerika project database, which numbers in the hundreds of thousands of boards, but we are glad to have spotted the potential for trouble and have re-indexed the data on these particular boards.

If we did our job well, no one will notice.

Amazon burped a little on the weekend

Kerika, Technology,

We use a number of Amazon Web Services, including one called Simple Queue Service which Kerika uses to handle communications between our main project database server and a separate server that handles the Search function.

  • As with all search engines, Kerika’s Solr engine does a full indexing of the database only once: when the database is rebuilt for any reason (which happens very rarely), and after that it does incremental indexing which means that it only looks at changes made to individual boards, cards, and canvases.
  • Using a queue helps us manage the load of traffic going to the search engine server: in the unlikely event that a lot of people make a lot of updates to their Kerika boards at the same time, Solr won’t get overwhelmed with a sudden burst of new indexing.
  • There are lots of ways to implement queues in software — in fact, studying queuing theory is a standard course in all computer science programs — and at this point most apps, like Kerika, prefer not re-invent that particular wheel: instead, it is more cost-effective to use some standard queuing facility that’s available as part of the underlying platform.

AWS works very well in our opinion — it has very high reliability across most of its services — but like all software, it isn’t entirely infallible.

Over the weekend we observed a small handful of errors in our services logs where it looked like SQS had a temporary problem.

We cross-checked this time period with other activity on Kerika, and determined that about 7 Kerika boards may have been affected: not in terms of any data loss or corruption on the board itself, but in terms of some changes not being updated in the search index.

Now, 7 boards is a tiny portion of the entire Kerika project database, which numbers in the hundreds of thousands of boards, but we are glad to have spotted the potential for trouble and have re-indexed the data on these particular boards.

If we did our job well, no one will notice.

Amazon burped a little on the weekend

Kerika, Technology,

We use a number of Amazon Web Services, including one called Simple Queue Service which Kerika uses to handle communications between our main project database server and a separate server that handles the Search function.

  • As with all search engines, Kerika’s Solr engine does a full indexing of the database only once: when the database is rebuilt for any reason (which happens very rarely), and after that it does incremental indexing which means that it only looks at changes made to individual boards, cards, and canvases.
  • Using a queue helps us manage the load of traffic going to the search engine server: in the unlikely event that a lot of people make a lot of updates to their Kerika boards at the same time, Solr won’t get overwhelmed with a sudden burst of new indexing.
  • There are lots of ways to implement queues in software — in fact, studying queuing theory is a standard course in all computer science programs — and at this point most apps, like Kerika, prefer not re-invent that particular wheel: instead, it is more cost-effective to use some standard queuing facility that’s available as part of the underlying platform.

AWS works very well in our opinion — it has very high reliability across most of its services — but like all software, it isn’t entirely infallible.

Over the weekend we observed a small handful of errors in our services logs where it looked like SQS had a temporary problem.

We cross-checked this time period with other activity on Kerika, and determined that about 7 Kerika boards may have been affected: not in terms of any data loss or corruption on the board itself, but in terms of some changes not being updated in the search index.

Now, 7 boards is a tiny portion of the entire Kerika project database, which numbers in the hundreds of thousands of boards, but we are glad to have spotted the potential for trouble and have re-indexed the data on these particular boards.

If we did our job well, no one will notice.