Skip to content

Companies

The Objective of Time-Boxing

NetObjectives - Sun, 04/23/2017 - 14:22
This blog continues my series on Going Beyond Practices to Achieve Objectives   Timeboxing is used as a project planning technique. The schedule is divided into a number of separate time periods (timeboxes), with each part having its own deliverables, deadline and budget. In Agile, these time boxes are known as “iterations” (XP and generic Agile) or “sprints” (Scrum). The deliverables of each...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

Values, Practices and Principles Are Not Enough

NetObjectives - Sun, 04/23/2017 - 14:12
Agile has been around for over 2 decades now. Most every method talks about values, principles and practices. The Agile Manifesto, for example, is comprised of 4 values and 12 principles. XP, Scrum, Kanban, SAFe, LeSS and Nexus have added a considerable number of principles and practices as well. However, there has been little discussion of the laws of software development and insufficient...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

The Question Isn’t” Scrum Vs Kanban?” or Even “Scrum and Kanban?” But Rather “What Works?”

NetObjectives - Fri, 04/21/2017 - 19:11
If you find this topic interesting, check out our webinar Blending Kanban and Scrum Or What to do When Neither Kanban or Scrum Is Optimal Executive Summary We should not be debating whether Scrum or Kanban is better.  Both have practices and principles to offer.  Each has a different mindset towards learning, however.  But instead of just blending them, we should look to a mindset that embraces...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

GitKraken v2.4

About SCRUM - Hamid Shojaee Axosoft - Wed, 04/19/2017 - 22:14

In GitKraken version 2.4, substantial improvements have been made to lots of actions you perform every day. You know those little quirks in GitKraken that sometimes made you say an expletive out loud? It turns out that one of our own, Dan Suceava, regularly swears at his monitor, oftentimes with GitKraken being the recipient of his wrath.

Who is this Dan Suceava?

Hmm, where should we begin…. You don’t know Dan, but you probably use his deftly-coded API regularly. Dan is the VP of Engineering here at Axosoft and has been with the company for more than 11 years. Even though he’s not an active GitKraken developer, his work touches all aspects of Axosoft as a company. You could say that a piece of Dan goes into every release—but that’s a somewhat disturbing thought!

Anyways, what does he actually do, you might also ask? This question is harder to answer. All we know is, he turns up to work, and then, later, he leaves. Between his comings and goings, Dan enjoys saying “no,” a lot, he swears at his computer, and he drinks more Jack Daniel’s than any mortal man should. A sort of engineering equivalent to a Boo Radley–Sasquatch hybrid; he sits in a dark corner of one of our dev rooms, only to be rarely spotted in the kitchen. Some say he eats squirrels. Some say he uses Windows ME. But one thing no-one disputes is that Dan is a coding powerhouse. Much of Axosoft’s success can be attributed directly to Dan!

A rare sighting of Suceava outside of his natural habitat

So when it became apparent that one of Dan’s favorite products, GitKraken, is also the recipient of some of his curse words, the GitKraken team wanted to make things right. As a tribute to Dan, the GitKraken team is dedicating a release (or two) to fixing the issues that made Dan go through his stockpile of Jack Daniel’s at twice the rate he normally would. After getting a demo of his issues with GitKraken, the team realized these issues are going to make a lot of people (except for Jack Daniel) very happy.

Suceava updates
  • Before: GitKraken would dismiss 99.7% of issues as “user error,” muttering profanities under its breath.
  • Now: GitKraken is polite as can be, updating submodules correctly when switching branches, and initializing them faster (and recursively, if a submodule has submodules).
  • Before: When refreshing, there was a 90% chance that GitKraken DSRC either shrugged or barked “NO!” The other 10% of the time, the app took 3 days to complete the action.
  • Now: Commit sorting algorithm improvements mean the app is faster when refreshing.
  • Before: The app got drunk and forgot where it was, randomly disappearing only to reappear several hours later.
  • Now: the app remembers whether or not it was in full-screen mode when shut down, and the location of its Window. It will restore these settings when restarted.
  • Before: Checking out a remote branch beyond the graph history made the app highly irritable, giving the message “I should have started a farm,” and then accusing you of user error.
  • Now: Checking out a branch beyond 2,000 commits creates a local ref and checks out the branch, error-free.

