Agile Delivery Lead

Last November a change was made to the composition of our development teams.  I had been working as a team lead since the previous March and things were going really well.  But a gap in the department was identified and I was asked to change roles to fill it.   My new title became “Software Engineer – Agile Delivery Lead”, yes it is a mouthful but it encompasses what I do.   Almost 6 months later I have settled into my new role and we have been slowly defining what that means for our teams, department, org, and myself.   I’m still working on what my duties entail.   For right now I have identified a list of responsibilities that are on my plate and we prioritized them based on how much I can help by performing each role.  As with anything, it changes constantly.

#1 Team Support:  Keeping the teams moving and the work steadily flowing onto our production systems is the first priority that I have on my plate.  I currently work directly with 2 development teams and keep my ears open for what 3 others are working on.  This includes activities such as Daily Standups, Weekly retrospectives, quarterly retrospectives, team velocity reporting, and managing the “Coming Soon” part of the team backlogs.

#2 Product Manager Support:  Working with the product managers to help to research potential improvements to the systems and start scoping out the work.   Research, reporting, epic/ticket creation, determining order of the work to get done, backup for the team when the PMs are out, and reviewing the work completed.

#3 Senior Software Engineer: Utiliziing my skills as a Sr. SE in the department to help move the platform forward.   Estimating, documentation, cross-training, code reviews, backup for Engineering Leads, architecture, and special projects.

#4 Department support:  Helping upper management with keeping a pulse on the various teams and making sure things are flowing smoothly.  Team velocity reporting, department velocity reporting, process research & implementation, and help to manage engineering needs backlogs.

#5 Personal Projects:  Continue to grow my own skills and knowledge by doing projects that will help the team, department, and company work more smoothly.

Dev Team Lead Resources

Articles

Books

Quote: Team Goals

My mission is to create teams that change the world.

I began this mission as a software developer. I saw in myself and other teams a passion for creating products that people would use and love. I saw that same passion dashed over and over again when the products fell flat. I knew there was more out there.

I have sought for years to find ways of enabling teams and organizations to have a different story. One where the hard work pays off. One where people take pride in a job well done and a product that people love.

I’m a long way off still from saying my mission is accomplished, but I’m here to share what I’ve learned and to help people find that new story.

~ Ryan Latta, LeanAgileUS 2019 bio https://twitter.com/recursivefaults

Reblog: Optimize jQuery selectors

I have always found jQuery selectors very complex and have never quite understood how to use them properly.   I just found this article from the website Optimize your jQuery selectors for best performance.  It is a fantastic article and full credit goes to them.  The only reason I am copying it here is because I want to make sure that the information stays in my toolbox.   Please check out their page to see more information.


