Month: August 2017

CSS Specificity

Specificity is what you use to determine which bit of styling will “win” when there are conflicts. It’s all about how specific your styling is in defining what elements it should be applied to.

There are five different levels of specificity, with most important at the top:

  • !important
    • Wherever this is, it wins
    • It’s BAD. Avoid. It makes a mockery of any other css rules, and makes your css v hard to read / debug.
  • Inline styling
    • (use of the Style=”” attribute within an html element)
  • Id selector
    • !! Remember, this means that your html element has an Id, and you are writing styling which will only apply to that one html element with its own unique Id
      • This means your css will not be reusable!
    • Class, pseudo-class or attribute selector
    • Element or pseudo-element selector
  • So, if there is some styling which uses a level higher up the tree, it will win
  • If there are two pieces of styling at the same level, this is how you decide which will win:
    • Whichever one uses the most selectors at that level will win
    • So, div > ul > li > p will beat div > p
    • If they use the same number, then the one defined most recently (eg lower in the file) will win
  • Notes:
    • css-tricks.com uses a numbering system to represent the above levels, eg (0,1,0,3,0)
    • The universal selector (*) has no specificity value (0,0,0,0,0)
    • Pseudo-elements (e.g. :first-line) get 0,0,0,0,1 unlike their psuedo-class brethren which get 0,0,0,1,0
    • The pseudo-class :not() adds no specificity by itself, only what’s inside it’s parentheses.
    • The !important value appended a CSS property value is an automatic win. It overrides even inline styles from the markup. The only way an !important value can be overridden is with another !important rule declared later in the CSS and with equal or great specificity value otherwise. You could think of it as adding 1,0,0,0,0 to the specificity value.

More here (this was where I made these notes from): http://css-tricks.com/specifics-on-css-specificity/

Also more here: http://www.smashingmagazine.com/2007/07/27/css-specificity-things-you-should-know/

Want to learn Git / improve your Git knowledge?

Want to learn Git / improve your Git knowledge?

This list is culled from a thread where people were asking for useful resources when learning Git. A lot of useful recommendations were made, so I’m summarising them here (for my own benefit as much as anything):

I ran a git workshop for some devs earlier this year – I created a repo, a bunch of exercises and some top tips. Everything you need to find your way around should be in the readme: https://github.com/claresudbery/Git-Playground

I find it very helpful to understand what the definition of a branch is: it’s just a commit, which defines the current head of the branch …and that allows you to explain the concept of “detached head”.

I would also encourage people to dig a little into the gitconfig folder and understand what diffs and commit IDs are all about.

Criteria to Apply to Third Party Vendors

When assessing third-party products to purchase their software products:

  • Products need to be cloud native, extensible, and use open standards for integration.
  • How quickly do updates move from development to production? Do they use CI?
  • What do their processes look like?
  • What sort of extensions do they provide?
  • Do they allow you to customise a product without going off the upgrade path?
  • How will you migrate your existing data to the CRM solution?
  • Is data security guaranteed?
  • Does the solution have regulatory compliance?
  • Can you have a single central identifier for each customer, that can be used across systems?
  • How will communication happen between systems?
  • Does the vendor give good support?
  • Are their APIs fit for purpose?
  • Will they give you all the access you need?
  • Will they respond quickly to attempts to communicate / collaborate?

The Tech Lead’s New Project Checklist

These are my notes from a session on what a tech lead needs to do and know when arriving on a new project. The wisdom came from @JimBarritt at Thoughtworks – I am just the conduit.

Note that this list applies both to projects that existed before the tech lead arrived, and those where the whole team / product is new.

The first two are apparently “the two most likely causes of death or injury”:

1) Infrastructure

  • Where’s the production environment? It’s the most important one! What does it look like? When will it be ready? (Development environments are an afterthought after prod)
  • How are we going to go live? What’s the plan?
  • Load balancers
  • Firewalls
  • Certificates

2) Third parties

  • Integration!
  • If environments beyond your control are chaotic, it’s even more important to make sure your own environment is super-organised and disciplined, smooth, automated, with good scope planning, etc

3) Find the movers and shakers

  • Find all the people who can say No, and the people who hold the purse-strings/can sign off budgets, and the people who can say “Yeah, you did a good job” and get to know them
  • Eg:
    • Architects
    • The person who has control over data protection (Beware “organisational scar tissue”)
    • In the public sector, the SIRO (Senior Information Risk Officer)

4) Find any top-level documentation of your team’s work, read it and understand it

5) What’s the budget and the value proposition?

  • How well defined is it? Why are you doing the work? What’s the vision? Do people understand it?
  • Once you find this info, be really repetitive about it
  • If there are assumptions which are crucial to the whole success, keep repeating them at the start of every showcase