This release includes 15 more bug fixes and other improvements. See the release notes for all the details.

P.S. Release notes can be translated from English to Suceava—enjoy!

Categories: Companies

Axosoft v17.1: Burndown Chart Update

About SCRUM - Hamid Shojaee Axosoft - Tue, 04/18/2017 - 22:59

In Axosoft v17.1, we made a small adjustment to the way burndowns work, which should provide more accurate velocities for our users. Prior to v17.1, velocity was strictly based on the number of hours that were entered using work logs. This was great for the apple polishers that entered all of their work logs at the end of the day, for all items, without exception—but it lead to a lot of confusion for teams that weren’t adding work logs for all of their items (or any of their items).

We heard your protests about not having to add work logs for every single item, and we’ve accepted your peace offering of a Pepsi can to free you from the oppression of work logs.

pepsi commercial

Too soon? Sorry.

Burndown Velocity Update

Prior to this release, teams that used story points for estimation had burndowns that were often nonsensical—or that disappeared because work logs didn’t often make sense when completed work was estimated in points. The one behavior that changed in this release is decreasing an item’s remaining estimate manually, or by setting the item to `completed`. Axosoft will now update the burndown velocity as you’re getting work done.

For example, let’s say you have a bug fix that is estimated to be 4 hours worth of work, and you move the item to ‘completed’ without adding a work log. Previously, Axosoft would update all of the data points in the burndown and subtract 4 hours worth of work, as if the item was never in the release.

Prior to v17.1: burndown prior to v17.1 4 hours of work removed from all days. (First day goes from 164 down to 160 hours.)

Now, moving an item with 4 hours of work remaining to ‘completed’, will only subtract the 4 hours from the current day, and the work you completed will be reflected in the velocity.

After v17.1: burndown after v17.1 4 hours removed only from today. (First day remains at original value.) What you can expect with this change

Because Axosoft was previously only using logged work for velocity, you may notice that your velocity is now greater than it was for any previous sprint. This should be a more accurate representation of the rate at which your team is getting work done because Axosoft is now taking into account all the work you’ve completed for your items.

For more details about Axosoft burndown charts and velocity calculations, check out our support documentation.

Categories: Companies

Visual Report Improvements

TargetProcess - Edge of Chaos Blog - Tue, 04/18/2017 - 09:33
Period scale for date axis

Dates are scaled as continuous axes by default. Sometimes there is a need to use periodic scales for dates. You can now switch scale type from field popup.

2017-04-13-15-40-23

Legend

Legend filtering has been improved. Now, several categories in the legend can be selected and changes will be reflected on the chart.

2017-04-13-15-24-42

 

Tooltip

The mechanics of tooltip have been improved. Projection to axis was added for stacked bars and areas to see the total value of the stacked items.

2017-04-13-15-33-27

We will really appreciate your feedback on our reports editor. What do you like about it? What could be improved? Let us know what you think at ux@targetprocess.com

Categories: Companies

Learning Git with GitKraken: Rebasing in GitKraken vs CLI

About SCRUM - Hamid Shojaee Axosoft - Tue, 04/18/2017 - 01:00

In these videos, Brett Goldman compares the experience of performing a very basic rebase in the CLI vs GitKraken, followed by a demonstration of what happens, and what to do, when conflicts occur. Take a look and subscribe to our YouTube channel for more videos about learning Git with GitKraken.

Categories: Companies

Blog Series: TDD and Process, Part 4

NetObjectives - Mon, 04/17/2017 - 14:16
Part 4: Redundancy In part 3, we examined how the same specification can be bound to the production system in different ways, producing executable tests that have various levels of granularity and speed, by creating different bindings for different purposes.  We started with the “full stack” binding: Next, we created a different binding that avoided accessing the database at all by mocking...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

Targetprocess v.3.11.1: add/edit permissions separated, expand all in List views

TargetProcess - Edge of Chaos Blog - Mon, 04/17/2017 - 08:59
'Expand All' in List views

You can now expand and collapse all of the first and second List hierarchy levels. If you hold Ctrl (Cmd) and click '>' then cards from both levels will be expanded. This works for the first two hierarchy levels of a List view and doesn't affect the third level of cards in terms of List setup.

Permissions to create users through the API for non-admins

Previously, only admin users could post Rest API requests to create and delete users. Now, non-admin users with 'add user' / 'delete user' permissions can create/delete users via API calls.

