Skip to content

Feed aggregator

You should not be using WebComponents yet

Decaying Code - Maxime Rouiller - 10 min 21 sec ago

Have you read about WebComponents? It sounds like something that we all tried to achieve on the web since... well... a long time.

If you take a look at the specification, it's hosted on the W3C website. It smell like a real specification. It looks like a real specification.

The only issue is that Web Components is really four specifications. Let's take a look at all four of them.

Reviewing the specificationsHTML Templates

Specification

This specific specification is not part of the "Web components" section. It has been integrated in HTML5. Henceforth, this one is safe.

Custom Elements

Specification

This specification is for review and not for implementation!

Alright no let's not touch this yet.

Shadow DOM

Specification

This specification is for review and not for implementation!

Wow. Okay so this is out of the window too.

HTML Imports

Specification

This one is still a working draft so it hasn't been retired or anything yet. Sounds good!

Getting into more details

So open all of those specifications. Go ahead. I want you to read one section in particular and it's the author/editors section. What do we learn? That those specs were draft, edited and all done by the Google Chrome Team. Except maybe HTML Templates which has Tony Ross (previously PM on the Internet Explorer Team).

What about browser support?

Chrome has all the spec already implemented.

Firefox implemented it but put it behind a flag (about:config, search for properties dom.webcomponents.enabled)

Internet Explorer, they are all Under Consideration

What that tells us

Google is pushing for a standard. Hard. They built the spec, pushing the spec also very hary since all of this is available in Chrome STABLE right now. No other vendors has contributed to the spec itself. Polymer is also a project that is built around WebComponents and it's built by... well the Chrome team.

That tells me that nobody right now should be implementing this in production. If you want to contribute to the spec, fine. But WebComponents are not to be used.

Otherwise, we're only getting in the same issue we were in 10-20 years ago with Internet Explorer and we know it's a painful path.

What is wrong right now with WebComponents

First, it's not cross platform. We handled that in the past. That's not something to stop us.

Second, the current specification is being implemented in Chrome as if it was recommended by the W3C (it is not). Which may lead us to change in the specification which may render your current implementation completely inoperable.

Third, there's no guarantee that the current spec is going to even be accepted by the other browsers. If we get there and Chrome doesn't move, we're back to Internet Explorer 6 era but this time with Chrome.

What should I do?

As for what "Production" is concerned, do not use WebComponents directly. Also, avoid Polymer as it's only a simple wrapper around WebComponents (even with the polyfills).

Use other framework that abstract away the WebComponents part. Frameworks like X-Tag or Brick. That way you can benefit from the feature without learning a specification that may be obsolete very quickly or not implemented at all.

Categories: Blogs

Fix: Error occurred during a cryptographic operation.

Decaying Code - Maxime Rouiller - 10 min 21 sec ago

Have you ever had this error while switching between projects using the Identity authentication?

Are you still wondering what it is and why it happens?

Clear your cookies. The FedAuth cookie is encrypted using the defined machine key in your web.config. If there is none defined in your web.config, it will use a common one. If the key used to encrypt isn't the same used to decrypt?

Boom goes the dynamite.

Categories: Blogs

Renewed MVP ASP.NET/IIS 2015

Decaying Code - Maxime Rouiller - 10 min 21 sec ago

Well there it goes again. It was just confirmed that I am renewed as an MVP for the next 12 months.

Becoming an MVP is not an easy task. Offline conferences, blogs, Twitter, helping manage a user group. All of this is done in my free time and it requires a lot of time.But I'm so glad to be part of the big MVP family once again!

Thanks to all of you who interacted with me last year, let's do it again this year!

Categories: Blogs

Failed to delete web hosting plan Default: Server farm 'Default' cannot be deleted because it has sites assigned to it

Decaying Code - Maxime Rouiller - 10 min 21 sec ago

So I had this issue where I was moving web apps between hosting plans. As they were all transferred, I wondered why it refused to delete them with this error message.

After a few click left and right and a lot of wasted time, I found this blog post that provides a script to help you debug and the exact explanation as to why it doesn't work.

To make things quick, it's all about "Deployment Slots". Among other things, they have their own serverFarm setting and they will not change when you change their parents in Powershell (haven't tried by the portal).

Here's a copy of the script from Harikharan Krishnaraju for future references:

Switch-AzureMode AzureResourceManager
$Resource = Get-AzureResource

foreach ($item in $Resource)
{
	if ($item.ResourceType -Match "Microsoft.Web/sites/slots")
	{
		$plan=(Get-AzureResource -Name $item.Name -ResourceGroupName $item.ResourceGroupName -ResourceType $item.ResourceType -ParentResource $item.ParentResource -ApiVersion 2014-04-01).Properties.webHostingPlan;
		write-host "WebHostingPlan " $plan " under site " $item.ParentResource " for deployment slot " $item.Name ;
	}

	elseif ($item.ResourceType -Match "Microsoft.Web/sites")
	{
		$plan=(Get-AzureResource -Name $item.Name -ResourceGroupName $item.ResourceGroupName -ResourceType $item.ResourceType -ApiVersion 2014-04-01).Properties.webHostingPlan;
		write-host "WebHostingPlan " $plan " under site " $item.Name ;
	}
}
      
    
Categories: Blogs

Switching Azure Web Apps from one App Service Plan to another

Decaying Code - Maxime Rouiller - 10 min 22 sec ago

So I had to do some change to App Service Plan for one of my client. The first thing I was looking for was to do it under the portal. A few clicks and I'm done!

