Category Archives: Dev

Azure PowerShell

Posted on by under Dev, Ops

Of course Microsoft provides PowerShell functionality for their Azure cloud. This is pretty handy for several reasons.

For dev ops engineers using PowerShell is going to be faster than doing everything through the portal. PowerShell commands or scripts can be saved and reused easily. Eventually a toolkit of scripts and commands will help built out a solid dev ops infrastructure.

I’ve made use of some of these commands on occasion and found them highly valuable. I’m capturing them in this blog post so I have a quick reference for later.

For your standard commands (creating and manipulating resources) the overview here is good:

Get Started with Azure PowerShell cmdlets

I was setting up deployment slots for automated deployments. I found this article useful for creating, deleting and swapping deployment slots:

Using PowerShell to manage Azure Web App Deployment Slots

Scrum Anti-Patterns

Posted on by under Dev, Lead

Came across this over the weekend. It’s a good read. Scrum is pretty standard practice in software development these days. It’s a great tool for managing task based work cycles to track how much gets done. Combine this with an iterative approach and you can begin to see trends in overall team productivity not to mention deliver working features on a regular basis.

This article and accompanying e-book provide some insight into how to interpret burn down charts. Obviously there’s an “ideal” burn down that teams are supposed to strive towards. What we don’t often do is properly interpret these charts during retrospectives to identify problems.

Agile is meant to be an adaptive process. We should be vigilant in assessing our process in order to maintain velocity and meet expectations. Without understanding what the chart is saying it’s difficult to make the appropriate changes.

I will be reviewing this article regularly to help understand what’s happening within my own project work.

Use Burn Down Charts to Discover Scrum Anti-Patterns

A Daily Impostor

Posted on by under Dev, Lead

Impostor syndrome has been a common buzzword in software development for the past year or two. It’s an interesting concept and I think everyone experiences it to a certain degree.

There are two parts to the definition. One, as an individual in the workplace you don’t internalize your own accomplishments. This means a person thinks less of themselves and downplays their achievements and value in the workplace. Two, the individual feels they are an incapable fraud and this fraud will eventually be discovered. These feelings lead to a lot of anxiety and self doubt.

Software seems to be an interesting industry where the impostor syndrome is quite common. I definitely feel this way and it has impacted my career negatively. How you boost your own self confidence is somewhat subjective, and while I’ve gotten better, I feel I have a long way to go.

I recently came across an article that gave me a different perspective on a few levels. The article was more about work life balance but it made a few interesting points about how managing work life balance helped the author with his own impostor syndrome.

The issue for me is that if I don’t set these boundaries, if I allow myself to continue working and exploring and solving problems at all hours, my own Impostor Syndrome only gets worse. I want to know everything and I cannot, and because I cannot I start to think less of myself.

This is a great take on things. I feel the same way on a lot of levels, I know there are things I should be learning, tools I should be experimenting with and trends I should be following. It’s nearly impossible to keep up and knowing that can lead to feelings of inadequacy that only increase symptoms of impostor syndrome.

The second paragraph goes on to discuss social media and the developer community

Twitter and other social media are the worst things when it comes to having this problem. People who are clearly brilliant programmers, people who I admire for their work, would proudly declare that they’d just spent all day coding and were feeling really accomplished and I could only sit back and despair about why I couldn’t do that. Why can’t I put that kind of effort in? Stupid brain! Why won’t you let me be as productive as they are?! I can be just as good as they are, if only you’d get outta my way!

This was a trap I found myself falling into a year ago when I was really getting into React development. I discovered twitter was a great place for news and updates and there were all these amazing developers out there sharing their work. But comparing yourself to others is a surefire way to get serious impostor syndrome. We are all different in our own strengths and abilities so there’s no reason to for direct comparisons.

The article is about being a 9 to 5 developer but I think it has lessons for anyone working in any profession. We must balance our work and life in order to be effective in both our personal worlds and our professional worlds.

The React Component Lifecycle

Posted on by under Dev

Coming from the ASP .NET background the idea of a page life cycle is pretty well known to me. I was relieved to discover that React components follow a similar model: The Component Lifecycle. Briefly, these are defined methods that are always called during the life of a component and can be overridden with custom logic.