Add and edit permissions separated for user roles

Starting with v.3.11.1, user roles have separate permissions for adding and editing.

screen-shot-2017-04-11-at-3-32-00-pm

Request email notifications settings updated with "Requesters" check-box

You can set up a 'Request' workflow so that requesters get email notifications every time a specific event event occurs.

screen-shot-2017-04-11-at-4-29-23-pm

Visual Encoding improvements

It’s possible to create a predefined set of global Visual Encoding rules that can be applied to all views and all users. To do this, simply select the corresponding checkbox in the Visual Encoding tab and add the global rules that you want applied to every view in the system:

ve-global2

This setting can only be managed by Administrators; other users can see it in read-only mode.

Fixed Bugs
  • Visual studio add-in supports VS2015 now
  • It wasn't possible to delete a test plan if it had test cases that were run already
  • Fixed occasional improper results when searching by ID in a Relations tab
  • Fixed Project-Team assigments for Observer users according to their permissions.
  • Obsolete Tp.v2 option 'Show in lists/enable for filtering' removed from custom fields setup
  • Fixed User Story progress calculation when converting a Task with time records into a User Story
Categories: Companies

Introducing Axosoft Version 17.1

About SCRUM - Hamid Shojaee Axosoft - Fri, 04/14/2017 - 16:00

Some software releases have big, visual changes that you see the very moment you open the app. Version 17.0 of Axosoft was one of those big ones, with a huge visual overhaul that tidied up the UI, and big improvements to the user experience.

However, version bumps are also often cause for a large amount of development work being applied to complex solutions that are designed to be, at the front end, almost invisible. These feature sets are in place to remove friction, make you notice the app less, and so you can spend less time doing things.

Axosoft version 17.1 is one such release. In this release, not only have we fixed a bunch of smaller issues that some users on previous versions were experiencing, but we’ve continued the tradition of introducing subtle, elegant solutions to “quality of life” issues that have, until now, made certain repeated tasks less efficient than they could have been.

Version 17.1 has several marked interaction improvements that will soon become so commonplace in your day-to-day use of Axosoft, you’ll forget they’re there at all. So, what’s new?

Fuzzy Finding Duplicates Before You Duplicate Them

Collaborating on projects and releases can create duplication. For example, more than one person might create a task that has been discussed communally. In an effort to reduce the likelihood of the same item being created twice, Axosoft now has a fuzzy finder style drop down to show you existing items in your account that match or share similar names to the item name you are typing.

You can still create the new item as you did before, but if you happen to notice an existing item that you’d like to view or edit, simply select it from the drop-down. Cutting down on duplicated items means less confusion across your team.

Renaming Email Accounts

A lot of users have requested the ability to rename email accounts to something a little more friendly than ihatejira4353234@hotmail.com.

As an admin, simply go to Manage Account > Other Settings > Email Accounts. Open the account whose name you wish to change, and in Account Settings, use the Account Name field to edit the name to whatever you want. Simple!

You Literally Come First

When editing the Assigned To field, there’s a fairly good chance you’ll want to assign yourself to that item, so that’s a pretty reasonable default, right? When creating an item in v17.1, you will now appear at the top of the list of users. Typing another name will narrow down the options as before.

Other Improvements Reports

When exporting a report, you can now include a new field: Parent Item. This allows you to see more easily where sub-items sit in your projects.

Email

In your email lists, you can now filter by emails that are auto-reply emails. Simply click the gear icon in the top-right of the email list, and then select Email > Is Auto Reply filter.

You can also now view the size of attachments for an email, so you know just how large they are.

We hope you enjoy using these new features in version 17.1. As always, this release brings a bunch of other improvements and fixes to the app, and you can see the full list in the 17.1 version history.

Categories: Companies

Deprecating the old Help Desk portal

TargetProcess - Edge of Chaos Blog - Tue, 04/11/2017 - 22:21

We released our Help Desk portal back in 2008. It was a great software that allowed external users to submit requests. Years passed, and it became more and more obsolete from both the technical and user perspectives. Rather than wade through technical debt to try and improve it, we released a separate Service Desk application that already has all the functionality of Help Desk, a better UI, and some cool new features such as custom fields and request types.

