Archive for September 2015

Let’s give a little background here… in our day-to-day activity, we sometimes struggle when we start a new project.

And from here to project failure it’s not a long way.

At Delivery Management we often hear that it’s too time-consuming to estimate a complete backlog and try to get an idea about the project size and that we should rather do just-in-time estimation and release planning.

So what can we do to answer the natural desire of our sponsors and different stakeholders to know more or less how big their project is and how to approach it? Well, for this we have the Affinity tool.

We thought to make an exercise. Let’s take one completely new application, gather a group of developers and see if we can actually achieve our goals by running an Affinity process.

First step was to find an app idea that was easy to grasp for everyone and write down the features. The appointed PO took his new role very seriously:

And the rest is history: we played the Product Owner and Scrum Master roles, several enthusiastic colleagues joined with their superskills and in less than 3 hours we had all the ingredients to properly start a new application:

– A common vision of the product and of the product roadmap as envisioned by our PO

– A decision on the technologies to be employed

– A sketch of the technical solution

– An estimated backlog (in SPs)

– A rough idea of how long the project will take, obtained with the Wideband Delphi technique

– The list of assumptions

– Some risks we could already foresee

– An idea on how to approach the project

– And last but not least… the eagerness to start, because everyone was already IN

It is a very powerful tool, 2h45min and we already knew so much about what it takes to build our app.

Agile promotes individuals and interactions so what better way to achieve great software than to bring people together since the very beginning, present them the vision and let them draw the solution?

The feedback was also positive, even if we were running a bit out of time at the end.

We’ll definitely do this workshop again (and adjust a bit the scope to match the proposed timeframe) so please stay tuned if you’ve missed the first one.

Or, if you want to try it in your upcoming project and need help setting things up, pay us a visit at the 14th floor.

Chrome DevTools is a popular tool for frontend debugging these days, with new features being added frequently. In this post we’ll go beyond the common patterns and highlight features that are perhaps less known, but useful nonetheless.

1. Get inspected element

There are a few situations where you would want to access the last inspected element (from the Elements panel):

– for quick debugging inside the console: the element can be accessed via the $0 global variable (see for yourself: console.log($0))

– for writing tests using Selenium: in Selenium you can locate the element on the page using its XPath, and luckily Chrome has an option (right click element in the Elements panel) to copy XPath

– to use in your JavaScript code: to access that element you can copy its CSS path (right click element in the Elements panel) first and then select it (via document.querySelector for example)

2. Console features beyond .log

– console.trace() prints a stack trace from the point of the method call (which is a less hacky way of doing console.log(new Error().stack)); this is useful for determining what part of the code is calling the current function for example

4. Store as global variable

When paused at a breakpoint we can inspect locally scoped objects in the console, but we might also want to keep track of them for later inspection as well. Instead of manually storing such an object as a global variable in the console, DevTools has a handy option to “Store as global variable” by right clicking on it in the Sources panel (Scopes section on the right).

5. Snippets

DevTools provides a “snippets” section within “Source” panel which allows us to manage a list of scripts that can be injected onto a page. These things can range from inject a script into a page to printing out cookies or event more complex tasks. The point of this feature is to allow code reusability during debugging without having to resort to other tricks (such as using bookmarks for example).

6. Replay Ajax requests

There are situations when Ajax requests return an unexpected result or even an error. For replicating the request one might think we need to click the button that triggered it (or replicate the series of actions that triggered it). Fortunately there’s an easier way with DevTools:

– an option is to open the Network panel, right click on the Ajax request and click ‘Replay XHR’

– another way of doing the same thing is to click on ‘Copy as cURL’ (again, Network panel > right click request) and run the command into the terminal

7. Toggle element state

There are other styles to be applied to an element besides that of its regular state. For example a button could look differently when hovering over it, the same way a visited link is diffent than a regular link. These special states are the following: active, hover, focus, visited.

You could manually trigger these states by yourself, but you wouldn’t be able to edit their styles in DevTools as well (once you’ll open DevTools the special state of the will be gone – except for visited links).

But lucky for us there are solutions to force an element’s state with DevTools:

– in the Elements panel you can right click on the element and select ‘Force Element State’, then choose the preffered state

– the second option would be to select the element from the Elements panel, then go to the ‘Styles’ section on the right and click on the ‘Toggle Element State’ icon (the 2nd one)

8. DOM breakpoints

Sometimes an element changes and we would like to determine what part of the code triggered that change. DOM breakpoints are a good fit for these kind of situations, since they can pause the execution whenever an element is removed, its attributes are changed or there are subtree modifications.

To add a breakpoint simply right click on an element (in the Elements panel), select Break on.. and check the situations where you want the breakpoint to be added to. Now when the DOM element is being changed the execution will be paused and you will see what caused the update in the Sources panel.

9. Test responsive design and bad connections

If you want to see how an application feels like on a smartphone with a bad connection, you don’t have to leave your browser. By clicking on the smartphone icon near the DevTools panels on the left side you enter the Device Mode. Here you will be able to setup the viewport to match known smartphones/tablets, as well as throttle the network connection to simulate bad connections.

10. Locate an element by its selector

Let’s assume that you are visiting a relatively big page and you’re looking for a specific element. You search through source code of the page and you find that element. For the sake of the argument we’ll say that it has an id named instructions.

The next step would be to go to the Console panel and paste the following code:

inspect(document.querySelector('#instructions'));

What’s going on here?

- document.querySelector() will return the DOM element

– the inspect(element) function will open the Elements panel and select the element

At this point you will be able to take a look at the element’s DOM structure, checkout its styles or inspect other stuff.

But we can achieve more than that, to actually have a look at the element on the page. To do that just right click on the element in the Elements panel and select ‘Scroll into view’. This will scroll to the element and highlight it, so mission acomplished.

Conclusion

While you might not need to master all DevTools features, it’s a good thing to be aware of these tricks. Who knows, maybe you’ll end up as those people using DevTools as their IDE.