Speed Networking @ CodeClan, Glasgow

Today I spent the morning meeting students at CodeClan in Glasgow. The team is helping nurture some new talent in the Scottish software scene, via an intense 16-week course covering everything from object-oriented principles to designing and developing apps in a variety of languages.

Taught by industry professionals, the candidates were all equipped with not only the technical principles but taught that in 2017, software development is an increasingly social career choice, with the best results coming from interaction & understanding over “technical-first” development.

What’s more, many of the courses are SQA approved, meaning they’re able to award recognised qualifications. If you’re interested in getting started in software development or are an employer looking for some new recruits, check them out at http://codeclan.com

DevOps: Remove the space. Make better products.

The route to DevOps is a cultural shift which is integral to the success of any software business.

You might not do it all right now, and that’s fine.
You might do some parts well, and some parts not so well. That’s fine too.

Extending DevOps is a journey, with the end goal being connecting the same principles & practices you do with your development teams to the rest of your business, ultimately creating a scalable workflow, manageable team cadence and by becoming more responsive and agile than before.

Let’s start by looking at what DevOps might look like to a typical developer:

  • Utilising version control & issue tracking
  • Employing software-driven IaaS management
  • Continuous integration
  • Automated deployments

You’re probably asking how we roll the above out to non-technical teams, however, the principles in each of the practices above can be implemented around existing frameworks & systems in use by project teams and can augment support processes and even help boost your sales function.

All too often, development, product, and operations teams work in silos, with too little discussion around the important stuff;

  • Are we focusing our energy on the right things?
  • Is the solution to this problem adding value for other customers?
  • Where is our product going?

DevOps is about inclusion, and we must fight spell check’s urge to put a space in between the two words comprising the portmanteau!

DevOps

REMOVE THE SPACE.

So we know roughly what DevOps looks like from a software team, but how do we implement it throughout the company?

I firmly believe it comes from the top, and by introducing better communication channels between historically disconnected teams.

Ops, Meet Dev

The main benefit of getting your operations team on board with DevOps is cohesion. It’s probably fair to say that your operations team doesn’t want to be looking at JIRA boards all day, just as your development team doesn’t need to know each and every thought. However, agreeing on a common toolset and having buy-in to ensure this is used correctly is a great way to ensure that both teams work together to ensure the delivery of relevant and high-quality software.

The result of doing this is that it breaks down the traditional barriers and ‘God complex’ which sometimes breeds in development teams by bringing everyone, from the product team to the support people into the product design, development and QA process.

At Layer Systems, we use Aha! as the conduit which brings the teams together.

Dev, Meet Ops

So you’ve got your systems (close to) perfect, what next?

Speedy code shipments and quick feedback loops are what most developers working in a team want: their work gets from their workstations to users’ screens much faster and continuous delivery enables faster iteration and product improvement.

If you’re just getting around to implementing DevOps, why not set up a few key metrics to check if it’s working for you as you transition:

  • How quickly does it move from ‘done’ to release
  • How often are you deploying to production
  • How much manual intervention does a deployment need

In Summary

Start small with the cultural shift.

Implement tried and tested processes within your development team, and then look for buy-in from your operations team and repeat.

Then you’ll be one.

Art of Working in Wood

Strathclyde University‘s Centre for Lifelong Learning has an amazing workshop called FABLAB, which is home to loads of high-spec tools & equipment. Graham Murdoch runs daytime and evening classes here. I did one this spring and built a dog lamp, pictured below. You should check out the course details here and register for the next session!

Layer Case Study – Voice2Voice

My name is Warren Stroud and I am the Managing Director at Voice2Voice Ltd. We are a international business that have been in business since 2003. We concentrate on multi-site organisations, supplying them with their telecommunication infrastructure and services.

The reason why we selected The Layer was to move away from various other programmes like Microsoft Dynamics, which was running our CRM, various spreadsheets, which were running the back office side of things, and various subscription models that handled all of our quoting processes.

From an order management perspective we never really had something in place that could take the equipment quoted within a proposal and follow that right through to invoicing. The Layer addresses that perfectly with barcodes, scan readers and a simple process of taking an order and processing through from a customer services perspective.
The Layer captures every bit of information that is needed here at Voice2Voice. The dashboards give us a good idea of what’s happening within the organisation. Our sales dashboard can tell us prospects, to quotes that have gone out, and even margins that can be made on the various deals that are out there. Help desk dashboard gives management information on cases that need addressing urgently [inaudible 00:01:33] being breached and general customer service.

My recommendation for someone who’s looking to change their CRM package, especially in the telecommunications industry, is to be quite wary. There are a lot of products out there, we’re a prime example of a company who used many of the products that are out there. When we found The Layer, we now know that it encompasses everything that an IT support or telecoms company requires in order to run their business.

I would definitely recommend The Layer to anyone who’s interested in it. It has brought this business to a new level with regards to profitability, efficiency and customer service.