The similarities lie in the idea that there are specific events for the creation, use and termination of a Page or Component. Because ASP .NET is a server side rendered page it has a more complicated life cycle. If you want to compare take a look at this ASP .NET Page Life Cycle Overview.

The React Component is simplified and as such can be broken down into three phases:

  • Creation and initial rendering – When a component is used it will need to be instantiated and rendered on the page. For this there are several methods which are executed in the following order:
    • constructor(): If you’re familiar with object oriented programming this is the method that instantiates your component. Useful for setting up initial state of the component and binding your call backs.
    • componentWillMount(): This is called immediately before mounting the component and rendering. This is useful because any logic in this method won’t trigger a re-render.
    • render(): This is the real heart of a component where the actual output is specified (what will show up on the screen). This method is required. Also note that the render function should not modify state directly.
    • componentDidMount(): Invoked immediately after the component is mounted. Any updates in this method will cause a re-render. This is a good location to fetch data from a remote source because the component will have rendered before the data is fetched.
  • Using and updating the component – Once the component is mounted it will be interacted with. This is where the user gets a chance to use the component. The following methods are executed in order when the component is being re-rendered:
    • componentWillReceiveProps(): This is called when the component props change (maybe being reset). This is not called during initial mounting and will only be called if some props update.
    • shouldComponentUpdate(): React’s default behavior is to re-render on any state change. This method can be used to override that if there’s cases when an update shouldn’t cause the component to re-render.
    • componentWillUpdate(): Similar to componentWillMount() this can be used for perparing before a re-render. Keep in mind that you can’t call this.setState() within this method.
    • render(): Same as above. This is what outputs the component. All updates have been captured and pushed to the screen.
    • componentDidUpdate(): Called immediately after the re-render. Similar to componentDidMount() and can be used for updating DOM elements or calling network resources.
  • Disposing the component – At the end of the lifecycle the component is removed from the DOM. Here we have one useful method:
    • componentWillUnmount(): This is called immediately before the component is unmounted and destroyed. Us this to clean up anything outstanding (network requests, DOM elements, timers etc.).

 

As you get into more complicated use cases your components will inevitably require the use of these lifecycle methods to handle complicated logic, data requirements and interactivity. Getting to know them will help in understanding React better.

Creat-React-App on Azure

Posted on by under Dev, Ops

The create-react-app boilerplate is pretty good. It’s easy to get up and running in react with this package. It also provides useful tools for compiling the application into a production ready deployment.

Unfortunately this doesn’t fit perfectly into the Azure pipeline because Microsoft wants to build things on the server. The Azure platform is great and they’ve got good support for Node.js apps. But with the create-react-app in particular a few steps need to be completed in order to get this up and running properly. There’s documentation for this out there but I ran into a couple small snags along the way.

  • Obviously you want to have a create-react-app set up in a repository.  You can clone the project from this Github Repo. Read the documentation on setting it up
  • You’ll need custom deployment scripts for this app. Install azure-cli then use

    azure site deploymentscript --node --sitePath build

    where “build” is the output directory from the npm run build command

  • The deploy.cmd must be modified to properly build the app then copy it over to the actual wwwroot. This Stack Overflow Answer helped point me in the right direction

kudu

  • In my case I’m doing “npm install” then “npm run build” and finally using the kudu sync to copy the compiled app to the wwwroot folder.
  • Connect your Azure web app to your repository. Microsoft provides support for a variety of source control repos for this. It’s fairly straightforward and well documented at here
  • Properly set the node version: I had some problems where my node and npm versions were incorrect. The version can be set in the package.json file or the application settings. This blog post explains both.
  • I needed to install the create-react-app and babel packages globally to handle proper transpiling. Log into Kudu from the Azure portal and run the npm install -g commands

If all goes well doing a commit and push to remote will kick off a build on the azure web app. From there the custom script will kick in and build the app using the create-react-app build script. Finally it should copy this to the wwwroot folder leaving you with a clean website.

The nice thing with the custom script is I’ll be able to get my unit tests running in there making it all automatic. The deploy will fail if the tests fail leaving the environment untouched. I’m excited to get this working for a very simple and streamlined CI pipeline.

 

Another useful post by Jeff Wilcox describing setting up custom builds on an Azure web app