We probably should have dropped the old Help Desk back in December 2016, when Service Desk was officially out of beta. It's hard to do, since we sort of got attached to it over the years. Nothing lasts forever though, especially in the software business, so it's time to let it go. Apart from the infrastructure costs of hosting both versions of the software, we also have to maintain and update it to keep up with the latest changes in Targetprocess. For example, in our latest release (v.3.11.0) there were some changes to the way user information is stored, and the 'Forgot Password' button stopped working in Help Desk.

We cannot afford to lose focus at this point, so we are freezing the Help Desk and will completely remove it from our On-Demand servers on June 1st, 2017. What does this mean for you? Most likely, nothing new. If you're not using request management, or if you're already using Service Desk, you don't have to do anything. In case you're not sure, here's what Service Desk looks like:

service_desk_plan

If you are still using Help Desk, that means you will have to switch to Service Desk. All you need to do is activate it at Settings -> Service Desk, and all of your requests and projects will automatically transfer over. On-Premises customers can technically continue using the old Help Desk, though we do not see any good reason for it.

We hope you enjoy the new version of the software. If you have any reason you prefer the old one, please let us know.

Farewell, Help Desk. It's time to move on.

Categories: Companies

Reduxifying GitKraken

About SCRUM - Hamid Shojaee Axosoft - Tue, 04/11/2017 - 16:59

GitKraken is a React app. We’ve been using React since version 0.12.2 (in January of 2015) when we migrated from Angular.js. When we started using React, we architected with the flux library from Facebook as our state model and forged ahead into glory. At first, it was good. Much performance. Many code. Wow!

The initial excitement subsided, and the honeymoon was over. We looked back at our strange mess of state and decided to make a move to Redux. It’s fair to say we had problems scaling with Flux.

The GitKraken team is now finishing up the transition from Flux to Redux, and everything is looking really amazing. There are already a lot of benefits that we are seeing from Redux as we write new code for the application.

Redux vs Flux

For those unfamiliar with Redux, but familiar with Flux, you can think of Redux as a stricter implementation of Flux. Instead of multiple stores and a dispatcher to bind all of the stores together, there is one store that holds all of the state in the application.

For those unfamiliar with both libraries, the Flux library is the implementation of the Flux pattern. The Flux pattern is similar to Model View Controller (MVC), but has a strict one-way data flow constraint.

Flux pattern

At each step in the flow, data is limited to only one movement direction. A view can start an action at the request of a user, the action can generate new data and pass it to the dispatcher, the dispatcher dispatches the results of actions to the stores, and the stores can then emit an update to the views.

In the Redux library, we’ve reduced our total store count to one, and thus we don’t need a dispatcher at all. The dispatcher was originally there to manage the order in which we update stores with action results and keep the stores behaving. Instead, we just directly inform the Redux store of an action that has occurred. So we’ve kept the basic premise of the Flux pattern, but shrank the pattern’s flow by combining the dispatcher and the store.

Redux state

Since we only have one store now, my first reaction was that the store would be a monolithic hellspawn of a maintenance issue, but we actually keep some semblance of order by using Redux’s reducer pattern for our separating concerns. The main mechanism for Redux is the reducer pattern; we have one top level reducer, and we can branch substate trees into smaller reducers.

A reducer is a pure function of state and message to state. We take the previous state tree, a message, and apply some transformation of the state to produce a new state tree. The top level reducer has this shape, and any subreducers also have this shape.

The process of reducing utilizes a constraint we place on the Redux state, that it is immutable. When a message is passed into Redux land, the message is passed through a series of these reducers. Those reducers then decide whether or not to perform an update according to the message.

In our case, the reducers decide whether or not to produce a brand new object. To clarify, we update every reference along a path to an updated value, such that we have made no mutations to the previous state tree. When our reducers produce a brand new object, we know that changes happened to that particular substate tree. In fact, we can trace the new object references to the exact set of changes that have taken place between the previous state and the next state.

Benefits of Redux

What makes this transition so nice to work with is that exactly one message changes state at a time in a very consistent and straightforward manner (a → b). It might seem a bit daunting at first to hoist all state of the app into a single state tree, but the benefits are an amazing trade-off.

Things like time travel can be implemented in a trivial fashion (just store the sequence of state updates). Holding all state in an immutable data structure also allows React to, erm, react better! We can utilize referential transparency when the Redux store emits a change. React can perform a check before updating to see if the top level object reference has changed, and it if hasn’t, shortcircuit the entire rendering tree.