But before I get into why I need to move one of them, I'll need to tell you about why I needed to move 20 of them.

Consolidating the farm

First, my client had a lot of WebApps deployed left and right in different "Default" ServicePlan. Most were created automatically by scripts or even Visual Studio. Each had different instance size and difference scaling capabilities.

We needed a way to standardize how we scale and especially the size on which we deployed. So we came down with a list of different hosting plans that we needed, the list of apps that would need to be moved and on which hosting plan they currently were.

That list went to 20 web apps to move. The portal wasn't going to cut it. It was time to bring in the big guns.

Powershell

Powershell is the Command Line for Windows. It's powered by awesomeness and cats riding unicorns. It allows you to do thing like remote control Azure, import/export CSV files and so much more.

CSV and Azure is what I needed. Since we built a list of web apps to migrate in Excel, CSV was the way to go.

The Code or rather, The Script

What follows is what is being used. It's heavily inspired of what was found online.

My CSV file has 3 columns: App, ServicePlanSource and ServicePlanDestination. Only two are used for the actual command. I could have made this command more generic but since I was working with apps in EastUS only, well... I didn't need more.

This script should be considered as "Works on my machine". Haven't tested all the edge cases.

Param(
    [Parameter(Mandatory=$True)]
    [string]$filename
)

Switch-AzureMode AzureResourceManager
$rgn = 'Default-Web-EastUS'

$allAppsToMigrate = Import-Csv $filename
foreach($app in $allAppsToMigrate)
{
    if($app.ServicePlanSource -ne $app.ServicePlanDestination)
    {
        $appName = $app.App
		    $source = $app.ServicePlanSource
		    $dest = $app.ServicePlanDestination
        $res = Get-AzureResource -Name $appName -ResourceGroupName $rgn -ResourceType Microsoft.Web/sites -ApiVersion 2014-04-01
        $prop = @{ 'serverFarm' = $dest}
        $res = Set-AzureResource -Name $appName -ResourceGroupName $rgn -ResourceType Microsoft.Web/sites -ApiVersion 2014-04-01 -PropertyObject $prop
        Write-Host "Moved $appName from $source to $dest"
    }
}
    
Categories: Blogs

Microsoft Virtual Academy Links for 2014

Decaying Code - Maxime Rouiller - 10 min 22 sec ago

So I thought that going through a few Microsoft Virtual Academy links could help some of you.

Here are the links I think deserve at least a click. If you find them interesting, let me know!

Categories: Blogs

Temporarily ignore SSL certificate problem in Git under Windows

Decaying Code - Maxime Rouiller - 10 min 22 sec ago

So I've encountered the following issue:

fatal: unable to access 'https://myurl/myproject.git/': SSL certificate problem: unable to get local issuer certificate

Basically, we're working on a local Git Stash project and the certificates changed. While they were working to fix the issues, we had to keep working.

So I know that the server is not compromised (I talked to IT). How do I say "ignore it please"?

Temporary solution

This is because you know they are going to fix it.

PowerShell code:

$env:GIT_SSL_NO_VERIFY = "true"

CMD code:

SET GIT_SSL_NO_VERIFY=true

This will get you up and running as long as you don’t close the command window. This variable will be reset to nothing as soon as you close it.

Permanent solution

Fix your certificates. Oh… you mean it’s self signed and you will forever use that one? Install it on all machines.

Seriously. I won’t show you how to permanently ignore certificates. Fix your certificate situation because trusting ALL certificates without caring if they are valid or not is juts plain dangerous.

Fix it.

NOW.

Categories: Blogs

The Yoda Condition

Decaying Code - Maxime Rouiller - 10 min 22 sec ago

So this will be a short post. I would like to introduce a word in my vocabulary and yours too if it didn't already exist.

First I would like to credit Nathan Smith for teaching me that word this morning. First, the tweet:

Chuckling at "disallowYodaConditions" in JSCS… https://t.co/unhgFdMCrh — Awesome way of describing it. pic.twitter.com/KDPxpdB3UE

— Nathan Smith (@nathansmith) November 12, 2014

So... this made me chuckle.

What is the Yoda Condition?

The Yoda Condition can be summarized into "inverting the parameters compared in a conditional".

Let's say I have this code:

string sky = "blue";if(sky == "blue) {    // do something}

It can be read easily as "If the sky is blue". Now let's put some Yoda into it!

Our code becomes :

string sky = "blue";	if("blue" == sky){    // do something}

Now our code read as "If blue is the sky". And that's why we call it Yoda condition.

Why would I do that?

First, if you're missing an "=" in your code, it will fail at compile time since you can't assign a variable to a literal string. It can also avoid certain null reference error.

What's the cost of doing this then?

Beside getting on the nerves of all the programmers in your team? You reduce the readability of your code by a huge factor.

Each developer on your team will hit a snag on every if since they will have to learn how to speak "Yoda" with your code.

So what should I do?

Avoid it. At all cost. Readability is the most important thing in your code. To be honest, you're not going to be the only guy/girl maintaining that app for years to come. Make it easy for the maintainer and remove that Yoda talk.

The problem this kind of code solve isn't worth the readability you are losing.

Categories: Blogs

Do you have your own Batman Utility Belt?

Decaying Code - Maxime Rouiller - 10 min 22 sec ago
Just like most of us on any project, you (yes you!) as a developer must have done the same thing over and over again. I'm not talking about coding a controller or accessing the database.

Let's check out some concrete examples shall we?

  • Have you ever setup HTTP Caching properly, created a class for your project and call it done?
  • What about creating a proper Web.config to configure static asset caching?
  • And what about creating a MediaTypeFormatter for handling CSV or some other custom type?
  • What about that BaseController that you rebuild from project to project?
  • And those extension methods that you use ALL the time but rebuild for each projects...

If you answered yes to any of those questions... you are in great risk of having to code those again.

Hell... maybe someone already built them out there. But more often than not, they will be packed with other classes that you are not using. However, most of those projects are open source and will allow you to build your own Batman utility belt!

So once you see that you do something often, start building your utility belt! Grab those open source classes left and right (make sure to follow the licenses!) and start building your own class library.

NuGet

Once you have a good collection that is properly separated in a project and that you seem ready to kick some monkey ass, the only way to go is to use NuGet to pack it together!

Checkout the reference to make sure that you do things properly.

NuGet - Publishing

OK you got a steamy new hot NuGet package that you are ready to use? You can either push it to the main repository if your intention is to share it with the world.

If you are not ready quite yet, there are multiple way to use a NuGet package internally in your company. The easiest? Just create a Share on a server and add it to your package source! As simple as that!

Now just make sure to increment your version number on each release by using the SemVer convention.

Reap the profit

OK, no... not really. You probably won't be money anytime soon with this library. At least not in real money. Where you will gain however is when you are asked to do one of those boring task yet over again in another project or at another client.

The only thing you'll do is import your magic package, use it and boom. This task that they planned would take a whole day? Got finished in minutes.

As you build up your toolkit, more and more task will become easier to accomplish.

The only thing left to consider is what NOT to put in your toolkit.

Last minute warning

If you have an employer, make sure that your contract allows you to reuse code. Some contracts allows you to do that but double check with your employer.

If you are a company, make sure not to bill your client for the time spent building your tool or he might have the right to claim them as his own since you billed him for it.

In case of doubt, double check with a lawyer!

Categories: Blogs

Software Developer Computer Minimum Requirements October 2014

Decaying Code - Maxime Rouiller - 10 min 22 sec ago

I know that Scott Hanselman and Jeff Atwood have already done something similar.

Today, I'm bringing you the minimum specs that are required to do software development on a Windows Machine.

P.S.: If you are building your own desktop, I recommend PCPartPicker.

ProcessorRecommendation

Intel: Intel Core i7-4790K

AMD: AMD FX-9590

Unless you use a lot of software that supports multi-threading, a simple 4 core here will work out for most needs.

MemoryRecommendation

Minimum 8GB. 16GB is better.

My minimum requirement here is 8GB. I run a database engine and Visual Studio. SQL Server can easily take 2Gb with some big queries. If you have extensions installed for Visual Studio, it will quickly raise to 1GB of usage per instance and finally... Chrome. With multiple extensions and multiple pages running... you will quickly reach 4GB.

So get 8GB as the bare minimum. If you are running Virtual Machines, get 16GB. It won't be too much. There's no such thing as too much RAM when doing software development.

Hard-driveRecommendation

512 GB SSD drive

I can't recommend enough an SSD. Most tools that you use on a development machine will require a lot of I/O. Especially random read. When a compiler starts and retrieve all your source code to compile, it will need to read from all those file. Same thing if you have tooling like ReSharper or CodeRush. I/O speed is crucial. This requirement is even more important on a laptop. Traditionally, PC maker put a 5200RPM HDD on a laptop to reduce power usage. However, 5200 RPM while doing development will be felt everywhere.

Get an SSD.

If you need bigger storage (terabytes), you can always get a second hard-drive of the HDD type instead. Slower but capacities are also higher. On most laptop, you will need external storage for this hard drive so make sure it is USB3 compatible.

Graphic Card

Unless you do graphic rendering or are working with graphic tools that require a beast of a card... this is where you will put the less amount of money.

Make sure to get enough of them for your amount of monitors and that they can provide the right resolution/refresh rate.

Monitors

My minimum requirement nowadays is 22 inches. 4K is nice but is not part of the "minimum" requirement. I enjoy a 1920x1080 resolution. If you are buying them for someone else, make sure they can be rotated. Some developers like to have a vertical screen when reading code.

To Laptop or not to Laptop

Some company go Laptop for everyone. Personally, if the development machine never need to be taken out of the building, you can go desktop. You will save a bit on all the required accessories (docking port, wireless mouse, extra charger, etc.).

My personal scenario takes me to clients all over the city as well as doing presentations left and right. Laptop it is for me.

Categories: Blogs

End-to-end Hypermedia: Building a React Client

Jimmy Bogard - 38 min 39 sec ago

In the last post, I walked through what is to me the most interesting part of REST – the client. It’s easy to build a server API, but no API is complete without someone actually using that API. This is where most REST examples fall down for me – they show all sorts of pretty pictures of hypermedia-rich JSON from the server, but no real examples of how to consume that API.

I walked through some jQuery code in the last post, but why stop with jQuery? That’s so 2010. Instead, I want to build around React. React is perfect for hypermedia because of its component-oriented nature. A resource’s representation can be broken down into its components, and React components then matched accordingly. But before we get into the client, I’ll need to modify my sample to consume React.

Installing React

As a shortcut, I’m just going to use ReactJS.Net to build React into my existing MVC app. I install the ReactJS.Net NuGet package, and add a script reference to my downloaded react.js library. Normally, I’d go through the whole Bower/npm path, but this seemed like the simplest path to integrate into my sample.

I’m going to create just a blank JSX file for all my React components for this page, and slim down my Index view to the basics:

<h2>Instructors</h2>
<div id="content"></div>
@section scripts{
    <script src="@Url.Content("~/Scripts/react-0.13.3.js")"></script>
    <script src="@Url.Content("~/Scripts/InstructorInfo.jsx")"></script>
    @{
        var href = Url.Action("Index", "Instructor", new {httproute = ""});
    }
    <script>
        React.render(
            React.createElement(InstructorsInfo, {href: '@href'}),
            document.getElementById("content")
        );
    </script>
}

All of the div placeholders are removed except one, for content. I pull in the React library and my custom React components. The ReactJS.Net package takes my JSX file and transpiles it into Javascript (as well as builds the needed files for in-browser debugging). Finally, I render my base React component, passing in the root URL for kicking off the initial request for instructors, and the DOM element in which to render the React component into.

Once I’ve got the basic React library up and running, it’s time to figure out how we would like to componentize our page.

Slicing our Page

If we look at the page we want to create, we need to take this page and create React components from the parts we find. Here’s our page from before:

Looking at this, I see three individual tables populated with collection+json data. I’m thinking I create one overall component composed of three individual items. Inside the table, I can break things up into the table, rows, header, cells and links:

I might need a few more, but this is a good start. Next, we can start building our React components.

React Components

First up is our overall component that contains our three tables of collection+json data. Since I have an understanding of what’s getting returned on the server side, I’m going to make an assumption that I’m building out three tables, and I can navigate links to drill down to more. Additionally, this component will be responsible for making the initial AJAX call and keeping the overall state. State is important in React, and I’ve decided to keep the parent component responsible for the resource state rather than each table. My InstructorInfo component is:

class InstructorsInfo extends React.Component {
  constructor(props) {
    super(props);
    this.state = {
      instructors: { },
      courses: { },
      students: { }
    };
    this._handleSelect = this._handleSelect.bind(this);
  }
  componentDidMount() {
    $.getJSON(this.props.href)
      .done(data => this.setState({ instructors: data }));
  }
  _handleSelect(e) {
    $.getJSON(e.href)
      .done(data => {
        var state = e.rel === "courses"
          ? { students: {}}
          : {};

        state[e.rel] = data;

        this.setState(state);
      });
  }
  render() {
    return (
      <div>
        <CollectionJsonTable data={this.state.instructors}
          onSelect={this._handleSelect} />
        <CollectionJsonTable data={this.state.courses}
          onSelect={this._handleSelect} />
        <CollectionJsonTable data={this.state.students}
          onSelect={this._handleSelect} />
      </div>
    )
  }
}

I’m using ES6 here, which makes building React components a bit nicer to work with. I first declare my React component, extending from React.Component. Next, in my constructor, I set up the initial state, a object with empty values for the instructors/courses/students state. Finally, I set up the binding for a callback function to bind to the React component as opposed to the function itself.

In the componentDidMount function, I perform the initial AJAX call and set the instructors collection state based on the data that gets back. The URL I use to make the initial call is based on the “href” of my components properties.

The _handleSelect function is the callback of the clicked link way down on one of the tables. I wanted to have the parent component manage fetching new collections instead of a child component figuring out what to do. That method makes the AJAX call based on the “href” passed in from the collection+json data, gets the state back and updates the relevant state based on the “rel” of the link. To make things easy, I matched up the state’s property names to the rel’s I knew about.

Finally, the render function just has a div with my three CollectionJsonTable components, binding up the data and select functions. Let’s look at that component next:

class CollectionJsonTable extends React.Component {
  render() {
    if (!this.props.data.collection) {
      return <div></div>;
    }
    if (!this.props.data.collection.items.length){
      return <p>No items found.</p>;
    }

    var containsLinks = _(this.props.data.collection.items)
      .some(item => item.links && item.links.length);

    var rows = _(this.props.data.collection.items)
      .map((item, idx) => <CollectionJsonTableRow
        item={item}
        containsLinks={containsLinks}
        onSelect={this.props.onSelect}
        key={idx}
        />)
      .value();

    return (
      <table className="table">
        <CollectionJsonTableHeader
          data={this.props.data.collection.items}
          containsLinks={containsLinks} />
        <tbody>
          {rows}
        </tbody>
      </table>
    );
  }
}

This one is not quite as interesting. It only has the render method, and the first part is just to manage either no data or empty data. Since my data can conditionally have links, I found it easier to inform child components whether or not links exist (through the lodash code), rather than every component having to re-figure this out.

To build up each row, I map the collection+json items to CollectionJsonTableRow components, setting up the necessary props (the item, containsLinks, onSelect and key items). In React, there’s no event aggregator so I have to pass down a callback function to the lowest component via properties all the way down. Finally, since I’m building a collection of components, it’s best practice to put some sort of key on these items so that React knows how to re-render correctly.

The final rendered component is a table with a CollectionJsonTableHeader and the rows. Let’s look at that header next:

class CollectionJsonTableHeader extends React.Component {
  render() {
    var headerCells = _(this.props.data[0].data)
      .map((datum, idx) => <th key={idx}>{datum.prompt}</th>)
      .value();

    if (this.props.containsLinks) {
      headerCells.push(<th key="links"></th>);
    }

    return (
      <thead>
        <tr>
          {headerCells}
        </tr>
      </thead>
    );
  }
}

This component also only has a render method. I map the data items from the first item in the collection, producing header cells based on the prompt from the collection+json data. If the collection contains links, I’ll add an empty header cell on the end. Finally, I render the header with the header cells in a row.

With the header done, I can circle back to the CollectionJsonTableRow:

class CollectionJsonTableRow extends React.Component {
  render() {
    var dataCells = _(this.props.item.data)
      .map((datum, idx) => <td key={idx}>{datum.value}</td>)
      .value();

    if (this.props.containsLinks) {
      dataCells.push(<CollectionJsonTableLinkCell
        key="links"
        links={this.props.item.links}
        onSelect={this.props.onSelect} />);
    }

    return (
      <tr>
        {dataCells}
      </tr>
    );
  }
}

The row’s responsibility is just to build up the collection of cells, plus the optional CollectionJsonTableLinkCell. As before, I have to pass down the callback for the link clicks. Similar to the header cells, I fill in the data value (instead of the prompt). Next up is our link cell:

class CollectionJsonTableLinkCell extends React.Component {
  render() {
    var links = _(this.props.links)
      .map((link, idx) => <CollectionJsonTableLink
        key={idx}
        link={link}
        onSelect={this.props.onSelect} />)
      .value();

    return (
      <td>{links}</td>
    );
  }
}

This one isn’t so interesting, it just loops through the links, building out a CollectionJsonTableLink component, filling in the link object, key, and callback. Finally, our CollectionJsonTableLink component:

class CollectionJsonTableLink extends React.Component {
  constructor(props) {
    super(props);
    this._handleClick = this._handleClick.bind(this);
  }
  _handleClick(e) {
    e.preventDefault();
    this.props.onSelect({
      href : this.props.link.href,
      rel: this.props.link.rel}
    );
  }
  render() {
    return (
      <a href='#' rel={this.props.link.rel} onClick={this._handleClick}>
        {this.props.link.prompt}
      </a>
    );
  }
}
CollectionJsonTableLink.propTypes = {
  onSelect: React.PropTypes.func.isRequired
};

The link clicks are the most interesting part here. I didn’t want my link itself to have the behavior of what to do on click, so I call my “onSelect” prop in the click event from my link. The _handleClick method calls the onSelect method, passing in the href/rel from the collection+json link object. In my render method, I just output a normal anchor tag, with the rel and prompt from the link object, and the onClick event bound to the _handleClick method. Finally, I indicate that the onSelect prop is required, so that I don’t have to check for its existence when the link is clicked.

With all these components, I’ve got a working example:

I found working with hypermedia and React to be a far nicer experience than just raw jQuery. I could reason about individual components at the same level as the hypermedia controls, matching what I was building much more effectively to the resource representation returned. I still have to have some sort of knowledge of how I’m going to navigate the links and what to do, but that logic is all encapsulated in my topmost component.

Each of the sub-components aren’t tied to my overall logic and can be re-used as much as I want across my application, allowing me to use collection+json extensively and not worry about having to parse the result again and again. I’ve got a component that can effectively render a nice table based on a collection+json representation.

Next, we’ll kick things up a notch and build out a React.Native implementation, pushing the limit of hypermedia with a dynamic native mobile client.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Categories: Blogs

It worked on my machine – Communication Trap

Sauce Labs - 45 min 22 sec ago

“I don’t see it on my machine!” said every developer ever. Every QA professional I have talked to in my career has heard this at least once.

But why?

Have we asked what’s in a bug?

The answer can either be what gets your team on the road to efficiency, or it can become a kink in the delivery hose. Let’s discuss how your QA can help the team deliver faster by providing a consistent language to keep everyone on target.

Don’t Let The Bad Bugs Bite…

Over the last decade, I have seen issues that have almost no noted content in them (seriously, some have just declared something to the tune of “This feature is… not working”). Then there are tickets that are the golden standard, that have all the information you could possibly want (and probably some with more than you need that turn out to be a few bugs in themselves).

But what happens when you don’t have a common way to report a ticket, and why is it important?

I just came across an issue recently that seemed to have some steps to reproduce, but the setup was not included. Try as I might, I could not replicate the bug. The only way that I could come close to the reported result did not match the steps provided, and I could only guess that the setup I created was what the reporter had done. I will let you guess how long this issue took. Hint: It wasn’t a few hours.

Or perhaps you have an offshore team. I’ve seen many, many instances when someone reports a bug that just doesn’t have enough information in it. If the engineer cannot figure out exactly what the issue is, and has to place it on hold, back to the reporter, the engineer waits another night while the person on the other side of the world hopefully notices the ticket is back in his or her queue for more details. That is another full day that the bug exists, delaying when the root cause can be identified and the issue fixed.

Depending on the makeup of your team, and whether you are in an automated or manual setup — you need to consider how the issue will be verified. The person testing the fix (or writing the automated test to ensure the issue does not occur again) may not be the one who reported it. (Again, more time is spent figuring out how to test if the fix is correct.)

The bottom line? The back and forth that occurs from a poorly reported bug is costly in terms of time and resources.

Cut The Chit Chat

Having a uniform language/template will help reduce uncertainty across the board, and reduce the time a bug is spent unresolved. But what should be included in a bug report to cut out this back and forth, and keep the team on track?  There are several other things you may want to consider adding, but these are some of the top things I like to see from a tester:

  • Summary/Title: This should be succinct yet descriptive. I almost try to make these sound like a user story <user> <can/cannot><do x action> in <y feature>. When I sit in a triage meeting, can I tell what the issue is just by reading the summary?
  • Environment: every now and then we come across bugs that are very specific to the OS, database type, browser, etc.  Without listing this information, it’s all too easy to say ‘Can’t reproduce’, only to have a client find it in the field.
  • Build: Hopefully you are testing on the latest build, but if for some reason you have servers that are updated at different rates than others, you need to pinpoint when exactly the bug was found.
  • Devices: if you’re doing any type of mobile testing, what type of device were you using? What version? If you found a bug on the web app, do you see it on the mobile app too? Which one? Android or iOS?
  • Priority: The priorities are all relatively standard across the field — Critical, High, Medium and Low. Have criteria defined up front so everyone is on the same page as to what constitutes each selection.
  • Steps to reproduce: Not just ‘When I did this, it broke.’  Really break it down, from login and data setup to every click you make.
  • Expected Result vs. Actual Result: What were you expecting, and why?  What happened instead?  I’ve seen several bugs
  • Requirements and Wireframes: This helps to point to why testing occurred, and why someone wrote up a bug and linked it back to the originating artifact, though hopefully you are on the same page upfront, before development begins. Sometimes things slip through and perhaps an engineer has a different understanding of a feature than the tester. Being able to point back to why you think an element is a bug is helpful, and gets you all on the same page.

Of course, there are people other than your traditional testers writing bugs, and it is essential to use your QA to drive conformity. Perhaps your UX team is performing audits, or you have bug bashes where people from other departments are invited to test the system and find bugs, or you have someone new to the team that simply needs training. Having a template will ensure clarity and reduce inefficiencies, regardless of who enters the ticket.

Utilize QA to promote consistency, get bugs out of purgatory, and drive faster delivery.

 

Categories: Companies

Code Dx Code Analysis Tool on Bitnami

Software Testing Magazine - 1 hour 5 min ago
Code Dx, Inc., a provider of a robust suite of fast and affordable tools that help software developers and security analysts find, prioritize and visualize software vulnerabilities, today announced the availability of its code analysis tool on Bitnami, a marketplace that makes it simple to find popular server applications and development environments and deploy them in just a few clicks. Code Dx is now standardizing deployment with Bitnami installation technology for Linux, Windows and Mac OS X. After one quick installation, users are able to automatically configure and run Code Dx ...
Categories: Communities

Keynote Adds Appium to Support Mobile Testing

Software Testing Magazine - 1 hour 15 min ago
Keynote has announced the integration of Keynote Mobile Testing with Appium, an open source framework designed to help automate the testing of native and web iOS and Android mobile applications. The new integration will allow organizations to improve the quality of apps by enabling efficient collaboration between quality assurance (QA) practitioners doing end-to-end testing and developers automating unit tests. By integrating Keynote Mobile Testing with Appium, developers and QA professionals can pair a high-fidelity interactive mobile testing environment with a common automated scripting test framework and run tests across real devices ...
Categories: Communities

NeoSense 1.1 Launched

Software Testing Magazine - 1 hour 41 min ago
Neotys has announced NeoSense 1.1, an enhanced version of its synthetic monitoring solution for application performance and availability. The release of NeoSense 1.1 adds powerful new capabilities for web and mobile applications to quickly create realistic monitoring profiles even for complex business apps using the latest technologies. The solution enables you to generate synthetic users in production and actively monitor the performance and availability of critical business transactions within recorded user paths to detect and automatically alert you of any issues before they become problems for real users. NeoSense 1.1 Key Enhancements Greater ...
Categories: Communities

Should Every Tester Learn To Program?

Gurock Software Blog - 1 hour 53 min ago

This is a guest posting by Simon Knight. Simon Knight works with teams of all shapes and sizes as a test lead, manager & facilitator, helping to deliver great software by building quality into every stage of the development process.

header

Sometimes, I like to think of my teammates as a kind of band of adventuring heroes. Usually, I don’t mention this to them, in case they start looking at me funny. But when I gaze across the room at the product owner, if I squint and use my imagination a bit, I can see a bit of Elf in her. Probably she’s handy with a bow and arrow. If she was a World of Warcraft character, I reckon she’d be a Hunter class; great at long range thinking and decision making.

Sitting next to me I have a Warrior class programmer. Master of the weapons of his trade. Capable of slaying a tricky line of code with a single blow. Myself I think of more as a kind of Shaman. I get to call on elemental powers, unleashing the primordial forces of skilled testing to support the team and help them deliver a great product.

Mostly I’m happy enough doing my thing. I’ve levelled up quite a bit. My spells have power and the team appreciate them. Every so often though, I’ll watch my warrior buddy slicing and dicing code and think, it would be great to carve a few lines myself. I’m not going to be a full time code warrior, so I don’t need a broadsword or a battle-axe, or anything heavyweight. My weapon of choice probably wouldn’t be an Oathkeeper. I’d prefer something with a bit more Sting.

Context Is King

There’s some solid arguments for learning a bit of programming swordplay. Being able to slice beneath the surface of the application code means you can better understand what’s going wrong, and why. Your bug reports will be better informed and the additional information you provide to developers when raising defects means shorter feedback loops.

Of course the software you’re working with comes in many shapes and sizes. And you don’t have to interact with it in the way the developers intended. If you’re working on a web application for example, operating the software while keeping a browser dev tools window open will provide you with a view of the client-side code and resources. Running your software through a proxy can help you to see what requests are being sent and received. Being alert to application behaviour by way of a logging or monitoring tool can help you see even further down the stack.

The nature of the software your team is working on is ultimately going to determine what tools (or weapons) will serve you best. Testing a web site is going to be very different to testing a native application, or a piece of embedded software. There’s a common thread though. Whatever kind of software you’re testing, the engine beneath it, the thing that makes it all hang together, is code. The software behaves the way it does because that’s the way the developers have programmed it to.

So given that, as a software tester, your job is to test software that’s driven by code – it makes sense to learn how to understand how code works, right? Well, you’d think. But it turns out, there’s some debate about this very subject. Not everyone agrees that testers should learn to write code.

“There’s some debate about this very subject. Not everyone agrees that testers should learn to write code.” – Simon Knight Tweet this quote

sign

What’s All The Controversy?

If you follow some of the testing voices by way of their blogs and other social media, you may have come across arguments against learning to code like these:

  • Being able to code will make you think more like a computer and less like a person.
  • If you know how to code you’ll spend more time doing that and less time testing.
  • Learning to code comes at the expense of learning other, equally or more important skills.
  • Developers are better at programming anyway. Testers should focus on testing and let the developers write the code.

You’ll also see arguments in favour of learning to code, like these:

  • You’ll be better able to speak the language of your developers.
  • You’ll have a better understanding of the complexities and accompanying risks of development.
  • You’ll empathise with your teammates better when you understand the coding problems they face on a daily basis.

With all of this controversy around the subject, you could be forgiven for wanting to sit on the fence. But there’s more:

Anyone who is serious about a career in testing would do well to pick up at least one programming language. – Elisabeth Hendrickson

Back in 2010 Elisabeth Hendrickson carried out some market research and observed that 80% of the advertised testing roles they looked at seemed to require some kind of programming experience.

More recently, Rob Lambert speaking as a hiring manager notes that although there might once have been an argument for less technical testers who focused more on the big picture business scenarios, there are now plenty of testers who can write compelling test scenarios and develop the code to execute them as checks too.

It’s no longer enough to be a tester who doesn’t code, because when you apply for a job you may be up against a tester similar to you who can code. – Rob Lambert

If we take those last two points as arguably the most compelling reasons for learning a programming language or two, you’d think that life would become a bit clearer. You just need to make a decision about what programming language to learn and get on with it, right?

Wrong. Turns out, even that’s not straightforward.

What Does Learning To Code Mean Anyway?

config

Figuring out where to start learning anything can be tough. There’s so many choices! Should you go to college? Do an online course? Read some blog posts? Buy a book?

Learning a programming language can be particularly difficult. Before you start studying, how do you even know which language to choose? Figuring out answers to the questions below may help to narrow down your options:

What kind of work are you doing?
The software you test and the platforms it needs to work on may have a bearing on the kind of programming language it will be useful for you to know. If you’re working mostly on the client side of a web application, learning some Javascript might be more useful than learning some Java.

What does your code need to do?
Having a specific purpose or task that your code will be used for, in addition to being a great motivational tool for learning it in the first place, can be used to steer your decision about which language to actually learn. If you just need to create some data, a scripting language or some variety of SQL may be sufficient. If you need to develop a tool that’s intended to be a bit longer term, something more heavyweight like C# or Java may be required.

Where will your code be run?
Does your code need to work in a browser? On the server? On a desktop? In Windows, OS X and Linux? On a mobile device? The platform on which your code needs to be developed and run (or run against) should be a consideration.

What is everyone else using?
If you’re working on a team or project and everyone else is using C#, developing your scripts and tools in Ruby may not be the best idea. In addition to not wanting to upset folk, you want to take advantage of all of the experience and knowledge that’s around you, right? Find out what the preferred language of your colleagues is, and why. Then ask them for their advice and support in getting started with that language. Most often, they’ll be happy to provide it.

What skills is the market looking for?
Scanning job advertisements will provide a good indication of what skills are hot in the marketplace right now (as Elisabeth demonstrated back in 2010). You need to balance the ebb and flow of fashionable skills with longer term trends though.

Learning to Program

book

If you’ve chosen a programming language to get started with, you’ve cleared the first hurdle. It’s time to start developing those skills! The strategies below will help you on your way.

Talk to someone else who writes code
You’re probably already in one of the best places to learn programming; amongst developers! Go out of your way to talk to them and get them sharing their knowledge. Ask them to show you how their code works. Even better – sit with them as it’s being done. This way, you can add value by sharing your testing ideas while the code is still being written.

Look for examples of the same code in lots of languages
If you decide to read a book or some blog posts that provide typical examples, don’t just read code for the language you’ve decided to learn. Look at example code for other languages as well. Try to understand both the differences and the similarities so you can start to understand underlying patterns and principles.

Write some of your own code
Writing your own code will add depth to your understanding that simply can’t be achieved just by reading somebody else’s. And programming isn’t just about writing the code in any event. You have to setup your environment, familiarise yourself with the tools and carry out various other tasks along the way. There’s really no substitute for learning by actually doing the work.

Make changes and test them
Once you’ve gotten started with actually working through some examples, and hopefully got them working, start to make some changes. Apply your exploratory testing skills. Formulate a hypothesis, make a small adjustment, then observe the result. Look for ways to improve and optimise your code.

Learn to understand the compiler and debug your code
While you make changes you’ll probably experience some compilation or execution failures. The console will report an error of some kind, but do you understand what the error message means? Learning to search for reports of the same problem will be invaluable at this stage of your learning curve. Consider adding some logging to your code so that problems can be traced and pinpointed more accurately.

Look for things to do with your code
As your confidence grows and useful examples to learn from start to thin out, it’s time to start looking for ways to implement your learning at work. Mechanical activities that have to be repeated often are great candidates for code or scripted execution. But what about smaller, more ad-hoc tasks like data creation, extraction or manipulation? Try to think about ways you could carry out day-to-day tasks by writing simple scripts.

Store, share and re-use your code
As your portfolio of scripts and code grows, you’ll need somewhere to keep it all so you can refer to and re-use it. If you haven’t already done so, investigate some version control tools and code repositories. Git and Github are very popular (though other options are of course available) and Github makes it very easy to store and share your code with others.

Read someone else’s code
If you’re already working on a software project, why not download the source code and read through it? Many developers try to follow a test-driven approach to development, so unit tests are a great place to start. Some development tools will also let you step through the code as it’s being executed, which is a great way to see how it works in action.

Work on code somebody else wrote
Open source projects are a good way to start putting your new found skills to the test. Some of the software you use on a day to day basis is probably open source. Next time you use a tool, think about ways in which it might be improved? Join the mailing list for the development group or search the web for features under development and bugs that have been logged. Try to fix a problem in the source code or find some other way to contribute.

Practice, practice, practice!
If you want to get really good then you’ve got to keep putting in the work. It may not take ten thousand hours, but you should certainly expect to put in a significant amount of effort to become anything near competent. And even then, practice isn’t necessarily the same thing as experience. Professional developers solve all kinds of engineering problems on a daily basis. If you’re serious about learning to program, try to get some experience with production code. In these days of cross-functional teams, it shouldn’t be too hard.

Is Learning to Program Really Worth All The Effort?

github

There are many routes you could take towards becoming a highly skilled tester who is able to add significant value to the projects and teams on which you work. Leveling up your coding swordplay is just one of them. And one will that require significant time and effort.

So is it really worth it? Some people say that just learning to read code is enough.

“I advocate learning to read code over coding. Coding well can take a significant investment in time and practice.” – Alan Parkinson

Others argue that learning about programming (James Bach) or learning about IT (Patrick Prill) may be more valuable. These are all perfectly valid arguments, but learning about programming and IT is analogous to learning about swordplay and hand-to-hand combat.

Learning to read code would be like learning to read and predict an opponents movements in a fight. Useful skills to be sure. But not quite the same thing as being able to fight back.

The way that you learn how to handle a sword is by picking one up. Feeling the weight. Learning to swing, thrust and parry. Sparring against a real, live opponent once you’ve learned some moves. Learning to program is the same.

Reading a book or watching a few training video’s really won’t cut it. You need to sit at the keyboard and practice your moves, over and over. As you do so, your programming skills will start to emerge, and your understanding of what professional development looks like below the surface will grow.

This guide should get you started, but if you have some strategies that you’ve found particularly helpful in levelling up your programming skills, we’d love to hear about them in the comments section below.

PS: Have you found this article useful? We will have more relevant testing & QA related articles soon on topics like building a great testing team, improving your testing career or leveling up your testing skills. Make sure to subscribe below via email and follow-us on Twitter!

Photo credit: book and sign photos by Francois Schnell: here and here.
Categories: Companies

Delivering High Quality Applications in a Mobile World

Telerik TestStudio - Wed, 07/01/2015 - 06:22
Testing mobile applications is not an easy process. There are many common challenges that must be considered before testing a mobile application. This blog post will help you get started. 2015-06-17T15:45:27Z 2015-07-01T04:18:31Z
Categories: Companies

Building an Automation Framework that Scales Webinar

Telerik TestStudio - Wed, 07/01/2015 - 06:22
The next Test Studio webinar, which will take place on June 25, 11:00 a.m. ET, will focus on how Test Studio solution can help scale the test coverage by integrating with TFS and Visual Studio. 2015-06-09T15:00:00Z 2015-07-01T04:18:31Z
Categories: Companies

Mastering the Essentials of UI Automation—Webinar Q&A Follow Up

Telerik TestStudio - Wed, 07/01/2015 - 06:22
Wednesday, March 25, Dave Haeffner, joined me (Jim Holmes) for a webinar targeted at helping teams and organizations start up successful UI test automation projects. This webinar was based on a series of blogposts on the same topic hosted here on the Telerik blogs. You can find the recording of the webinar hosted online and you can sign up to receive a copy of an eBook assembled from those same blogposts. We had a very interactive audience for the webinar. Unfortunately we couldn’t answer all questions during the webinar itself. We’ve addressed quite a few of the unanswered questions below. 2015-04-03T20:07:39Z 2015-07-01T04:18:31Z
Categories: Companies

Master the Essentials of UI Test Automation Series: Chapter Six

Telerik TestStudio - Wed, 07/01/2015 - 06:22
Chapter 6: Automation in the Real World So here you are: ready and raring to get real work done. Hopefully, at this point, you're feeling excited about what you've accomplished so far. Your team has set itself up for success through the right amount of planning, learning and prototyping. Now it's time to execute on what you've laid out. Remember: your best chance for success is focusing on early conversations to eliminate rework or waste, and being passionate about true collaboration. Break down the walls wherever possible to make the mechanics of automation all that much easier... 2015-03-25T17:00:00Z 2015-07-01T04:18:31Z
Categories: Companies

Knowledge Sharing

SpiraTest is the most powerful and affordable test management solution on the market today