Layer Case Study – Tru Solutions

I’m Mat Whyman, head of marketing, and key account manager for Tru Solutions. Tru Solutions are a complete business communications provider. We offer mobile, fixed line data, and managed services. We originally started looking for a quoting tool, and looked at two or three different processes. We also were interested in the CRM. When we saw what The Layer did, it was a no-brainer. The Layer took us through every process in the business we were looking to improve.

So our key business issues were finding an easy to use quoting tool for our sales guys, as opposed to producing a commercial report or template separate to that, and having no control. I think we wanted a system where the quoting was easy. So The Layer helps us solve our issues by condensing multi-supplier price books, products, and offerings into one platform.

The sales order process has also given us the ability to be able to track where we’re at in the process of completing the sales order. We’re not having to duplicate anything for capturing, for data capture. That converts through from the sales order process, which converts through from the quote. So there’s no room for error.

So from a management perspective, The Layer has given us a higher view of everything, from telesales operation, to booking appointments, where we’re winning, and where we’re not winning. Where we need to change, through to what sales activity we’ve got going on. Who is busy? Who is not?

The main benefits that we’ve seen since using The Layer are move effective on renewals, and at the point where we renew it ahead of time, as opposed to after events. That daily interaction with our customer base is invaluable. Also, profitability, we’ve actually increase profitability since using The Layer. 2015, we have 95% feedback from our customer base on the cases that we manage, which we thought was excellent. 2016, it was up to 97% positive feedback, and 2017 to date, is currently at 98% feedback. So it is helping us progress and to learn from our mistakes.

From a support and training perspective, The Layer came down and spent quite a bit of time with our staff, and took them through the modules that they needed training on, introduced them to the system fully, and then have since supported us impeccably since we went live. So I’d definitely recommend The Layer to any commerce business. It’s given us a streamlined process. It’s given us a condensed view of multi-suppliers, multi-clients, all in one place, and it’s given us control. It’s empowered Tru Solutions.

Taming SQL Server Transaction Logs

Ensuring your log files are in good shape when using SQL Server with AlwaysOn Availability Groups is essential and should be an integral part of your database deployment & management strategy. Since AlwaysOn requires full recovery model to be enabled prior to configuration, your logs must be backed up regularly in addition to the database itself.

If you’re reading this, it’s more than likely you’re trying to find an easy way to clear down your growing log files. I’d recommend taking a little time to think about why it’s happening in the first place before you do anything else. Perhaps your logs aren’t backing up properly, your preferred backup replica is configured incorrectly or one of your secondary replicas is in error or playing up, Whatever the reason, diagnose it before going any further using the steps below.

The best place to start is by examining the state of your transaction log files in order to determine the reason that your logs are filling up and space isn’t being cleared. You can do this by issuing dbcc loginfo against the database with issues then cross reference the reason ID(s) against Microsoft’s Factors That Can Delay Log Truncation list (from sys.databases).

So you’re not using HADR?

If you haven’t implemented a high availability solution such as AlwaysOn or database mirroring, a temporary fix (if your RPO allows) is to change your data recovery model to Simple in order to avoid backing up transaction logs at all. This isn’t recommended for any production environment where data loss is a concern. Again, do not attempt to change this if your database is part of an AlwaysOn Availability Group.

And if you are?

OK, so we’ve already established that why our logs aren’t backing up by running dbcc loginfo. Let’s run the following in SSMS against all the databases causing you problems so we know what we’re working with prior to attempting to resolve the issue

USE [yourDatabase]
DBCC SQLPERF(LOGSPACE)

If your logs are massive and growing *and* you’re taking regular backups, it’s worth checking that the SQL Server instance you’re taking backups on is set as the preferred backup replica in SQL Server. An incorrect setting in here can often delay the truncation of transaction logs.

Let’s free up some space

Ok, now we know which databases (and logs) are causing the problems, we can start to try and shrink them. If the results of your dbcc loginfo show that a replication issue is a potential problem, check the health of your availability group via the dashboard to ensure your replicas are in good shape. If not, you could remove the offending servers from the group until you’ve resolved the issue.

Next, take a backup of your log files. If space isn’t a concern, back these up to a physical drive. If you’re having issues with space (which is more than likely if you’re reading this), dump it to NULL. Please do this at your own risk as NUL is a special place in the file system. It’s the nul device, the outside bin or black hole of the file system.

BACKUP LOG [yourDatabase] TO DISK=‘NUL:’

Next, if required, let’s start to shrink your files. Again, run these at your own risk and ensure you have a full backup in place beforehand:

DBCC SHRINKFILE (yourDatabase_Log, EMPTYFILE);

Finally, get your backups back to normal and then go and explore what was *actually* causing your issue in the first place.

A good place to start is to ensure your backup solution is taking regular full backups, as well as frequent differentials & transaction logs.

Good luck!