Another nice benefit of the pattern we build with Redux comes into play when we organize our view around our Redux state. We build containers which listen to Redux state, and when a state update occurs, those containers retrieve the relevant changes and choose whether or not to react. Those containers pass any state they care about to a presentation layer. These layers are largely stateless view components (components that only receive props).

Ok! Ok. The benefit I’m describing is that the view layer scales horizontally by top level containers, which hold onto a pure render tree. When we want to add more containers, we can do it in a clean manner (a container is responsible for a full view), even though every container talks to the same store. We’ve basically built an architecture that adds one connection per new UI container when scaling. That’s really clean!

That’s not the only place we scale better. The Redux state itself scales per reducer. We can grow the size of the total state by building new reducers with their own substate, but we don’t have to increase the complexity of already written reducers, nor do we have to manage an explicit dispatch order like we did in Flux. There’s only one store, and our reducers run synchronously, producing a new state one message at a time.

Scaling example

So there you have it. We have an architecture that now provides a cleaner scaling experience in GitKraken.

Categories: Companies

Blog Series: TDD and Process, Part 3

NetObjectives - Thu, 04/06/2017 - 11:52
Part 3: Reusing the Specification I’ve said that notion of automation should follow the TDD specification process, not lead it.  We choose the “test automation framework” (TAFW) based on the nature of our specification and how we have chosen to represent it to stakeholders. That said, once we have settled on a TAFW, we can then determine how best to use it to bind the specification to the...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

Axosoft Dev Talk: Practical Category Theory

About SCRUM - Hamid Shojaee Axosoft - Wed, 04/05/2017 - 17:37

It’s time for another video in our Axosoft Dev Talk series! In the first of two talks about Practical Category Theory, David Koontz explains Semigroups and Monoids. Watch this video to learn more, and don’t forget to subscribe to our YouTube channel for more videos about software development.

Could your Git client list be represented as the monoid ""? Maybe you should add GitKraken!

Categories: Companies

GitKraken v2.3

About SCRUM - Hamid Shojaee Axosoft - Tue, 04/04/2017 - 00:14

As you’re probably aware by now, we work hard to address the needs and requests of ye faithful users of your favorite Git client, GitKraken. Version 2.3 implements a widely requested feature that everyone here at Axosoft is excited to see in a release: Git hooks!

We’re aware that this has been a barrier that has prevented some users from being able to adopt GitKraken for use in their teams, where specific functionality during certain actions is an absolute necessity. With Git hooks support, we’re hoping that GitKraken now incorporates the best of both worlds: an intuitive and simple to use interface, with the super-user functionality of Git hooks.

What are Git hooks?

Well, a hook might be defined as a trigger. If you’re familiar with JavaScript, you’ve probably used hooks before, in the form of events. Event listeners can be set up to fire custom actions when certain events (e.g. click, ‘click’) occur. Those events might be considered “hooks,” since you’re ‘hooking’ into them to do what you need to do.

WordPress users might also be familiar with hooks in the context of action hooks. At certain points in a page or post being rendered, various actions are fired off, into which the programmer can hook custom functions to work with the information at hand at that point in the rendering process.

Git hooks are very similar. They allow a user to create custom scripts that fire off at certain points during Git processes. GitKraken does not require that you install Git on your system, so until now, that independence had meant no Git hooks support. But, with a lot of blood, sweat and tears, v2.3 allows you to hook your way to a bounty of control over your Git actions!

Watch this short video to learn about Git hooks, and to see how Git hooks work in GitKraken.

What hooks are supported by GitKraken?

Beneath each hook is a list of the actions during which GitKraken calls that hook:

  • pre-commit:
    • Commit
    • Amend
    • Merge Resolve
  • prepare-commit-msg:
    • Commit
    • Amend
    • Cherrypick
    • Merge
    • Squash
    • Revert
  • commit-msg:
    • Commit
    • Amend
    • Merge Resolve
  • post-commit:
    • Commit
    • Amend
    • Cherrypick
    • Merge Resolve
    • Revert
  • pre-rebase:
    • Rebase
    • Squash
  • post-checkout:
    • Checkout
    • Discard Changes (selectively)
  • post-merge:
    • Merge (Without Conflicts)
    • Fast-Forward
  • post-rewrite:
    • Amend
    • Squash
    • Rebase
  • pre-push:
    • Push Branch
    • Push Tag
    • Delete Remote Branch
    • Delete Remote Tag