• ID selector $(‘#elementID’)
• Tag selector $(‘p’)
• Class selector $(‘.CSSClass’)
• Attribute selector $(‘[type=”text”]‘)
• Pseudo selector $(‘:visible’)

Always use ID selector if possible

Accessing DOM is a very expensive operation, so it’s beneficial to minimize effort and time. As we all know, the ID attribute is unique for each HTML element on the page. in JavaScript document.getElementById() is the function that one would use to select the HTML element. It’s the fastest and the best way to select the element because it directly maps to the element. jQuery is a library written on top of JavaScript, which means that it internally calls the JavaScript functions to do the job. When you use ID as a selector in jQuery, it internally calls document.getElementById(). To select the HTML element with elm as ID, the jQuery code looks like this: $(“#elm”);
This method works well in all browsers, so it’s a good choice if you are using an older browser.

Cache your selector

Caching improves the performance of the application. You can cache data or objects for better performance. You can also cache your jQuery selectors for better performance using the ID as your selector (as mentioned in the previous tip). When you don’t cache the selector, jQuery must rescan the DOM to get the element. You may not feel the difference in small applications, but with large applications this becomes very critical. Let’s look at the process of caching objects in jQuery. The following simple line of code caches the selector and stores it in the $elm variable:

var $elm = $("#elm");

Now use the $elm variable instead of using the jQuery ID selector. Like this:

var $elm = $("#elm");
 $elm.addClass(‘dummy’);

Remember, the scope of a variable is limited to where it is defined. If it is defined as a global variable then you can use it anywhere in the jQuery code, but if it is inside a method the scope will be limited to that particular method only. Global caching is useful for elements which are frequently used in the code.

Define a context with jQuery selectors

By default, jQuery selectors perform their search within the DOM. But while defining the selector, you can pass the context, which limits the searching range for the jQuery selector. In other words, you are instructing jQuery to look inot the context rather than beginning the search from the document root. This helps in speeding up the searching process which will definitely improve the performance. Passing the context is optional, but you should use it whenever you can.
Enough theory! Let’s take a look at a practical example. Consider the following HTML code:

<div id="”parent1”">
<div class="”child”"></div>
<div class="”child”"></div>
<div class="”child”"></div>
</div>

If you want to select all the div element with child class you can use the following jQuery code:

var $elm = $(".child");

The above code will search for elements with child class starting from the document root. It can be optimized by passing via an alternate selector. Like,

var $parent = $("#parent1");
 var $elm = $(".child", $parent);

This limits the search range, so now searching is limited to the div with ID parent1. The context argument can be a DOM element, a document, or a jQuery object. If you pass context, then jQuery will internally use the find method to retrieve the elements. So the above code is internally converted to:

var $elm = $parent.find(".child");

jQuery first checks if the passed context is a jQuery object. If it is, it calls the find() method on the given context. If the given context is a DOM element, it first converts it to a jQuery object and then executes the find() method. As such, it is better to pass the object as context instead of the DOM element because it will reduce the conversion time.

Don’t repeat your selectors

As mentioned earlier, you can cache the jQuery selectors which prevents you from repeating your selector. jQuery also offers chaining, which allows you to chain multiple methods in a single call. Consider the following jQuery code:

$("div").css("color", "red");
 $("div").css("font-size", "14px");
 $("div").text("New Text!");

Below is the first optimized version using caching:

var $div = $("div");
 $div.css("color", "red");
 $div.css("font-size", "14px");
 $div.text("New text goes here!");

Next is the second optimized version using chaining:

$(“div”).css({“color”, “red”, “font-size”, “14px”}).text(“New text goes here!”);

Use class selector wisely

jQuery also provides a CSS class selector which allows you to select elements with a particular CSS class. This is again a very useful and popular selector as it allows you to select multiple elements at once. However, you have to be cautious while using class selector. The following jQuery code will select all the elements with “dummy” class applied to them:
$(“.dummy”)

In this case, jQuery has to scan the complete DOM to discover elements with dummy class. As mentioned earlier, traversing DOM is a very expensive process so it’s always better to minimize this effort. In this case, you can pass a tag name to reduce the searching scope. Like this:

$("div.dummy");

The above code tells jQuery to only give me the DIV elements with dummy CSS class applied. Though the class selector works quite well in modern browsers, older browsers have performance issues with class selector. That being said, it’s not always a good choice to add a tag name with class selector. Why?

In this example, jQuery will first search for all elements with class dummy and then filter records to only return those elements that are div elements. So when the dummy class is only meant for div elements, you need to specify the tag name in order to add an extra step of filtering. Keep in mind that this is only useful when the CSS class is applied to different HTML elements like span, paragraph and div.

Be very specific about selectors

Did you know that jQuery selectors are executed from right to left? In other words, the last selector will be executed first when there are multiple selectors. Consider the following example:

$("div.parent .child");

In this example, jQuery will first search for all elements with class child (last selector executed first) and then apply a filter to return only those elements which are div elements with a parent class applied. This is the optimized version:

$(".parent div.child");

Here we are more specific on the last selector, which helps to speed up performance!

Look for an alternative for the Pseudo selector

Pseudo class selectors are CSS selectors with a colon preceding them. They are also available with jQuery – :visible, :checked or :first. Pseudo selectors are useful for selecting elements with different states, or a particular element from a set of elements, but they are slower compared to other jQuery selectors. You should either find a way to replace the pseudo selector or be very specific in using it. Let’s take a look at examples of both. The following jQuery code selects all elements which are visible:

$(":visible");

You can be more specific here. Like,

$("input:visible");

or even better,

$("form").find("input:visible");

Pseudo selectors like :first, :last and :eq allow you to select a particular element from a set of elements. As an example, the following jQuery code will select the first table row using the :first pseudo selector.

$("tr:first")

The above code can be replaced with better performing code, but first you need to cache the selector (table row in this case).

var tRows=$('tr');

Since jQuery stores this as an array, we can take advantage of it. To get the first table row:

var firstRow=$(tRows[0]);

To get the last element (:last),

var lastRow = $(tRows[tRows.length - 1]);

Or to get any nth row (:eq(n)),

var nRow=$(tRows[n]);

 

Paging Example

This is a great example of doing paging in SQL versus on the front end.

-- find activity logs
insert into @tblActivityLogs
select al.ActivityLogId
	, al.TargetPartyId
	, pWhoDidIt.PartyId
from dbo.ActivityLog al
left join dbo.Party pWhoDidIt on al.PartyIdentifier = pWhoDidIt.Identifier
where al.TargetPartyID = @PartyId
	and al.Created >= @DateTimeRangeFrom
	and al.Created <= @DateTimeRangeTo
order by al.Created
	offset ((@Page - 1) * @PageSize) rows fetch next @PageSize rows only

SQL Saturday #682

Full Session Schedule

https://www.youtube.com/user/SQLPASSTV

Session #1: Reading Execution Plans Successfully

By: Arthur Daniels

Twitter: https://twitter.com/arthurdanSQL?lang=en

http://www.dba-art.com/

If you’ve seen an execution plan but didn’t know how to read it, this session is for you.

The goal of this session to learn how SQL Server is interpreting your query into an execution plan. We’ll discuss execution plan internals, how SQL Server estimates the cost of your query, and what a graphical execution plan is displaying through its operators.

Learning to read an execution plan is a great way to begin troubleshooting performance. At the end, we will take a look at how SQL Server 2016 provides more tools for exploring execution plans.

Notes:

Session #2: Getting Started with Extended Events 

By: Andy Galbraith

Twitter: https://twitter.com/DBA_ANDY?lang=en

http://nebraskasql.blogspot.com/

Few subjects in Microsoft SQL Server inspire the same amount of Fear, Uncertainty, and Doubt (FUD) as Extended Events. Many DBA’s continue to use Profiler and SQL Trace even though they have been deprecated for years. Why is this?

Extended Events started out in SQL Server 2008 with no user interface and only a few voices in the community documenting the features as they found them. Since then it has blossomed into a full feature of SQL Server and an amazingly low-impact replacement for Profiler and Trace.

Come learn how to get started – the basics of sessions, events, actions, targets, packages, and more. We will look at some base scenarios where Extended Events can be very useful as well as considering a few gotchas along the way. You may never go back to Profiler again!

Notes:

Session #2: Query Optimization Statistics : Driving Force Behind Performance

By: Vern Rabe

Twitter: https://twitter.com/VernRabe?lang=en

http://rabedata.com/

When the SQL Server optimizer evaluates a query to determine how best to execute it, the statistics are quite possibly the most important tool at its disposal. But SQL Server statistics objects aren’t perfect because they only contain estimated summary information. In this session, we’ll start with an overview of what the statistics objects are, how the optimizer uses them, and some general guidelines for their maintenance. Then we’ll look at some of the issues, how to find them, and how to solve them, that can arise due to their imperfection: ascending keys (the most prevalent statistics based performance killer?), correlated predicates, skewed distribution, or downright bad summary information. There’ll be many examples, and even a stored procedure to help you find ascending keys. By applying the techniques we’ll discuss, you WILL see improved query performance.

    

Notes:

Session #2: Getting the most out of SQL Server Data Tools 

By: Eric Strom

Twitter:

SSDT has been around for a while, but a lot of people don’t use the tool to its full capabilities.  In this session, we will cover writing unit tests, good deployment script writing practices, T4 and command variables.  This session requires a good understanding of T-SQL and Visual Studios.

Session #3: Lightning Talks (Round 1)

Vagrant Auto Build System

By: Mitchell Hamann

This session talked about the Vagrant Software that can be used to build SQL development VMs and deploy to developers machines.

The bonus to doing something  like this is that the SQL tools may not need to be installed on each developers machine.

SQL Server Monitoring on No Budget

By: Daniel Crowson

A review of different free software that can be used to monitor your SQL server including sp_whoisactive, DMVs, Perfmon Counters.

In the Q&A session the following list of lower budget options were also listed:

  • SQL Monitor
  • FogLight
  • Brent Ozar (Highly recommended)
  • Solar Winds
  • Sentry One (Highly recommended)
  • SP Blitz
  • Stack Overflow Observor

Testing Backups in One step

By: Constantine (CK) Kokkinos

Twitter: https://twitter.com/mobileck

https://constantinekokkinos.com/

Session about using the https://dbatools.io/ software to test the current state of databases quickly and cleanly.

Session #3:  Index 360 – Looking at Indexes from Multiple Perspectives

By: John Eisbrener

Twitter: https://twitter.com/johnedba?lang=en

http://www.dbatlas.com

If you have used a database, chances are almost certain you’ve utilized indexes as well.  In this presentation I will discuss both Rowstore and Columnstore Indexes and why they are important to anyone that interacts with a database.  This session will cover what they are, how they are utilized, how best to take advantage of them, and even when they can be problematic. It is my intention to help anyone become more comfortable with indexes and understand what they can do for you and your role, be it a DBA, Developer, or BI Professional.

Session #4: Difficult Queries

By: Rick Bielawski

https://rickbielawski.wordpress.com/

Notes:

  • Cross Joins, Cursors
  • Snooze

Session #5: Intro to Machine Learning

By: Jared Zagelbaum

Notes:

 

  • Flew wayyyyy over my head.

Session #5: Free SQL Server Tools

By: Cecil Spivey

Everybody loves a free lunch. Come to this session to learn about all the SQL Server freebees.