6) Try to have a one-to-one with each person in the team

  • Try to understand what their goals are, particularly on the project – and be transparent about your own goals. For instance if you have areas you want to move away from, find people who are keen to move INTO those areas
  • What are their main pain points and blockers?

7) Befriend a project manager and get to understand how they manage budgets

8) If there are multiple teams, find and get to know the other tech leads

9) Understand the importance of the Trinity of delivery: Delivery manager, product owner, tech lead

  • There is often a tension between these three areas
  • Build relationships with these people
  • All three should be present for all decisions, otherwise it’s likely to be skewed
  • Tech leads can sometimes get a bit side-lined in these relationships

10) Backlog: make sure the scope is clearly structured

  • Use story trees and backlog hierarchies
  • People can struggle with higher levels of grouping / scale
  • You need to get into the helicopter, go up and look down on the thing you’re building

11) Code:

  • Make sure you have access to it
  • Remain connected to it
  • Get a couple of the devs to give you a guided tour
    • Can be particularly illuminating to get newer team members to do this
  • You need to be able to visualise the entire code base (overall architecture)
  • How easy is it to run it from scratch for the first time?

12) What are the pain points and blockers?

  • Project manager is good person to talk to about that

13) Cross Functional Requirements

  • Resilience & scalability
    • Is it going to fall over with the load
  • Security
    • Is someone going to break into it?
  • Automation
    • Although automation is awesome, don’t fall for the trap of thinking you have to set everything up at the start
    • Don’t necessarily prioritise automation – but do prioritise what you need to actually deliver something
    • Once you have something up and running and iterating, it’s all good – but how do you break that initial blank sheet of paper?
    • You want pipelines etc, but as a principle, maybe there are different laws of physics right at the start of a project
    • Don’t spend six weeks building a pipeline with no actual deliverable – make sure you have something iterative
    • Imagine this product that you’re building… imagine you’re doing it with no software at all. Then bring the computer into it, and ask why – what is it going to give you? Where can it give you the most value? Don’t add stuff you don’t need
    • Imagine a walking skeleton in business terms – for instance, delivering whisky by physically posting it*. Your deployment walking skeleton can be over the top – only automate something when you need it
    • It’s a subtle art though – you don’t want to end up with tons of tech debt
    • You can spend a bunch of time working out the concept without having the capability.
    • Could have a simultaneous technical alpha – looking at cross-functional requirements etc
    • Try a walking skeleton of the architecture – a “scale model”

14) As a tech lead, what things are scaring you most about this project?

  • Do a futurespective graph with time on the x axis and clouds of uncertainty. If the cloud is really close and has a lot of lightning coming out of it… pay attention to it!
  • This is partly about risk management

* Whisky idea inspired by JK Werner.

How to Establish a Culture of Learning

I’ve pulled this out of a larger discussion. The detail of that discussion is not important, but a thing happened there which often happens in many discussions in IT: The possibility was raised that some people might be less well informed than they ought to be.

It’s a bugbear of mine. I think it’s a hidden menace in the software industry so I wanted to put something here.

And no, I do NOT think the menace is that people in IT are ill-informed. Quite the opposite: I think the menace is that we constantly judge one another for being (we believe) ill-informed.

I am often reluctant to admit that I don’t recognise a piece of IT terminology, because I think I might be judged for that. I think it might lead to people taking me less seriously in the context of whatever the discussion is.

But here’s the thing: There are thousands of books out there. Thousands of principles and phrases which encapsulate software development principles. Every single one of us will have books that we have not read and yet which some of our fellow colleagues believe are crucial to a good understanding of software development. Every single one of us will have phrases and terminology we have, by whatever chance, not come across before, even though they may seem crucial to a particular colleague.

There is a temptation sometimes to judge one another for not having knowledge of a particular thing. This attitude feeds strongly into impostor syndrome and the insecurities we all feel about how well equipped we are to do our jobs. The solutions to this are:

a) To rejoice whenever we encounter somebody who doesn’t have knowledge of one of our favourite things. It means we get to introduce it to somebody new! Hurrah!

b) To not assume that just because somebody has not come across a particular way of framing a problem or solution, does not mean they do not have knowledge and understanding of the underlying principles.

c) To always always feel safe to admit any gaps we might have, as that encourages others to do the same. This means we all get to learn more and foster a culture of continual learning and experimentation, which is crucial to good software development.

d) To have faith in the fact that we are part of a larger community of seasoned experts. This compensates for the fact that there is NO SUCH THING as a fully informed individual. We all have gaps. But together we can inform one another and create a powerful force.