So that’s Git hooks. We hope you enjoy getting your tentacles all up in our actions!

Regional Date Settings

Another widely-requested feature has been the ability to set region-specific display dates for commits. Y’all might not be from these here parts and might have some region-specific ways of presenting your dates. Viewing another format can be jarring and counter-productive when you’re trying to decipher dates at-a-glance.

Well, guess what? GitKraken will now think to itself, where am I? and will update its date format accordingly, based on your system locale. You’re welcome! De rien! Bitte schön! De nada! Don’t mention it! Pip pip! As you were.

New Onboarding Experience

It’s now easier than ever before to get the rest of your team set up in GitKraken. V2.3 introduces a brand new onboarding screen for first-time users. It’s easier to see where to set preferences and start working with repos. It also introduces users to our Intro to GitKraken video which gives a quick 90-second overview of GitKraken’s functionality, our support site which provides lots of helpful documentation, and the GitKraken Slack Community where our users come together to help each other and help our team improve GitKraken.

But, there is just one more thing…

Try GitKraken Pro for free

If you’ve been wanting to try out GitKraken Pro features—like the merge conflict output editor, multiple profiles for work and personal use, or GitHub Enterprise integration—nows your chance!

Start a free GitKraken Pro trial by simply clicking the 

button in-app. You’ll be able to test these awesome features for up to 14 days before deciding if you want to upgrade to a paid account!

Categories: Companies

Introducing GitKraken Walk-In Stores

About SCRUM - Hamid Shojaee Axosoft - Sat, 04/01/2017 - 15:00
We were just kidding!

Of course we were! But it’s definitely no joke that we’re still offering GitKraken as a handy download you don’t need 50 diskettes to install.

We’re incredibly excited to reveal that, beginning Q1 2018, we will be offering a brand new way to get your hands on GitKraken: through a physical version of the app purchasable at actual walk-in stores!

For almost 2 years now, we’ve been offering a Git GUI – GitKraken, that we’ve constantly been updating and improving because we’re determined to provide you with the most luxurious Git client imaginable. Part of that luxury has always been about the UX. What are the fundamental UI traits that transpose to actual, physical actions that in turn make for a more efficient, simplified and robust experience for the end user?

In addition to the development of the app itself, we felt there was something missing from the way in which we provided GitKraken to our users.

Until now, our flow has been:

  1. Go to the GitKraken website
  2. Download GitKraken
  3. Install GitKraken
  4. Use GitKraken

Sound familiar? Of course, it does. It’s literally what almost every software company has you do. It’s standard and mediocre. It champions supposed ‘efficiency’ over the experience of luxury. But what do users actually want?

We needed some sound data to help us strategize. We sampled 5 members of the public, over the age of 80 years old, and asked them 4 simple questions:

  1. Is internet security important to you, or is it the most important thing in your life?
  2. Would you rather obtain and install a Git GUI client online or face-to-face?
  3. Tabs or spaces?
  4. If you were to install and configure a Git GUI on your Linux distribution, would you need expert help?

The results were pretty conclusive:

We convened a strategy meeting in which all stakeholders almost unanimously agreed that some sort of physical presence was missing from GitKraken’s marketing mix, and a casual mention of brick-and-mortar stores quickly escalated into animated discussion.

We looked at other companies who offer tangible experiences as part of their marketing and purchasing funnel. Apple was, of course, the first company who sprang to mind, and Hamid Shojaee, VP of Product, tasked himself with revising GitKraken’s roadmap accordingly. It wasn’t long before he had drawn up some compelling arguments, impressively articulated:

We quickly had an agreed plan in process, including architectural experts who would help us design the GitKraken Stores not only to look great but also to stimulate conversations among fellow Git users browsing the store.

Artist mockup of the first GitKraken store, opening Q1 2018. The entrance can be seen between the glass doors. At the back of the store is a large monitor to display visual items, and headphones are available to listen to music on iPods.

The aim of this venture is to provide a literal one-stop shop for you to purchase GitKraken (and install in-store, if you wish). The convenient and highly portable diskette format for the app will mean you can take GitKraken anywhere with you, even without wifi.

Perhaps you’re camping at a California state park. With your boxed copy of the app, you’re only ever one step away from installing GitKraken. On vacation at a hotel? You can install GitKraken on any hotel PC that has a 5.25 microfloppy drive. It really is that simple.

Here’s to the next exciting adventure!

Categories: Companies

Blog Series: TDD and Process, Part 2

NetObjectives - Fri, 03/31/2017 - 14:57
Part 2: Basic (A)TDD Automation In part 1 we expressed a view that many people hold when it comes to the various kinds of tests that we write in a process that centers on Test-Driven Development: “Your tests can either provide you a great deal of value and precise information when they fail, or they can be more broadly useful to the organization when they are passing (when they accurately...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

Recorded Webinar: Q1 Product Update, 2017

TargetProcess - Edge of Chaos Blog - Thu, 03/30/2017 - 20:01

On March 15, we held our quarterly Product Update Webinar. Our Product Specialists went over the latest features in Targetprocess, and covered some of our upcoming plans.  You can watch the webinar recording here: https://attendee.gotowebinar.com/recording/1773514835961965063

New features and enhancements:

  • My recent items & browsing history
  • Metrics
  • Connectors for integrating Targetprocess with ALM tools such as Atlassian JIRA, Microsoft TFS,CA Agile Central, and DevOps tools such as Git, GitHub, Jenkins and many others
  • Contributor user type
  • Improved Project-Team Selector for users, teams and projects
  • Lane suggestions
  • Service desk improvements
  • iOS & Android app improvements

Upcoming improvements (version 3.11.0 is now available):

  • Multiple final states (3.11.0)
  • Mention of teams (3.11.0)
  • Context improvement (3.11.0)
  • Settings remake (3.11.0)
  • Split of add/edit permissions
  • Undelete entity
  • Search improvements

Our team also answered questions from attendees throughout the webinar. Some of the more common questions have been listed with their answers below:

Q: Hi, thank you for the new github integration. Does the new integration also allow syncing from comments in both directions? Also, is it possible to create github issues via targetprocess?

A: Yes, it allows you to sync comments. Yes, it's also possible to create Github issues via Targetprocess.

 

Q: Can a metric or Calculated field now refer to the parent name? Ie, can a feature have a field that will contain the name of the Epic that contains the feature?

A: Hi, yes, you can do this with both - Calculated Custom Fields as well as with metrics

 

Q: Hi, is there a way to show total effort spent for tasks in a user story?

A: Hi! Yes. It is possible. In the User Story, you have a row which shows you the sum Effort of Tasks. For spent effort, you can use Calculated Custom Fields.

 

Q: My thought about multiple final states is: Hurra!!!

A: We're happy you like this update!

Categories: Companies

Performance Problems and Solutions in React.js

About SCRUM - Hamid Shojaee Axosoft - Thu, 03/30/2017 - 15:55
This is part 1 of a 4-part series!

This post is the first in a 4-part series looking at the performance issues that GitKraken developers faced. This post outlines the problems themselves, and subsequent posts in the series will focus on how the solutions to each problem were developed.

Part 1: The Problems

It may sound obvious, but in order to improve an app, you have to identify the pain points and precisely what is causing them.

A major issue we noticed in GitKraken was that the more a repository grew, the more everything slowed down. There were some tools we used to get more specific with what was at the root of such performance degradation; such as the Chrome dev tools in Electron, which contain a profiler that’s handy for giving you an idea of where you’re spending most of your time.

A profile of an action in GitKraken

After some investigation, it was clear that the app was spending an unwelcome amount of time tied up in React processes, frequently rendering and updating. Thankfully, React has its own tools for discovering performance issues, so we were able to move over to that to get more granular with the issues. It turned out that most of the expended time was in the graph, and that most of it was what we in the software development industry like to call wasted time. Wasted time is probably exactly what you expect it is–it’s time spent in processes that weren’t required in the first place.

In the context of React, the process was to go through a whole render cycle comprised of pulling new data, updating components, rendering, and constructing a virtual DOM. In the end, you compare the actual DOM to the virtual DOM, and you may conclude that the two DOMs are the same. That’s wasted time because no actual DOM updates needed to happen, and you just performed a bunch of work for nothing. Nothing!

This scenario was starting to creep up into seconds of wasted time. A couple wasted seconds might not seem like very much, but in Computerland, seconds of wasted time is comparable to watching season 5 of Lost: it might seem like there’s a point to it, and you’ve come this far so you kind of need to see it through to completion, but in reality it’s taking an excruciating amount of time, becoming increasingly irritating and turns out to be a genuinely bad user experience.

Yikes.

Anyways… The point is, at this time, every action in GitKraken would cause graph renders. That’s every action, even if no refs changed (for example, if a new PR came through, or one of the timelines on the graph updated), a whole graph refresh would still be performed. The subsequent frequency of repository refreshes, alongside the graph rendering process itself being slow, made the whole app feel slow.

Attempted Solution #1: Unmounting the graph

We tried to remedy this by unmounting the graph as something was loading. So, during that process, the whole graph component would be removed from React. That increased how fast the repository would load, but as a result, the amount of special-case application of this method would make the app code far more complicated and less sustainable long-term.

Attempted Solution #2: Flux implementation and Immutable.js

In our Flux implementation at the time, we had a store for each domain, and as a domain was updated, that update would cause a refresh of the graph. But, if you had a big refresh coming through, with multiple domain updates, you’d get a cascading effect of a graph refresh being calculated with every one of those domain updates. To put that into an actual use-case context, refreshing a repository would essentially result in around 8 graph rerenders, producing significant performance consequences in the app.

How so? A quick background about how Flux operates: There is a dispatch of data, and that dispatch goes from store to store, updating things as it goes. Each store—if its data changes—emits an event saying that some data has changed. React then responds to this event, grabbing the new data from the store and performing a render process.

This is all well and good, but the kicker here is that no subsequent store would update until that render process was fully resolved. So, for a single dispatch of data that updated multiple stores, this chaining effect would get costly. This was a fundamental bottleneck in our implementation of Flux.

This performance hit was compounded by the rendering process itself. When you grabbed new data from the store, the store would give you a deep copy of the data rather than its actual original data, to protect that original data from any mutations that may be caused by naïvely-written React components. We’ve since repented for our sins and now follow the one true path.

This deep copying proved to be expensive. When a component would get that data copy, it would perform a deep comparison between that data (copied from the store) and the data it already had, to ascertain if an update was necessary.

Though somewhat of a time-saver in the respect that it worked out whether or not an update needed to be performed, this check was in and of itself very expensive. However, this deep comparison was actually faster on average than just doing the update. All the rows (a commit in the graph would be considered a row), each made of multiple components and subcomponents, were causing multiple verifications that their data was the same. Faster, but still an expensive chain of events.

So, we decided to bring in a library called Immutable.js, which made immutable arrays and objects, allowing us to quickly compare if part of the object had changed because we could do a quick memory address comparison to see if that changed. Although this helped, it was extremely unwieldy to get shoehorned into our existing infrastructure without breaking ‘a lot of stuff’, and (you guessed it!) it was really slow to update objects. Even when batching updates using the built-in methods. This made our updates to the data actually take longer than the renders, so we had to ditch using Immutable as a solution. Womp womp.

Attempted Solution #3 (Bonus Fail): PureScript

We tried migrating lots of stuff over to PureScript. However, once we got started, we soon realized that this wasn’t going to be the right fit for our team.

So, by this point, we had established 3 solid areas that were pain points, causing performance issues that we needed to remedy:

  1. How we modified the state of the application with new data that came through.
  2. Retrieving data out of stores.
  3. Determining how to update components in the UI in as fast and efficient a way as possible.

These were the main 3 points that each required significant rethinking in how we were building the app.

The next 3 parts of this blog post series will focus on each of these issues respectively, the solutions we implemented, and how we implemented them. Subscribe to our blog to get the next 3 parts delivered to your inbox!

Categories: Companies

4 Things You Must Do At Scale

NetObjectives - Tue, 03/28/2017 - 08:36
This blog covers some of the ideas in the first session of our upcoming webinar series on Tuning SAFe. It's actually an adaptation of our Lean-Agile experience into the SAFe model so it will be useful for anyone attempting or doing Agile at scale. The first session, called 'Rationale of SAFe', discusses the four key elements of an Agile transformation. These four issues must be dealt with...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies