CTO Craft Con has been running for 9 years, but this year was my first chance to attend — and I'm pleased to say it didn't disappoint. As you'd expect given today's technical landscape, there was a lot of focus on AI and how it's been reshaping teams, particularly since December 2025.

Small changes. Real impact.

Highlights / Thoughts

AI is Everywhere

AI is everywhere, and unsurprisingly it dominated the conversation in and out of the auditorium. I was keen to get a real sense of where people are in this journey.

I think everyone agreed it was disrupting common practice. There was no shortage of enthusiasm about what AI should be able to do - and while specific agentic AI success stories are still emerging, the direction of travel is clear. The industry is still in discovery mode. But the overall message was simple - pay attention, or risk getting left behind.

What Makes a Good Hire?

With the push for AI, what makes a good hire has changed. Several talks touched on the need for developers to also be good product people - and this came up repeatedly in conversations between sessions too. AI is merging the roles of product, engineering, design and UX together.

Over the last few months, my hiring focus has shifted towards people who can not only code well but also bring a product mindset and entrepreneurial outlook. For those who can do two of the three reasonably well, this is a genuine land of opportunity.

Empathy was a running theme

Several speakers raised empathy as the key differential between humans and AI. In particular, they commented that they felt empathy would be something that AI would never be able to replicate as it requires human effort.

The time you invest in your teams is part of the reason why empathy feels genuine; and even if AI could simulate it, it wouldn't carry the same weight.

As roles evolve in this new era, showing up with empathy for your team through that change matters more than ever.

When a model performs better but at the cost of being more verbose

AI as a Thinking Partner

We've become accustomed to AI completing tasks for us in product engineering but James Stanier showed us how he was using it to reduce leadership isolation, manage his ideas and notes via a scratchpad of ideas and automate the mundane, like gathering metrics.

To borrow wisdom, James shares a list of transcribed podcasts, interviews and blog posts from people he admires, has AI summarises them and then includes those insights in his context files.

I'll certainly be playing around further with the idea of an AI Executive Assistant with all these different agent roles to help me work.

Moving the Bottleneck

Will Lytle spoke about how AI has made writing code cheap, but it has just moved the bottleneck further down the Software Development Life Cycle. He referred to a quote from State of DevOps 2025:

AI doesn't create organisational excellence - it amplifies what already exists. The value of AI will be unlocked by re-imagining the system of work it enables.

He spoke about the RACER framework which I'll be experimenting with over the next few weeks:

• Rollout: deploy and use the tools
• Approach: align the right tools with the right use cases
• Constraints: systematically eliminate barriers
• Engineering Impact: measure impact on productivity
• Results: achieve business outcomes

If you're navigating AI bottlenecks in your engineering org, his slides are sure to help

From SaaS to Agentic Platforms

Jaime de Mora made a compelling case for how SaaS is being disrupted by agentic AI.

He argued that interoperability needs to be the foundation of agentic systems — built on MCP protocols and CLIs — and showed how agentic products are increasingly being measured, and priced, by outcomes rather than usage. Intercom's Fin is a great example where they charge per successful ticket resolution, not per seat.

The market is shifting from traditional SaaS metrics like DAU, MAU, time in app and feature usage to outcome-based measures: tasks completed, time to resolution, cost per task, and ROI achieved.

Owning the Stack

Moving away from AI, Sathya Nandakumar delivered one of the most compelling talks of the conference - covering Holland & Barrett's complex journey from legacy systems to in-house platforms.

She spoke candidly about staying committed to the goal through significant challenges, and shared hard-won lessons on the importance of communicating complex migration work to stakeholders.

Leading From the Edge

Similarly, Dr. Ilknur Colak drew compelling parallels between climbing the Seven Summits and technical leadership.

There were some great tips for leaders in here such as building resilience before the storm, taking ownership with others hesitate, using bold communication to build trust and staying calm in uncertainty.

And beyond the leadership lessons, her personal story of conquering some of the world's most demanding terrain was genuinely inspiring.

Glue Work

Somehow I hadn't come across the term "glue work" before, but I quickly recognised it as something that I had come across many times over the years within my own leadership skills and team.

In her talk, Melinda Seckington presented how to share glue work through the team and through the community - and how sharing that glue work builds leadership skills and shapes engineering culture.

Melinda propsed six levels to share the glue work between teams:

Perpertual Exposure

1. Recognise and Celebrate
2. Build Shared Knowledge
3. Connect People

Deliberate Practice

4. Learn By Doing
5. Learn By Teaching
6. Learn By Leading

The Human Load Balancer

Another talk that hit home was Rebecca Anderton's session about the human load balancer and recognising when shielding your team actually becomes a burnout risk to you as a leader.

She spoke about the invisible work that leaders often do to protect their team - which works in the short term but creates problems further down the line.

So instead Rebecca advised on how to step away from being always-on and build sustainable leadership practices such as sharing context, building boundaries with intent and sharing the load on purpose that in the long term protect both the team and leader.

There was also lots of advice on hiring and people management

Conclusion

There were so many great talks and insights that I haven't mentioned here, and I genuinely found something of value in almost every one of the talks.

Looking forward to the next CTO Craft Con — maybe by then AI will have advanced enough to take the stage itself!

For as long as I can remember, in most businesses these disciplines have operated in clearly defined lanes. Product owned the vision, engineering built it, and UX made it usable. Each role had its specialists, its processes, and its seat at the table. In the start-up world, the lines have always been a bit more blurred with team responsibilities, but with this new wave of agentic AI even larger teams are going to find that this model is under pressure.

AI is compressing the skill gap in ways that would have seemed unlikely even six months ago. The cost of writing code is lower than ever. Interfaces can be prototyped quickly, thrown away and restarted with almost no penalty. Product decisions can be validated without a full team behind them. The bottleneck is no longer technical execution. Instead, the bottleneck is thinking time.

This is already playing out. Engineers are now making product calls. Designers are prototyping in code. Product managers are shipping without engineering dependency. The lines aren't just blurring — they're genuinely dissolving. A single person can now explore an idea from concept to working prototype in a single day.

This has real implications for how we build and hire. The most valuable people aren't necessarily deep specialists anymore. They're people who can move fluidly across disciplines, hold the bigger picture in mind, and make good decisions with incomplete information. T-shaped skills are giving way to something harder to define but increasingly recognisable when you see it. None of this means specialisation is dead. But the weight is shifting.

So if you are working in product engineering, what should you do?

The best place to start is by getting curious about the disciplines adjacent to yours. If you're an engineer, spend time understanding why product decisions get made. If you're in product, get closer to the technical constraints. If you're in UX, understand the business outcomes you're designing for.

You don't need to become an expert in everything — but developing fluency across the stack, both technical and human, is increasingly the differentiator. The people who will thrive in this new world are those who lean in rather than wait to see how it plays out.

Change is coming whether we're ready or not. The right response isn't anxiety. It's curiosity. Bring a product mindset, an entrepreneurial spirit, and a genuine openness to working differently.

Nobody has this fully figured out yet. It's a work in progress - for all of us. The real advantage right now is curiosity.

Reading that back, that sounds brutal. But as time goes on and the models improve, it's a reasonable question. The tools are genuinely impressive. But the question misidentifies the bottleneck. Product development isn't slow because writing code is hard. It's slow because understanding what to build and why is hard. AI works to requirements. It doesn't work to intent.

Requirements vs Intent

Imagine asking your AI tooling to help simplify an onboarding flow.

This looks like a sensible goal. The AI can see exactly what you were optimising for, so it recommends removing a step that on the surface looks like it is adding unnecessary complexity.

The problem? That step isn't complexity. It's the core business proposition. Remove it and you're not building a simpler product. Best case you've lost some context of what you were trying to build. Worst case you're building a different product entirely.

You could argue that you should have given the AI better context. And you'd be right. But that's precisely the point. The context has to come from somewhere. It comes from months of customer conversations, failed experiments, and hard-won decisions that sit in the heads of the people who built the business. You can't shortcut to it. You have to earn it.

Requirements are what you ask for. Intent is why you're asking for it, and what you're ultimately trying to achieve. The difference between the two is where products win or lose. The AI could see the requirement was to simplify onboarding but had no way of knowing the intent behind the step it recommended removing.

The tools don't compress the learning that builds that intent. They don't replace the iteration. They don't skip the moment where you realise you built the wrong thing and have to go back. Customer feedback, market signals, the hard conversations with users - these are still what separates a product with a point of view from one that just functions.

What AI changes is how quickly you can execute once that intent is clear. That's genuinely valuable. But the intent still has to be defined first, and the only way to build it is to go through the process.

What This Means For Your Business

AI is very good at the parts of product development that are routine and repeatable. It's the unique parts — your business model, your customers, the decisions that make your product yours — where it falls short. That's not a temporary limitation waiting to be solved by the next model release. It's the nature of what these tools are.

As building code gets faster and cheaper, the constraint shifts. It's no longer about how quickly you can produce something. It's about how clearly you can decide what to build.

The businesses that succeed in this AI era won't be the ones who generate the most output. They'll be the ones who remain clear about what makes them valuable — and use AI to build something that reflects that, rather than something that just looks like everything else.

That's a higher bar than it used to be, not a lower one. Speed is easy now. Knowing what to build is the hard part.

Sometimes time is not on your side. Your team is busy building features, but the discussions around how we build and with what are building up.

My CTO coaching mentor, Joel Chippindale, once introduced me to a technique called lean coffee - a structured but agenda-less meeting. For the CTO circle I was participating in it worked incredibly well for ensuring we each got to speak about the topics that were important to us and that we were invested in what others had to say.

So I decided to implement a variant of it within my teams.

What is Lean Coffee?

With lean coffee participants gather, build an agenda together, and begin talking. After five minutes, the organiser interrupts the group and asks everyone to vote thumbs up/down on whether to continue discussing or move to the next priority topic. If majority votes to continue, you get another shorter time duration.

How we use Lean Coffee

To be the most time efficient for our team I've been trialling a slight variation on lean coffee which works as follows:

• We schedule a regular team meeting
• 24 hours before the session, the organiser asks participants to propose suggestions on what they wish to discuss on a Slack thread
• Participants are also asked to place emojis next to those they feel strongly about
• Shortly before the session, the organiser orders the topics by number of emojis
• The session begins and follows the usual lean coffee structure:
  • Each topic gets a timebox (5 minutes)
  • If the topic doesn't naturally conclude before 5 mins, we vote thumbs up/thumbs down on whether to continue
• The aim is to have an action/resolution to each item

The Results

So far it has been working incredibly well for us. It has helped us make a lot of rapid decisions on the way we work without requiring a lot of time from the team.

Lean Coffee turns control back over to the attendees of the meeting; it reduces the ability for one person to dominate the conversation and it ensures the team are able to talk about the topics that matter to them - which means their ownership, accountability and engagement has also improved.

Give lean coffee a try!

As engineering managers, we can spend most of our time deep in execution. We spend our day to day unblocking teams, managing delivery and navigating difficult technical decisions. But influence in an organisation doesn't flow through org charts. It flows through relationships. And most of us have never deliberately audited ours.

Mapping Where You Are

One exercise I've found genuinely useful is the Relationship Radar.

The concept is simple. Draw a circle. Place yourself at the centre. Now plot the people you should be working with on the circle - not by title or reporting line, but by proximity. How close is your actual working relationship with each person?

An example of a relationship radar

The exercise only works if you're honest with yourself about your relationships when you complete your circle. For example, the QA lead you sync with daily will be close. The CFO you've met twice sits near the edge.

What you'll likely find is a cluster of familiar faces near the middle — and a ring of people on the outside who probably shouldn't be there.

The Gap Is the Point

The radar's real value isn't the map itself. It's the gap between where people are and where they should be.

Who are the stakeholders whose priorities you don't fully understand? Whose buy-in you'd need if you wanted to push through a meaningful change? Whose opinion shapes decisions before they ever reach you?

Those are the relationships worth investing in - and you should invest in them before you need something from them.

Proximity Is a Choice

Strong engineering leaders don't wait for relationships to form organically. They build them deliberately. Go for a regular coffee, ask a genuine question about someone's priorities and show curiosity about problems outside your immediate domain.

The radar won't tell you what to do. But it will tell you where to start and who you should be booking in a 1-1 with.

The new model outperforms other models when working on long-context tasks and more complex reasoning chains. It's great for long coding tasks and multi-file refactors, but it's also great for creating working solutions for other parts of the business too.

Maybe you're not convinced and still on the other side of the fence when it comes to AI. Regardless of what you think of the model benchmarks, the tools are good enough now that waiting to invest in AI is the riskier bet.

Getting Started

My team has been experimenting with AI a lot recently, and we're starting to see some great results. But if you're still new to the AI scene, and confused where to start it can be difficult to know what to do.

1. Get a Subscription!

Give your team Claude Code subscriptions to get them going!

Ensure they have a safe place to start exploring how to use the tool and play with how it works. Some engineers feel threatened by AI, whilst others over-trust the output. You can acknowledge this by framing Claude Code as a "junior pair programmer that needs review".

Avoid starting with a production-critical feature and instead begin experimenting on internal tools or fixing bugs instead.

$200/month for a license for developers will quickly pay itself back when they get used to the tools.

2. Knowledge Sharing

Give developers a way to share their learnings with one another, and start to build a shared context domain with the things that work within your repo. This could be through a shared Slack channel or regular catch ups. Encourage the team to talk about AI.

3. Guardrails

All the old rules to software development still apply.

Guardrails are incredibly important. The AI will inevitably go on tangents and will still write bloated code from time to time. AI isn't an excuse to start throwing out the rules of good code and PR hygiene.

Code should follow standard patterns, have explicit naming and organisation conventions, and a clear separation of concerns. PRs should still follow best practice rules. Keep code changes small. Keep writing tests. Keep reviewing code.

Tests aren't just a safety net, they're the feedback loop that keeps the agent honest. Consider utilising TDD to get the AI to write code to pass the tests.

Creating an AI bot (or using a tool like CodeRabbit) with your Github pull requests to check the PR against the standards will give you an extra line of defence, but human validation is still incredibly important.

4. Standards

Keep documenting your coding standards.

Create a standards document within your code repository that your team and your AI works from - covering things like database patterns, coding principles, security requirements. Better documentation of your code base will lead to more predictable results from your AI agents.

Full-stack ownership starts to become more natural with AI, you may find engineers moving out of their front end or back end specialities to work more efficiently; so it's important they (and their AI) can understand how to do that with this shared foundation.

Grow this document over time from the things that frustrate you.

5. Build Agent Skills

Once your team has the basics down, you can start building reusable skills for common tasks. For example, scaffolding a new service, writing tests for existing code, generating PR descriptions, or setting up a new feature end-to-end.

These are essentially prompt templates or task definitions that live in your repo alongside your standards document. They're how the compounding gains start to show up.

Make sure you are saving shared agent context with your PRs, so instead of every developer figuring out how to prompt the agent for a database migration, someone can write it once and everyone will benefit.

Conclusion

The cost of experimenting is low, the iteration cycles are fast, and the most expensive thing you can do right now is stall. Teams that are seeing 10x productivity gains didn't plan their way there — they started small and built confidence. The best time to start with AI was several months ago, the second best time is now.

Unless you see your business as a web only platform, there's a good chance you're going to need to make a choice early on about the technology used to build your app. This is a choice that will more than likely live as long as the company itself and will define your engineering team structure, development speed and budget for years to come. So it's important to get it right.

I've spent much of my career working with different companies and trying the latest and greatest technologies. Technology changes at a rapid pace, and often trends come and go quickly. But every so often you get something that sticks around.

React is a good example of one such technology. Before React, JavaScript frameworks felt like they were on rotation week by week with Angular, Dojo, MooTools, Ember, Knockout, Backbone, Meteor, Sencha and others being introduced and sometimes forgotten at rapid pace. Choices are still available in the web framework space - Vue.js and Svelte, for example - but with over 10 million developers worldwide using React, it's hard to ignore.

For a start up, there is often a business need to have a mobile app too. If you didn't want to commit to native, there's been a variety of frameworks that have come and gone in this space too - some which were incredibly difficult to work with or didn't feel like a native experience at all. Cordova, Ionic, Sencha Touch and jQuery Mobile spring to mind.

Today, the only real cross-platform competitors with staying power are React Native and Flutter, but their philosophies and ecosystems differ in ways that matter for startups.

React Native originally felt like a gateway for React developers to try mobile development, but lacked a lot of the tools and processes to make that journey easy. Like the frameworks I mentioned before, it also didn't feel very native - and as soon as you needed to build something outside of content you were hit with writing Swift or Kotlin anyway.

Over the last two years, the React Native and Expo teams have really pushed forward React Native as a viable technology for mobile apps and as of 2024, both Stack Overflow and Github stars show React Native is consistently among the top mobile frameworks, ahead of Flutter. Let's take a look at why.

Support

Improvements in what we can build in React Native have never been as rapid as they are now.

In 2024, the React Native team announced the New Architecture, which combined support for modern React features with direct access to native interfaces on mobile. This change has made apps feel far closer to the experience you'd expect from a Swift iOS or Kotlin Android application. The performance concerns that plagued early React Native applications are largely resolved with the New Architecture, with apps now achieving near-native performance while maintaining cross-platform benefits.

The Expo team themselves have been busy building a huge amount of libraries to make React Native development easier - from audio and video; to sensors and haptics; and security and storage functionality like biometrics and SQLite integrations.

One Codebase, Multiple Platforms

React Native allows developers to build apps with one codebase and release to multiple platforms - commonly iOS and Android, with Web support also possible with some extra effort. For cash-strapped startups, this resource efficiency is React Native's biggest advantage. Instead of hiring separate iOS and Android teams, you can build one team of JavaScript developers who can ship to both platforms.

But this isn't only about saving money - it's about speed. When you need to iterate quickly based on user feedback, having one codebase means one set of changes, instead of coordinating updates across multiple teams. However, a single codebase doesn't mean development time is completely halved for iOS and Android - each phone operating system has its own quirks - but it does mean that it is quicker to build in a single codebase and you are assured of feature parity between the two platforms. And if your idea pivots, then you only have one codebase to change.

Talent Accessibility

Like React, the talent pool for React Native developers is only growing. What was once a single developer adventure into app prototyping is now becoming a technology to seriously build full teams around. The concepts taken from React mean the doors are open to millions of developers to learn React Native quickly and efficiently.

Due to Flutter's different approach in this area, rendering everything through its own graphics engine, developers need to know how to program in Dart - a language with far fewer developers than JavaScript, making hiring more challenging and expensive for startups.

The Bottom Line

If your startup needs to prove product-market fit, React Native helps you move twice as fast with almost half the engineering spend. Companies like Discord, Shopify, Coinbase and Microsoft are big supporters of React Native citing development and iteration speeds as their main gains.

It's worth being clear: React Native is not a silver bullet. If your product is a 3D game or relies heavily on AR/VR then native code or specialized engines like Unity are still the best choice. But for the vast majority of startup apps - in the commerce, productivity, social, media business spaces - React Native provides near-native performance with far greater efficiency.

Flutter is strong, but React Native's ability to leverage existing React talent, its proven ecosystem, and Expo's investment make it the pragmatic choice for most startups.

It's often the small things that create the most friction. Minor issues compound in to major problems. This can be due to frequency multiplication, context switching penalties or motivation drain.

Here are some of the common areas I see friction in startups:

• Approval processes with either unnecessary steps or unclear criteria. For example, purchasing a license to a critical piece of software.

• Unclear decision making authority. When it's unclear who is the person who can actually say yes to a decision. Does it always have to be the founder or CEO, or can they hand off some decisions to other people?

• When requirements aren't locked down. When there's uncertainty within the team on what is actually being built and a real danger of scope creep beyond what is really important.

• Documentation that is hard to find. When it isn't clear which tool is the right place to document, processes get documented in different places or nowhere at all. They get lost.

• Information overload without clear prioritisation creates cognitive overload. When every task is shouting for attention at once it's hard for the team to understand what is important.

• Pull requests that take days to review. Either due to the right people being unavailable, or due to the size of the code change, or a lack of coding style guidelines.

Looking for Friction

You can spot the signs of friction within an organisation by looking for these signals:

• Tasks that people avoid or continuously delay
• Processes where people create informal workarounds
• Complaints that seem disproportionate to the size of the problem
• Things that require knowledge from one specific person to navigate

Removing Friction

If it isn't clear where the friction is in your company, and asking around hasn't helped, then a value stream mapping exercise can help you to understand the issue.

By carrying out this exercise you can map out your workflows and learn about the duration and effort it takes to complete each step. Walk through the steps with the people who actually do the work and look for steps that take a disproportionately long period of time, require multiple people or require re-work.

Focus on areas where there is wait time between activities or the same information needs to be gathered repeatedly are good candidates for removing friction.

The pattern across all these friction points is the transition cost - the overhead from moving between states. The highest-impact improvements often come from either eliminating these transitions entirely or making them so smooth they become invisible.

Where do you see friction in your organisation?

About Rate Limits

Often when we use third party services, they come with some kinds of limits for the amount you are able to use them. This is often to stop abuse of their APIs and protect them from suffering denial of service attacks or service misuse.

Most third party services offer different tiers which can help you adjust your limits for different situations. For example:

• Auth0 has a tiered system based on monthly active users that can be adjusted month-by-month based on usage.
• OpenAI has a comprehensive tiering system which scales with the amount you spend and the length of time you have had an account.
• Analytics tools like Mixpanel offer tiers based on the number of events tracked which can be scaled per tier.

Often catering for rate limits will involve picking a plan early or pre-paying for a certain amount of usage. While this seems helpful on the surface, it can result in needing to pay for more capacity than you actually need.

We were expecting to experience a short-lived spike in traffic which would result in us nearing our current plan limits. We'd created a couple of components which could be turned on when we were approaching a limit - but I wanted a way to also send myself and my team an alert during an unexpected spike so we could check everything was still running ok and potentially adjust our plans.

Slack Workflows

Slack provides great functionality for development teams to use automated messaging for observability and alerting. One of these tools is the workflow builder which allows you to POST data to an Slack webhook and that in turn can be used to post a message to a channel on your Slack organisation.

The message itself can include templated variables, emojis, @mentions and also a call to action button.

In my case, I wanted to alert how close I was to the limit, when it would be refreshed and include a link to a button that allowed me to configure the limit.

Locating Rate Limits

Different services provide different ways to retrieve rate limits. Lots of services like Auth0 and OpenAI include rate limit information in the response headers.

For example for OpenAI, they have comprehensive information on the state of your applications limits with fields such as:

• x-ratelimit-remaining-requests - remaining allowed requests in the current timeframe
• x-ratelimit-limit-requests - max number of allowed requests in the current timeframe
• x-ratelimit-reset-requests - time until the request rate timeframe resets
• x-ratelimit-reset-tokens - time until the token limit timeframe resets
• x-ratelimit-remaining-tokens - remaining allowed tokens in the current timeframe
• x-ratelimit-limit-tokens - max number of allowed tokens in the current timeframe

As another example, in Auth0 they are:

• x-ratelimit-remaining - remaining requests in the current time frame
• x-ratelimit-limit - remaining allowed requests in the current timeframe
• x-ratelimit-reset - unix timestamp of when the rate limit will reset.

POST to Webhook

In order to trigger the Slack workflow, we need to have a check in our code which reviews the limits and sends a message to Slack.

For example:

const ALERT_TRIGGER_AMOUNT = 200;
const rateRemaining = parseInt(headers["x-ratelimit-remaining-requests"] ?? 0, 10);
const rateMax = parseInt(headers["x-ratelimit-limit-requests"] ?? 0, 10);
const rateReset = headers["x-ratelimit-reset-requests"];

// check for rateReset in case we get a header with no values back so we don't send a false alert
if (rateReset && rateRemaining < rateMax - ALERT_TRIGGER_AMOUNT) {
  console.warn("Warning: approaching limit", JSON.stringify(limits));

  // post to Slack hook
  await fetch(process.env.SLACK_HOOK_URL ?? "", {
    method: "POST",
    body: JSON.stringify({ rateRemaining, rateMax, rateReset }),
  });
}

In this code we check the remaining requests and if it's under 200 of the remaining amount, we send an alert.

Creating a Slack Workflow

To create a workflow within Slack:

• On Slack desktop go to your organisation's name in the top left and click the chevron.
• Select Tools & Settings > Workflow Builder
• Click the "+ New" button in the top right and choose "Build Workflow"

Setting up a workflow

• For step 1 - choose an event, select "From a webhook".
• Enter the variables you wish to output in your message - e.g. rateRemaining, rateMax and rateReset.
• For step 2 - you can choose to output a message to a channel.

We can use the variables in our message like so:

🚨 Warning! Reaching Limit @channel

RATES: {{{{rateRemaining}}}} out of {{{{rateMax}}}} (reset in {{{{rateReset}}}})

• Once we've created our workflow, a webhook will be created which we can then call from our application to trigger the workflow.

And that's how it works.

Workflows are great for communicating monitors and lots of automated processes. For example, they can be used for:

• Deployment status updates with rollback buttons
• Database performance alerts with direct links to monitoring dashboards
• CI/CD pipeline failures with quick retry actions

What other ways could you use Slack Workflows to improve your proactive response rates at work?

The quick fix is to beef up the server through vertical scaling and buy yourself six months. The right fix is a four month microservices migration that will either save the company or kill it if you miss the deadline. Meanwhile your $2m client is demanding new features or they'll go elsewhere.

That's the kind of decision making situation Ben Horowitz captures in The Hard Thing About Hard Things. The book is a thoroughly insightful read on the challenges that face CEOs and a recurring theme throughout the book is the contrast between a peacetime CEO and a wartime CEO.

Peacetime usually occurs when a company has a large advantage against its competitors in its core market, and its market is growing. The company can focus on expanding the market and reinforcing its strengths.

Wartime usually occurs when a company is fending off an imminent existential threat from competition or a dramatic economic change.

The core philosophy in the book is that during peacetime, leaders must maximise and broaden the current opportunity using techniques to encourage broad-based creativity across diverse objectives. Whilst in wartime, the company must hit the target - survival depends on strict adherence to the defined mission.

Applying this Philosophy to CTOs

Reading this book led me to think about how this applies to CTOs. For many of the points made in the book about CEOs, they can be applied equally to CTOs. But there are some additional peacetime/wartime scenarios that are worth thinking about:

Strategy

• Peacetime CTO balances new feature development with platform improvements. Wartime CTO ships only features that directly impact survival metrics.
• Peacetime CTO invests in monitoring, automation processes and scalable infrastructure. Wartime CTO focuses on keeping the lights on with minimal viable infrastructure and manual processes if needed.
• Peacetime CTO plans for disaster recovery and business continuity. Wartime CTO takes on risk if it buys another day of survival.

Technology

• Peacetime CTO encourages experimentation with new technologies and proof of concepts. Wartime CTO sticks with known, boring technologies.
• Peacetime CTO may opt for a microservices architecture. Wartime CTO accepts a monolithic solution to ship faster.
• Peacetime CTO lets the team decide their technical stack. Wartime CTO makes immediate decisions based on the fastest outcome and avoids unnecessary rewrites and refactoring.
• Peacetime CTO allows for experimenting with the best tool for the job. Wartime CTO optimises for cost as if every penny were coming out of their own pocket.

Team

• Peacetime CTO guides the team through career development and improvement. Wartime CTO hires and fires without hesitation to get the right team.
• Peacetime CTO invests in developer experience and tooling. Wartime CTO tolerates developer friction if it means faster time to market.

Security

• Peacetime CTO implements comprehensive security frameworks and compliance protocols. Wartime CTO goes for "good enough" to not get breached while moving fast.

Scenarios

Wartime Scenarios

• A startup trying to find their product market fit with limited funding.
• An e-commerce platform during Black Friday with revenue on the line.
• A fintech startup racing to achieve compliance before funding runs out.
• A company during a viral growth spike that's breaking infrastructure.

Peacetime Scenarios:

• A dominant streaming platform, focusing on global infrastructure.
• A successful enterprise software company investing in developer productivity.
• A mature startup with product-market fit optimizing for long-term scalability.

To understand what mode you should be in, you need to be taking regular assessments of where your business is at internally and within the market. How much runway do you have? Who are your biggest competitors? Is your revenue trending upward?

The Adaptive CTO

To be an effective CTO you need to be skilled at recognising which mode you are in and adapting your leadership style accordingly.

Your technical judgement needs to be good enough to understand what are real vs perceived risks. You need to know when your team are pushing for improving technical debt that will actually cause pain vs code that is ugly but functional.

Communicating under pressure is key to being able to successfully operate. You'll need to translate complex technical issues into language understood by stakeholders and be comfortable with difficult conversations about trade-offs.

You'll also need to be an expert at reading team morale and understanding the teams' stress levels. You'll need to know when you can push them hard vs when you need to give them space. To do that, you need to build relationships and trust that persists through both good times and in times of crisis.

There are some practical exercises in scenario planning, decision training and communication style training that can help you to build up these skills. For example:

• If you had to cut costs by 50% tomorrow, what would you do?
• Make a technical decision with incomplete information
• Write a status update in the tones of "everything is under control" and "urgent action needed".

The best CTOs develop an instinctive ability to sense when the environment is shifting and proactively adjust their leadership style before being forced to by circumstances. If you look at your roadmap today, are you acting like it's peacetime or wartime? ...and are you absolutely sure you are in the right mode?

Please note: As an Amazon affiliate I earn from qualifying purchases.

In a previous role, I inherited a fragmented system written in five different languages, both monolith and microservices; and years of inconsistent tech choices including areas of the system that had been completely neglected.

Whilst there were bottlenecks between the teams, the individual team performance ranged from moderate to good - so it was important not to be disruptive to the current ways of working of those productive teams with top-down mandates or heavy-handed governance that teams would try to circumvent or avoid. It felt like every team was solving the same problems differently - and sometimes unknowingly repeating each other's mistakes.

In this post I cover my experiences introducing lightweight governance, ensuring consistent architecture, and deprecating legacy systems without stalling team velocity.

Architectural Consistency Through Standards, Not Mandates

With an inherited system lacking process and documentation, there's no time like the present to start righting some of the wrongs.

One of the common issues we came across was that we often didn't understand why a particular technical choice had been made. So we began by documenting any new decisions in an Architecture Decision Record. These ADRs captured any significant architectural decisions made, including the context and consequences of those decisions. These could later be referred to by developers in other teams - or our successors - so they can understand the reasoning for different approaches and decisions.

I also brought developers together to review the current architecture and focus on patterns we'd like to use to improve future work. Given the varied tech stack, enforcing tools wasn’t feasible. But we could standardise how we build, test and deploy to make it easier for developers to switch between teams and reduce the debate when building new systems by aligning our new solutions to choices that aligned with our principles.

Legacy-Innovation Balance via Strategic Modernization

With a growing business, it's inevitable that technical debt will start to build up and some areas of your product will become legacy systems. Legacy systems aren’t always bad - but unexamined legacy is risky. We evaluated each system: should it be retired, kept or re-written?

Event storming exercises allowed us to understand the key concepts of legacy systems and helped clarify business rules. Understanding what the priorities are with legacy systems will help you understand how to approach the problem.

The strangler fig pattern let us replace functionality incrementally by wrapping legacy systems with a facade layer. Once all functionality is moved, you can retire the old system completely. With this pattern you never have a "big bang" replacement that could break everything and you can validate the new architecture with small pieces before committing fully. If issues do arise, you can easily rollback and redirect traffic back to the legacy system.

Governance That Accelerates Rather Than Gates

It is difficult to introduce new governance methodologies to teams without resistance.

It's important to bring the team on the journey to maturity and help them understand why these processes need to be introduced. Rather than leading with "we need governance", start conversations around the problems your developers are already experiencing. "We keep having to fix the same security issues across teams" or "onboarding new developers takes forever because nothing is documented" resonates more than abstract governance concepts.

Getting the team involved in how they can be implemented can also help. Forming working groups where senior developers from different teams help design the standards with their collective wisdom will lead to better buy-in. When people help create the rules, they're more likely to follow them, and they can help evangelize them to their teams.

Teamwork makes the dreamwork!

• Shift-left practices such as including static analysis security scanning and basic compliance checks in pull request and deployment CI/CD workflows can help introduce governance early into your processes, and are something the team will quickly get used to as part of their everyday.
• Infrastructure as Code can help bring in and keep these additions consistent - we created deployment templates with security scanning built-in, making the secure path the easy path.
• Providing self-service platforms with the right guardrails and minimal friction can help in other areas, like setting up new repositories or managing production access.
• Keep approvals lightweight so you meet your auditing requirements without blocking the velocity of the team.

The goal for governance should be to make the secure, scalable golden path the easy one.

Measuring Outcomes

Like all parts of software development, it's important to measure the impact of the processes you put in place rather than the adherence and compliance to the process.

As well as measuring the maturity of your system and processes, measure how your development experience has changed. Some metrics to consider include: deployment frequency, lead time for changes, or incidents caused by architectural inconsistencies.

Are things getting better? If not, iterate.

Summary

As a CTO, you're responsible for guiding the platform to scale sustainably - without slowing the team down.

It's important to focus on practical, proven approaches like the ones described in this article to help you move the system forward, and ensure the team are invested in achieving the results you need.

Don't try to fix it all at once - start small. Introduce lightweight governance, document decisions and build the golden path that teams will want to follow. Start with one visible win such as documenting architectural decisions or adding security scanning to CI/CD, then measure impact before expanding governance practices to other areas. By maturing your systems gradually, your team will scale with it.

Where could you introduce clarity without friction this quarter?

Ah, you want to have your cake and eat it! Brilliant.

Moving fast is one of the most advantageous tools in a startup's toolbox. MVPs primarily exist to help you learn, not just to launch, and by moving fast you can initiate the user feedback loop quicker and test your all-important product market fit.

But often quality is sacrificed for speed and many startups find themselves falling in to a "rewrite trap" as they need to scale and try to grow.

There are some steps we can take as CTOs to help. Let's explore them together!

Get moving whilst your still building!

Choose a Sensible Core Tech Stack

Choose technologies that are proven and boring to you over the latest cutting-edge can help mitigate the risk of building applications. Optimise for developer experience and team familiarity over theoretical performance gains. By using technologies you and your team are already experts in, you've immediately removed a risk.

There's also a wealth of developers building in proven, common technologies which makes hiring cheaper and faster, and there's tons of tutorials and assistance online for when you get stuck.

Here's some boring technologies I usually go to:

• Languages: Node.js/Python/Go (base this on your team's expertise)
• Database: PostgreSQL/DynamoDB
• Cloud: AWS
• Front End: React / React Native (Expo)

Build vs. Buy

I've previously written in detail about Buy vs. Build strategies - and this all stands true at the MVP stage too.

Why put yourself through the additional stress and pain of building non-core functionality from scratch when software like Stripe and Auth0 exist?

Build only what differentiates your product, and make your decisions based on the question: "Is this our competitive advantage?". If no, buy it.

Making It Non-Throwaway

By moving fast with existing knowledge and buying non-core functionality, you'll have far more time to invest in the things that are important for maintainable, foundational software. Following these three foundational rules can help set you on the right path to success:

1. Database Design

Your database is almost always the hardest foundation to change later. Spend time understanding how data should be structured and coming up with a good database design.

• Avoid duplicating data unnecessarily, but don't over-normalize either. Well-defined data relationships prevent data integrity issues that compound as you scale.
• Understand how your application is using data and index your actual query patterns as well as your primary keys. A missing index will cause performance issues at surprisingly low user counts.
• Keep consistent naming patterns for field names - e.g. use user_id not userId. Inconsistency creates bugs that waste debugging time.
• Use data types that make sense for your product. Some decisions I typically make:
  • Use UUID for IDs.
  • Use timestamp for dates.
  • Use integer for money to avoid floating point math.
  • Regardless of your choices, note down your decisions and keep them consistent.

2. API Design

Ensure you have clean API boundaries - mobile and web apps will depend on these contracts.

• Have consistent REST/GraphQL patterns such as ensuring resource names are always nouns and plural.
• Utilise the proper HTTP methods for the task the API is performing.
• Use the proper HTTP status codes.
• Valid input at the boundary - don't let it into your system.

3. Good Logging

Ensure you have comprehensive logging so that you give yourself the information to be able to debug production issues from day one.

• Ensure your logs are structured with consistent fields.
• Use request tracing so you can follow flows through your stack.
• Track feature usage so you understand what areas of your product are the most valuable.
• Consider if you want to implement feature flags or A/B testing tools to test hypotheses quickly.

Other Considerations

• Follow the YAGNI principle. You Ain't Gonna Need It. Considering YAGNI with each of your decisions will assist in avoiding over-engineered solutions and spending too long on "what if" scenarios.
• Be ok with intentional technical debt. Document why certain decisions and compromises were made and they will need to change as you grow. For example, maybe for speed you start with a monolith rather than microservices. Microservices add complexity, more deployments and complicate service communication and orchestration. Decisions can be logged and tracked using a simple ADR (Architectural Decision Record).
• Planning for 10x growth is fine. Be reasonable with the amount of architectural decisions you make around scale. Instead, design for observability and change. If something starts to scale poorly, you will be well equipped to spot the warning signs. Then when you do have to worry about 100x growth, it's likely you will be better equipped to make the right decisions for your product.
• Set up the basics for good coding practices. With minimal effort, it's possible to get linting and static analysis in to the code base from day one. Using a Github Actions workflow on pull requests can quickly assess code quality and ensure you are moving in the right direction.
• Think about testing strategy. Consider basic unit/integration tests for core user journeys such as sign up flow and payment processing. These can validate that your MVP's functionality remains consistent through a period of constant change.

Summary

Following the steps I've detailed here you can create a great MVP version of your app by learning quickly about your product market fit whilst still giving your product - and team - room to grow.

Well done, your founder is impressed! Enjoy the cake! 🍰

I have been reflecting on my learnings from the past few years of working at previous startups. As well as being incredible experiences, there were also a lot of learnings. Finding our product market fit was tricky in what became a difficult market and we naturally made a few wrong turns before ultimately ending up in a better place. But I've learnt and grown so much from the role - a smooth sea never made a skilled sailor.

Every startup journey has its unique challenges and victories - these are some universal lessons I've picked up along the way. In no particular order, here are some of my thoughts:

• How will your experience enable people to tell stories? - To have a successful product, you need to have people talking about it. So take a step back and think about how a user will feel using the product and who they will want to tell about it. It can really help focus the mind on what the product should be in the first place.

• Be focused - Trying to do lots of things quickly at the same time leads to a poor product, so managing ambition is key. You're better off doing one thing really well. It can be difficult to kill features, but it's really important to do as it'll add drag to every decision and every pivot.

• Indulge one client - Start with a single client and work with them until they love your product. Get to the point where they can't live without your product and then start to expand. Lots of clients make lots of noise, and then once you have a mass of clients it's a lot harder to change and pivot.

• Make sure you are aligned on what success is - What does a successful business look like? Some businesses thrive on daily active users, whilst others just need a few power users who can't live without your product. Make sure the data your tracking and reporting on reflects these success metrics.

• Make it easy - Once you have your product market fit adding extra benefit can be hard. Sometimes the best way to benefit users is to make things easier to use. How can you cut down the time it takes for a user to go from point A to point B? Make it as simple as possible to use, reduce the possibility of drop-off.

Lessons learnt == Experience gained

• No is a decision, yes is a responsibility - It can be hard to say no, but if you never say no you will inevitably find yourself in situations you regret. You rarely regret saying no. So think about the things you do want to say yes to - what's going to make the most impact? And remember, yes leads to extra work, and it may not be the right time to do that work.

• Size doesn't matter - The bigger your company, the more impressive you sound - but working with large amounts of people adds challenges. Startups are meant to be small and nimble - so avoid huge growth spurts early on, and certainly add hires slowly and steadily. You likely need less people than you think.

• Don't break the flow - I found I was working far better in the early hours of the evening - as that's when I could actually focus my job without distractions. Interruptions break your concentration, they stop you doing the job you need to do. I noticed that our velocity was dropping, so we agreed to move as many meetings as we could to the mornings so developers had their afternoons free. I also looked at what meetings could be handled asynchronously instead - for example, doing some stand-ups as Slack messages or recording Looms of things you need people to watch but not participate in means they can fit them around their work day.

• Everyone contributes - When you have a small team, you need contributors not delegators - including the leaders. Personally, I'm not afraid to get stuck in with whatever job needs doing - even if it isn't my job at all. It helps you understand the hires you will need to eventually make as you are doing jobs you will one day need to hire for. Delegators often love meetings as that's where they feel important - and their meetings have a habit of spawning more meetings - which cause even more interruptions.

• Trust your gut... and the data - Often your gut is right, and if you love your product your audience will also love it. But - if the data is overwhelming, then kicking off a quick experiment to explore alternatives is totally worth the damage to your ego.

I've always wanted to be able to create my own SVGs but the barrier to entry has always felt too high - as soon as we start having to deal with bezier curves I feel like I'm way out of my depth. This weekend, I finally bit the bullet and downloaded Inkscape, and discovered that it's actually really straightforward to get good results and you don't have to get bogged down with math. Sharing's caring (and I wanted to write notes) - so here's some of the things I have learnt.

Art by Inkonic from the Inkspace home page - I wish I could draw this well!

Keyboard Commands > Interface

There are a lot of options in Inkscape - it's obviously very powerful. I've been using keyboard shortcuts as much as possible as it's easier to navigate than multiple menus. So a lot of the advice here revolves around which keys to use.

Zooming In

So I loaded Inkscape and the first thing that struck me was my canvas was really far away! I couldn't see anything. The usual keyboard shortcuts I'd use in other programs didn't work. It was clear I was going to have to learn new ones.

• By far the most useful, pressing z + 5 zooms the canvas to fit your window size - so you can see everything in one go.
• z + + zooms in and z + - zooms out.

Drawing Something

If you want to draw a circle (press e for ellipse) or a square (r for rectangle) there are some nice, easy to understand tools to help you do that. But if you want to draw a custom shape, you're going to need to work with paths.

The pen tool (keyboard shortcut b) help you draw paths and selecting the "BSpline path" option from the top "Move" menu means you can click away adding as many nodes as you want without having to worry about your curves. The tool will do it's best to smooth out your lines for you letting you just worry about where your shape is going. Double click or hit enter to finish the path.

It'll probably look a little rough if you've used a lot of nodes and you may want a more curved look. Once your path is finished you can hit command/ctrl and l to simplify your path which has a nice side effect of making your path look more natural!

Transform

Within Inkscape, you can scale and rotate your paths and objects. Hitting shift, command/ctrl and m will bring up the transformation panel. I guess m stands for matrix?

It's a bit weird compared to changing values in CSS or other tools - once the transformation is applied, you need to think from zero again as all future actions are additive. For example, in CSS if I wanted to rotate an element I'd use 90deg, and to change it I may update it to 105deg. In Inkscape if I originally did 90deg and wanted the same change, I'd need to apply 15deg to get the same result.

To get a better idea of positioning on your page, View > Page Grid is a nice way to get a grid and then you can line things up.

Symmetry

There's a few ways to achieve symmetry in Inkscape.

There is a mirror symmetry mode where you can mirror your path. As a beginner, I've struggled a bit with this when it comes to placement.

Instead, I've had better success with Duplicate (command/ctrl + d). Once you have a clone, pressing h will horizontally flip your selected object, and v will vertically flip it.

Once you've duplicated, mirrored your path and moved it in to the right place you'll probably be left with some sharp bits where the two objects meet. Inkscape has a really nice tool to help with this.

First, select the Node tool (keyboard shortcut n) and shift and select both paths. Then shift select the end node of each path that you would like to join. There press the 'Join selected nodes' menu item in the top menu. This will join your paths and smooth them out.

In case mirror symettry is your thing, you can try this by going to Path > Path Effects, add Mirror Symmetry effect and then Path > Object to Path to convert it to a path.

Cropping

Once you have made your image, you can reduce the size of your viewport by selecting your objects and pressing shift, command/ctrl + r, or go to the Edit menu and hit "Resize Page to Selection".

Exporting a Single Layer

By default, Inkscape will save your SVG with all the layers you've created - even the hidden ones. Which is good - you probably wanted them for later.

But when you do only want to keep certain objects, in the Layers panel select the layer you want to export and all the objects in that layer. Go to File > Export (or shift, command/ctrl + e) and choose the 'Selection' tab. Tick the box that says "Exported Selected Only", choose "Plain SVG" as the file format and then hit "Export". You can SVGOMG the results for smaller file sizes.

We're Just Getting Started!

I hope you've found these tips useful. I'm going to continue playing around with Inkscape, so if there's any useful beginner tips you think I should know - please drop me a message!

SOC 2 certification is achieved by proving that certain security controls are in place and working as intended. While this sounds straightforward, the reality involves months of preparation, company-wide coordination, and careful evidence collection that many growing companies underestimate.

In this article, I share my experiences with SOC2 and the things I learnt along the way.

Type 1 vs Type 2

Firstly, there are two types of SOC 2 certification. Type 1 is promising the things you will do and Type 2 is proving you did them. Most companies expect their vendors to be Type 2 compliant, but it can take months to be ready for audit and then further months to collect evidence to prove you are compliant. A SOC 2 Type 2 audit period of 6 months or higher is generally considered acceptable - although it is possible to get shorter certificates.

To Infinity And Beyond

Once you are SOC 2 compliant, you need to stay SOC2 compliant. You will be audited every year, so it's important to put the checks and balances in place to ensure as you grow you will remain compliant. And you'll need an annual refresh for documentation and evidence.

Trust Criteria

There are five different trust criteria for SOC2:

• Security
• Availability
• Confidentiality
• Processing Integrity
• Privacy

Important: You do not need to be compliant in all five trust criteria! In fact most companies are not!

Only security is compulsory.

Availability and Confidentiality trust criteria are also common. Processing Integrity and Privacy require more rigorous checks and more expensive processes and monitoring.

It's critical to carefully scope your audit and understand what your business needs. Over-scoping can easily double your compliance burden.

It CANNOT Be Soloed

Let me repeat. It cannot be soloed (unless you are a company of 1). SOC 2 requires the whole company to take it seriously. It is everybody's responsibility to keep the company secure, it cannot be one person's responsibility.

There are parts of SOC 2 which are operations, HR, recruitment and even the board of directors. Some of the toughest parts of achieving compliance are trying to get buy in from the entire business.

Processes

As a CTO, there are processes you can put in place early to make passing the audit easier later on:

• A SDLC process
• CI/CD pipelines
• Mandatory Pull Request Reviews
• Linking JIRA Tickets to PRs
• Security Scanning (SonarCloud makes this easy)
• Use a Password Manager

Cheat Mode

I've carried out SOC2 processes in spreadsheets and also with specialist compliance tools such as SecFix, Drata and Vanta. The specialist tools seem expensive. But please trust me, they are more than worth it. These tools often allow you to automate certain processes to prove compliance, and to store your compliance data in a single place.

As I mentioned, these tools can be pricey - but if you shop around you can haggle a decent price. They are all fairly level in terms of feature set, so you can use this to your advantage.

Audits

Start collecting evidence from day one of your audit period, not months in. I've seen companies scramble to find 6+ months of missing evidence. This is not the way. Ensure you are collecting and know where to find your evidence from the start.

As well as tooling, you'll also need to pay for an auditor. A lot of compliance tools have recommended auditors who know their tooling well.

Toward the end of the audit period, your auditors will want to interview the team and look at the evidence you have gathered. This is a whole team effort, and auditors will want to see that the whole company is interested in security - not just technology.

It's not a Pass or Fail

Unlike a driving test, you cannot pass or fail a SOC 2 audit. You can do badly in it, but an auditor won't fail you. Instead, at the end of an audit the SOC2 auditor will list the gaps that they have found and you will be given a chance to respond to them. This report will be what you share whenever a client, customer or vendor requests it.

Whilst it's not great news for an auditor to find some gaps, it is common. I've seen many SOC2 reports with observations of controls that were not passing.

The important factor is to ensure you don't repeatedly fail for the same issues. Make sure you budget for remediation time. Even with good preparation, you'll likely need to address some findings post-audit.

Keep an Eye on Onboarding

In my experience the area that is most likely to fail an audit is the Employee Onboarding experience. A new employee who hasn't signed the code of conduct, the acceptable use policy, or completed the mandatory security training can catch you out. And unfortunately, an auditor has to report it.

What about ISO 27001?

While SOC 2 primarily focuses on proving you've implemented security controls that protect customer data, ISO 27001 also asks you to prove you have an operational information security management system (ISMS) in place to manage your InfoSec program on a continual basis.

In my experience, SOC 2 is a good stepping stone to ISO 27001 certification. ISO 27001 seems to be better regarded as a compliance standard in Europe, whilst SOC 2 is more popular in the US.

Conclusion

As you can see from this article, SOC 2 compliance is quite involved and requires a lot of planning and preparation. It's valuable once complete, but ensure you are prepared for the investment it carries.

Tool sprawl is the accumulation of multiple tools which serve the same or similar purposes. Throughout any company's lifetime it's not uncommon to have disconnected departments using similar tools without even realising it. Suddenly you are paying for multiple SaaS contracts and your costs have doubled (or worse). Left unchecked, these costs can quietly bleed thousands from your burn rate - money that could be better spent on product development or growth.

Start with Monthly Plans

SaaS organisations are always in a hurry to get you to sign annual (or longer) contracts to lock you in. These deals look attractive as over the long term they will likely save you money. However you lose flexibility - and when your company is still figuring out its identity locking in to a service prematurely may result in spend in an area you no longer need to be spending in.

Enterprise plans often come with premium price tags — justified by SLAs (Service Level Agreements) that promise guaranteed uptime, priority support, and faster response times. But in the early stages of your startup, you may not actually need these guarantees.

Before locking yourself into a costly Enterprise contract, evaluate whether the promised SLAs are truly critical to your team’s success. Many smaller startups can operate perfectly well on standard or pro-tier plans.

Take a moment to review the service’s status page (most providers have one) and check their historical uptime and incident frequency. A well-run SaaS company with a solid track record may offer sufficient reliability without the need for an expensive support contract.

Some tools (like Auth0 and Sentry) allow you to adjust your expenses month by month which can help you save extra money during quieter months (e.g. if your app gets more traffic around the holiday season). It's also worth noting that most tools won't switch you off when you exceed capacity and provide a short period of grace so you can adjust your requirements.

SaaS Auditing

Schedule quarterly reviews of all your subscriptions. This isn't just about finding forgotten tools - it's about evaluating whether each service still provides value proportional to its cost. Create a simple scoring system: usage frequency, business impact, and cost per user or transaction. Tools that score poorly across these metrics are candidates for replacement or elimination.

During these audits, also check for seat optimisation. Many SaaS tools charge per user, and it's common to have inactive accounts for former employees or users who've moved to different roles. A monthly seat audit can save significant money over time.

Capacity Tracking

One technique I use to manage non-seat SaaS tools is to track the capacity usage of our vendors so I can record and see how usage varies month on month. This provides predictability for the business, ensures we remain on the right plans and gives me the benefit of negotiating early when services need to scale.

For example:

Create a Spreadsheet

Everyone's favourite friend - the Excel / Google Sheets spreadsheet. As much as we mock it, it allows you to stay on top of the costs for your tools early on.

I tend to track a list of the tools, departments, cost type, frequency and how much is estimated/spent per month. Cost type is either Cost of Goods - costs directly tied to your product's delivery like the app, infrastructure or APIs; or Expenses which covers tools used for operations.

Encourage a "New Tool" Process

While you don't want to slow down your startup, having a short process that requires an employee to request a tool before it can be expensed ensures that the usage of the tool has been well thought out and keeps adoption disciplined.

Look out for Freebies

If you are a startup, freebies are everywhere. You just need to look for them. Often your startup investors will be able to provide codes and links to get you started. The cloud platforms are particularly keen on AI startups at the moment and may have additional discounts for them.

Here are some of the discounts available at the time of writing:

• AWS Activate offers a wide range of benefits for startups - including up to $100k in AWS credits and discounts on other tools.
• Github offers a year of free Enterprise access for up to 20 seats.
• Google offers a number of programs for the Google Cloud Platform.
• Microsoft also offer a number of startup discounts for Azure.
• Miro offers a $1000 startup credit - which is roughly a year of Miro access for a small team.
• Retool is great for quickly building admin panels for your application, and offers startup credits up to $60k.
• Stripe offer a startup program with access to financial benefits and experts to help you grow.
• Some investors have their own portals for providing additional discounts, so do speak to them.

Don't forget about open source alternatives either. Tools like Grafana, Supabase, and PostHog offer robust open source versions that can significantly reduce costs while you're building product-market fit.

Live a Task (and Look to Automate) Before Hiring

Hiring people is expensive, and hiring the wrong people is even more expensive. In a startup it's essential to get the right fit. Before hiring for a role to fulfill a task, actually carry out the task yourself so you can understand the skills you need to make the right hire. And if at all possible, use Saas tools to automate the task rather than hiring.

Look at tools like Zapier to easily automate workflows between SaaS tools. Sometimes a $50/month automation tool can replace a $5000/month hire, at least in the early stages.

Negotiate Everything

Don't accept the first price you see. Most SaaS companies have flexibility, especially for annual contracts or when you're close to moving to a higher tier. Come prepared with usage data, competitor pricing, and a clear understanding of your growth trajectory. In the past I've managed to get discounts that have even surprised me simply by asking multiple times.

For critical tools, consider negotiating contract terms beyond just price: cancellation clauses, feature guarantees, and support SLAs can be just as valuable as discounts.

In Summary

SaaS cost management isn't about being cheap - it's about being intentional.

Every tool should earn its place in your stack through clear value delivery. Your startup is likely moving at 100mph, so new SaaS tools are introduced quickly and frequently. But regular audits, careful capacity planning, and strategic consolidation will keep your costs predictable and your team productive.

Remember that the goal isn't to minimize SaaS spend at all costs, but to ensure every dollar spent contributes meaningfully to your business outcomes. A well-chosen $200/month tool that saves 10 hours of developer time is infinitely more valuable than a free alternative that creates friction and technical debt.

By implementing these practices early you'll keep ahead of the tool sprawl trap that catches so many young and growing businesses.

Some companies also interchangeably use the CTO and VP, Engineering job roles. Bloom employed me as a VP, Engineering but my role often overlapped into areas outside engineering - such as data, security, vision, finance and stakeholder management.

After thinking about it some more, I believe there are multiple archetypes of CTO, and as a company evolves the CTO job role does too. Your mileage may vary - but in my mind the CTO job is actually six different roles depending on the stage of the company.

Not every CTO walks in a straight line through these different archetypes. Some CTOs move fluidly between stages, while others find their niche. One might be a wizard at the early stage prototyping but step aside once the team hits 100 engineers. The most effective CTOs are those who know when to evolve, when to stay in their lane, and when to hand off the baton.

1. The "Let's Get Started" CTO

The "Let's Get Started" CTO is often either the technical co-founder or the first technical member of the team. When they join, there isn't a product - just an idea. The company is likely in Pre-Seed or Seed stage.

This CTO will:

• Make foundational technology choices that will impact the company for years.
• Be a capable, self-starting technical engineer who can build working prototypes and pivot quickly to change, balancing technical debt with speed of delivery.
• Prioritise Time to Market and finding Product Market Fit as these are critical for the business.
• Be capable of working in multiple technical areas (such as infrastructure, front end, back end, IT, compliance).
• Have a keen eye for first hires and be unafraid to make changes when personnel aren't working out.
• Manage individual contributors.
• Be the technical voice in fundraising conversations with investors.

2. The "Early Stage" CTO

After the product has launched and started to gain traction, the company will begin to grow and the CTO role will too. Usually this occurs around Seed to Series A.

As the company will need further focus on process and team building, there may be a decision on whether the existing CTO continues in the role, or if they become a lead engineer.

This CTO will:

• Have a strategy for how the technical side of the company will develop.
• Be responsible for designing the processes that will define the company's technical culture and outputs.
• Delegate! They need to be capable of managing multiple teams and delegating day-to-day control to a senior within the team.
• Establish metrics and KPIs aligned with business goals - e.g. uptime percentage, time-to-hire etc
• Take part in budgets and recruitment processes.
• Build relationships with key customers for technical discussions.
• Balance longer term strategy with day to day requirements.
• Ensure the system remains live and operational - and handle and resolve any downtime incidents.
• Spend a lot less time in the codebase, and avoid the critical path!

3. The Scaling CTO

Now the business has a clear Product Market Fit, the momentum will move to onboarding customers in the product rapidly.

Business focus moves to uptime and scalability. The codebase is a distant memory and the CTO's focus is on strategy, growing the business and technical architecture.

This CTO will:

• Understand and have a strategy for how to scale the architecture for growth.
• Build partnerships with key technology vendors.
• Have a hiring plan that allows for developer growth.
• Implement incident response and on-call rotations.
• Understand the security and data implications of having larger "enterprise" clients.
• Influence the product roadmap based on technical constraints and opportunities.

4. The Expansion CTO

With customers onboarded, the company will look to new paths for expansion - this could be acquiring other companies, adding new products or moving to other markets.

At this point the CTO is fully in the strategy and business side of work. They will need to ensure they have the right set of reports and leads to ensure they are not disconnected from how the engineering team is performing.

This CTO will:

• Standardise the technology stack across multiple teams and establish technology governance frameworks for multiple teams/products.
• Create centers of excellence for specialized technical areas.
• Have an established set of contacts and relationships that they can call upon to help growth.
• Have a deeper understanding of the competition and have expertise in what to look for during acquisition due diligence.
• Manage technical integration of acquisitions.
• Navigate regulatory requirements across different markets (data residency, compliance variations)

5. The Pre-Exit CTO

At some point, the goal of many companies becomes to sell for big bucks through acquisition. In order to do this, the CTO will need to bulk up the areas which make the company attractive to buyers.

This CTO will:

• Articulate the technical vision and roadmap to potential acquirers.
• Build relationships with technical leaders at potential acquiring companies.
• Prepare comprehensive technical documentation for due diligence.
• Ensure intellectual property is properly documented and protected.
• Build redundancy in key technical roles to reduce "key person risk".
• Demonstrate technical competitive advantages and moats.
• Prepare for technical presentations to acquirer boards/leadership teams.
• Ensure the technical team can operate independently during transition periods.

6. The Interim/Turnaround CTO

No process is perfect - and sometimes a company will hit unexpected roadblocks or find themselves without a technical leader.

Some CTOs specialise in coming into struggling companies at any stage to fix technical debt, reorganize teams, or prepare for acquisition. These are often experienced technical leaders who thrive in high-pressure situations and can quickly assess what's broken.

This CTO will:

• Conduct rapid technical audits to identify critical issues and prioritize fixes.
• Make tough decisions about legacy systems, technical debt, and underperforming team members.
• Rebuild engineering culture and restore confidence in technical delivery.
• Establish emergency processes to stabilize systems and prevent further outages.
• Communicate transparently with stakeholders about technical realities and timelines.
• Bring in specialised contractors or consultants to address skill gaps quickly.
• Implement interim solutions while planning longer-term architectural improvements.
• Often serve as a bridge leader while the company searches for a permanent CTO.
• Balance urgent firefighting with building sustainable foundations for future growth.

--

The CTO role is ultimately about matching technical leadership to business needs. Early-stage companies need hands-on builders; scaling companies need process architects; and expanding companies need strategic operators.

Transitions often hinge on inflection points such as raising a fund round, product market fit, the need for velocity or scale, or a re-org or acquisition. As a CTO growing with your company, proactive upskilling is key - learning to delegate and document, how to manage managers and how to embrace product and business metrics and goals - not just engineering ones.

When there's alignment between what the business requires and what the CTO is focused on, then the company will be primed for success. As a CTO, whether you evolve through all the stages or specialise in your sweet spot, success comes from being honest about where you add the most value - and where you don't. Being a great CTO isn't about holding the title. It's about recognizing what your company needs at its current stage - and whether you're the best person to lead it there.

What do you think about the stages listed here? Every company is different and some companies do activities in different orders. What is your experience with CTO roles across companies - is there anything you feel is missing?

Three qualities about all the tools listed here:

• They are all online tools - no downloads needed
• None require you to sign up to register
• The functionality I mention is free (some are ad-supported, but it's not aggressive)

1. Coolors

Coolors has an excellent list of colour palettes to help give your web site or app a unique look. Simply find a palette set you like and hover over the colours to get the hex values - or export them to CSS variables or another format to use them all in your app.

Some of my favourite palettes include this beach sunset combo and this blue-green-orange set

A great list of colour palettes

2. Squoosh.app

Image resize and compression has never been so easy than with Squoosh.app. As well as file uploads, Squoosh also supports pasting an image directly in - which I find extremely helpful when taking screenshots for this blog.

Squoosh runs its compression algorithms in the browser, so you don't send data to the server - and it can continue to process images when your connection is offline. It supports all the major image formats and has options for resizing, reducing colours and compression techniques directly in the app.

Image compression made easy

3. Lucide

Getting a decent set of royalty-free SVG icons on the Internet can be a bit of a challenge, but Lucide has come to the rescue! As well as providing a comprehensive set of over 1,500 icons, Lucide has a React npm library which allows you to easily add SVG icons to your project, and ensure you only include the icons you use in your final app bundle size.

Lucide has over 1,500 icons!

4. SVGOMG

Sometimes we can get the SVGs we need from an icon library and need to use a different source or make our own. SVGOMG's Optimizer is great for cutting away unneeded instructions and data. You cna adjust the compression level with the in-app interface and see a real-time preview to check the quality of your SVG output.

5. PhotoPea

Editing an image or photo means a plethora of different tool options - and rarely are any of them as good as Adobe's original Photoshop. But Photoshop costs money, and this is a list of free tools! Enter PhotoPea - a Photoshop like experience available online without the expense, and without the requirement to sign up.

Photopea supports all the usual PhotoShop file formats, and can handle most of the actions and edits you would typically associate with PhotoShop.

A Photoshop-like experience

So there you go - five of my favourites. Let me know if you have any excellent recommendations to add to the list!

My approach in this scenario is simple: build what makes you unique, buy everything else.

If a feature was core to our competitive advantage - the thing that would make customers choose us over competitors - we built it. For functionality where solutions already existed or where we were dealing with table stakes functionality that users take for granted such as login, we looked for existing solutions.

Making the Decision

If there is any doubt on what to build vs. buy, it's always worth looking back to the objectives of the business and considering how this decision would affect them. It was far more important to get our product out in the market and being used by our customers, so we made choices that reflected that.

Buying software comes with its own complications. Often there are multiple tools that can help you achieve your goals. Some lightweight SWOT analysis can help you get a handle on what's needed, but it's also worth looking at what your team have used before and factoring that in to the choice made. Why spend weeks learning a new authentication system when we could integrate Auth0 in a day?

The biggest trap with decision making can be analysis paralysis. In start up world, time is everything - so sometimes you just have to make your best guess with the information you have and move forward.

When It Doesn't Work Out

Not every decision can be perfect. We once chose a third-party service that seemed ideal but later became a problem as we learnt more about how our product was being used. Something that seemed fit for purpose during our SWOT analysis became a bottleneck for our team.

With hindsight, we could have done further testing in this area - but our product was also still evolving in to it's current form and we were still learning how our users would interact with the product so it's difficult to accurately surmise that we would have found the problem.

As your startup and product grows, and you understand more about how your users are using your product, you can start to unpick some of those initial choices that didn't work out.

The Real Win

Taking a Buy vs. Build mentality on each software decision worked really well for us. The biggest benefit wasn't just time saved - it was focus gained. By outsourcing the mundane stuff, our team could obsess over the features that actually mattered to users. We became experts in our domain instead of generalists trying to solve every problem.

Start with what makes you different. Everything else can probably be bought.

AI is improving by leaps and bounds week after week. Everyone’s trying to bolt AI onto their product. But AI only adds value when it’s solving the right problem.

One way I've explored using GenAI is offering a scalable, inexpensive conversational experience - the kind that could support engaging advisor-like interactions.

To test this I quickly prototyped a ChatGPT-based experience with an elaborate prompt. What became apparent was that while the AI could generate responses, the quality was inconsistent, and - more importantly - users were hesitant to open up in a computer-mediated interaction. AI lacks the genuine feeling of empathy you find talking with a human.

The truth is - AI isn't a magic bullet.

Time for a Rethink

It became clear that while AI had potential, I hadn’t yet aligned its capabilities with a well-defined user need.

Once I revisited the original problem I was trying to solve - offering a superior service to our users - it was clear the initial direction wasn’t fully aligned with the problem. The breakthrough came when I started asking 'what does our team actually need to offer a superior service?' instead of 'what can AI do?'

Rather than AI replacing the capabilities within the team, we pivoted toward using AI to amplify our teams' capabilities instead. Our goal became to equip them with superpowers.

Conversations with users would still be human-to-human, but supported by Natural Language Processing, integrated services, and content resources.

A huge number of different approaches become available when you start thinking about how you can give superpowers to your team. In thinking through potential applications, I focused on ideas that balanced feasibility, usefulness to advisors, and user trust. Possible approaches could include:

• Summarising conversation history to reduce the prep time before a session.
• Automated note-taking during conversations.
• Surface real-time sentiment cues to support advisor awareness.
• Suggest relevant exercises and draw from anonymized insights or content.
• Progress tracking and visualisation across multiple sessions.
• Automate scheduling and follow-up reminders based on the conversation outcomes.

To prioritise and understand how we should approach it, we considered how it was adding business value and the feasibility of building and supporting it.

A Better AI Product

It probably won't strike you as a surprise that taking a problem-first approach for AI led to far better user satisfaction and higher engagement.

As tempting as it is to go all-in on AI and be blinded by the latest and greatest release, be sure to:

• Quickly prototype ideas and test things out.
• Be willing to fail and pivot.
• Remember the reason your product exists in the first place.

With these things in mind, you'll create a better problem-first AI experience.

Have you tried to integrate AI into a human-first workflow? I'd love to hear what worked for you.

On Friday night, I performed an improv comedy murder mystery at the Brighton Fringe as part of the troupe "Who Killed The Plot". We played to a sold out audience who had paid £8 each to be there. The audience really vibed with our comedy and the show went better than any of us could have expected.

On stage at the Brighton Fringe

I've had an interesting journey to get to this point. Two years ago, I had never done any improvised speaking before. I never did drama or music at school. I had been on stage to deliver multiple rehearsed technical talks - but the thought of being on stage without the safety of a script or a powerpoint deck terrified me. Now I'm quite happy to get on stage to speak, act, sing an improvised song or even do some freestyle rap.

I originally started going to improv to improve my confidence when speaking to investors. I wanted to feel confident when I was talking about what we were doing at Bloom without needing to stick to a script. I found an improv community near where I live called Dingbats Improv and decided to go along. From the very first workshop I realised I had found something that was fun, a great way to remove any stress from the day and completely different from anything else I'd ever done.

As well as being a lot of fun, Improv has taught me many life skills and ways to be a better leader, a better partner and a better person:

Yes And

"Yes And" means accepting your scene partners offer and building upon it. You wanted your scene partner to feel supported, and you want to make them look as good as possible on stage.

As a leader, this same technique applies to building a strong team. When the team have suggestions it's important to value their contribution and then expand or redirect, rather than shutting them down. This creates a culture where people feel heard and have psychological safety - which results in more creative problem solving and more willingness to share innovative ideas.

For example, if an engineer suggests a change in process or architecture it may not be the right timing now, but there may be an element that you can start incorporating early on and schedule time to review the remainder at a later date. This will preserve their enthusiasm while acknowledging the current constraints. Later on, when you do the comprehensive review, they will be even more engaged because they saw that their input genuinely mattered.

Confidence

Improv requires performers to make bold choices without hesitation. If you wait too long to make a choice, the moment has passed and you have missed the laugh. Improv teaches you to trust your instincts and fully commit to the decisions you make.

In leadership, it's very easy to put off a decision or end up in analysis paralysis. Without hindsight, it's often impossible to know what is the right choice - we are just left with best guesses. We have to instill confidence in our team to take chances with decisions and.. embrace failure.

Embrace Failure

In Improv, mistakes are often celebrated as opportunities. Often the funniest laughs come from when things go wrong - like when someone badly mimes an action or something unexpected happens.

In technology, things also go wrong from time to time, and while it's not funny when it happens in the world of work, having the ability to remain calm and reframe failures is crucial. Think through how a failure can become an opportunity to make something greater.

Creating a team environment where people aren't afraid to fail encourages innovation and experimentation. When team members know that an unsuccessful attempt won't be met with blame but rather with curiosity and support, they're more willing to propose bold ideas and take calculated risks. Just make sure you are learning from your failures and building those lessons into your process.

Active Listening

Improv scenes rely on truly listening to your scene partners rather than waiting to speak. In leadership, this means giving full attention to the team and the problems you are trying to fix. Being present in conversations, asking clarifying questions and responding to what's happening rather than sticking to the path you originally thought was best. Active listening will help you build stronger relationships with your team and lead to making better decisions.

Reading the Room

As an improviser, you need to have awareness of everything that is going on on-stage. Having an understanding of group dynamics and your teams' emotional states is also an important skill of being a leader.

Quite often when we make a decision as a group we may have a developer or designer who says they are ok, but actually they are unhappy with the decision that has been made. Perhaps they have some concerns with the approach, or a better understanding of how to be successful, or maybe they don't believe in the idea yet. Being able to sense those moments will allow you to hone in on these situations and ultimately lead to better team dynamics and leadership.

Storytelling

Having to make stories up all the time on stage lends itself well to being able to tell narratives in the work place. It's helped me develop my skills in communicating my vision and explain the story about the technology solutions we are building. It's changed how I can communicate with non-technical stakeholders and how I can inspire others.

Hopefully this article has given you some insights in to how Improv has helped me improve, and how these ideas relate to being a better leader. Maybe it has sparked your curiosity in to trying some of these techniques yourself. There are many improv workshops and classes out there, just a Google away. Good luck!

And if you are already in an Improv group - try my improv suggestion generator!

At LifeWorks, when the pandemic hit we were in the middle of delivering a large and complex multi-team architecture change which was closely tied to a client obligation. The financial implications of missing our deadline were too high. We needed to make remote working work.

More recently teams have been moving back toward office working - usually in a hybrid situation. There is certainly something for face-to-face time and getting to know your team, and in the early stages of a startup where time is critical being able to make quick decisions.

The Remote-First Mindset

Having a large team working remotely means you need to pay far closer attention to the ways of working and the culture of the team. It's very easy for someone to feel disconnected from the business decisions that may affect them.

Documentation is king

I'm a big evangelist for having great documentation. New starters should feel supported from the start, and everyone should know where or who to go to if they need help or support. Taking extra time to make sure your systems are explained can help save a lot of time later on.

• Keep a decision log which documents the choices that have been made whilst building your system. This can help future team mates understand the why a architectural or technical choice was made, and it also gives an opportunity to document what the potential technical debt issues would be with such a choice.
• Ensure your onboarding documentation is clear and guides team mates on how to set up their systems to get up and running quickly.
• Keep an easy to access document on table stakes knowledge - such as how your servers are configured, what the responsibilities are of each service or repository and keep high level architecture diagrams and technical roadmap decisions.
• Keep a glossary of terms that are internal to your business or specialist knowledge for your subject domain.

Async

Asynchronous communication is where one team member asks for, or provides some information, and then there is a time lag before the recipients take in the information and offer their responses. Usual examples of this are Slack or email.

As a designer, developer or other do-er there are lots of benefits to this approach - you can plan your day to ensure you have good chunks of focus time and pick up correspondence at set intervals.

Asynchronous video is also another great tool for communicating more effectively with your team. Sometimes our messages get misunderstood in text, but we can clearly convey what we want and map our words to pictures with a video. Your team mates can find a time that works well for them to watch it.

In the development world, we also found having an agreed time where pull requests would be reviewed helped us ensure work did not get blocked and set expectations around how quickly code changes would happen.

Managing Time Zones

Timezones (and by extension country-specific bank holidays) can add an extra complication to the way you manage remote teams.

At LifeWorks, most of my 100+ engineering team were located in the UK or Europe and we worked in way where hours were adjusted around a set of base times (between 10am - 4pm UTC). We agreed that during the base times we would run standups and any important meetings so everyone could attend.

For managers and developers that are outside of Europe, there were additional challenges - async communication massively helped here and aligning check-in meetings to a time where you both were working was important. Having team members working completely different hours can actually be really useful if you have a time-sensitive issue as you can have a team working on the issue round the clock to help with a resolution, and this certainly helped with some of our incident availability issues. For example, if an issue occurred late in the day in the UK, our US, Canadian and Australian counterparts could continue the investigation with the UK/Europe team remaining on-call.

Trust

A remote-first culture requires a level of trust among employees. You have to trust your team to be able to plan out their time and be accountable for their outputs. For us, this meant weekly sprint commitments that engineers owned completely. We measured progress by completed work, not hours logged. When someone consistently under-delivered, we had specific conversations about planning accuracy and communicating issues early rather than questioning their work ethic. As a leader, you can guide and set expectations of what this should be and you need to be transparent and prompt with letting them know when your expectations are not being met.

Keeping Connected

It seems like a really trivial and simple thing, but at both LifeWorks and Bloom I set a tradition of saying "good morning" on an Engineering Slack channel when we first logged on for the day. It meant that every day, people had at least some connection with their team and kept small talk alive. It helped to remove a sense of loneliness or isolation.

I also ran a couple of sessions to help with team building - we used a tool called Brightful to organise fortnightly Friday fun, and I had a drop-in "ask me anything" session where people could drop in and chat about questions or problems they were having.

1-1s

I've written about 1-1s before so I won't go in to much detail here - other than to say they are critical in a remote-first environment.

Outsourcing

With outsourcing, the biggest mistake I see is treating offshore teams like an external vendor instead of integral team members. At LifeWorks, we used a number of outsourcing partners to help bolster our team and deliver our roadmap. For me personally, I wanted to ensure that outsourced developers were treated like full-time employees. We worked with our partners to set expectations of the skills and experience we were looking for and we interviewed our outsourced developers with the same standards we used for internal hires. As we'd hired competent outsourced developers, we ensured they were also part of our decision making processes and felt included in our sprint rituals. Working with a team that is fully remote actually made this easier as with everyone on a video call the playing field is even.

Conclusion

What started as a pandemic necessity became a competitive advantage - and these principles helped us not just survive that deadline, but grow and scale successfully through acquisition. There's a lot to talk about with remote-first working but this hopefully gives you an idea of how you can make it successful.

I know I often fall back to the same words and suggestions as they come to my mind first time and time again.

Inspired by a rehearsal I did recently, I've put together a little Improv Suggestion Generator that can help you with ideas for your next rehearsal.

I hope you find it useful, and drop me a message if you have any sugggestions for how I can make it better!

Access it here!

Coding with AI is moving at a fast pace thanks to great tools like Cursor, Highlight, Windsurf and others.

The Cursor team have been working super hard on pushing lots of updates to their IDE and it's made the possibility of vibe coding much easier for everyone to try.

What is Vibe Coding?

Coined by OpenAI co-founder Andrej Karpathy in February 2025, Vibe coding is an AI-dependent programming technique where a person describes a problem in a few sentences as a prompt to a AI chatbot or tool like Cursor and the AI generates all the code, shifting the human's role from manual coding to guiding the AI to generated source code, often without understanding what is being written.

This relates back to Karpathy's 2023 statement that "the new hottest programming language is English".

Why vibe coding is cool

Vibe Coding allows anyone to produce applications without having to think about the complexities of code. They can reel off an idea to an AI and then iterate on that idea without having to write any lines of code. And the results can be pretty impressive.

Why doesn't everyone just vibe code then?

For a non-engineer, vibe coding is a great gateway to getting started with code. It's really easy to get something going and make quick progress.

For an engineer, however the situation is slightly different.

Non-engineers see vibe coding and then struggle to understand why engineers are still taking time to write code manually.

There are a few reasons for this:

1. It's far easier to write code than it is to read code

When developers write code, they try to follow best practices for keeping code clean and maintainable through consistent naming, DRY principles and architected modular design. Writing readable code is a very hard thing to do - and even when coding manually developers often don't get it exactly right.

Vibe coding is a bit like having a junior developer on your team - they do exactly what you ask for without thinking about the bigger picture; or even if they should do it; and they have a habit of going off track and making other changes too.

2. The 80:20 rule

If you rely solely on vibe coding without establishing proper guardrails first (which may happen if you don't understand what guardrails are needed), you'll inevitably encounter problems as your application grows in complexity.

This situation illustrates the 80:20 rule of software development - where the final 20% of a project often requires the most time and effort to complete properly. With vibe coding, the challenge is compounded because you lack familiarity with the initial 80% of the codebase that was AI-generated.

As you approach the final stages of product development and begin refining your concept, issues are more likely to emerge. At this point, the vibe code engineer often finds themselves stuck.

For non-engineers, resolving these issues becomes nearly impossible because they don't understand the underlying code structure or problems. Even for experienced engineers who can read code, they're confronted with a disorganized collection of code that doesn't follow best practices, resulting in significantly longer debugging sessions.

3. What about security?

When vibe coding, you might overlook critical security considerations that professional developers would routinely implement. Essential security practices such as:

• Ensuring user inputs are safe
• Passwords are not stored in plain text
• API and Database keys are stored securely
• APIs are rate limited
• Permissions are set up correctly
• Errors are handled carefully

Not considering these security issues at all leads to issues like the ones we are seeing in the AI community now.

When it all goes wrong

So what can we do?

Engineers naturally approach AI code generation with caution. Beyond concerns about being undervalued or replaced, they prioritize keeping code readable and maintainable over time. While Cursor's MDC files can help address some of these concerns, you still need technical expertise to use them effectively.

Fortunately, this isn't an all-or-nothing proposition. Many routine tasks can be automated while engineers maintain control over the codebase structure. Time-consuming but low-value tasks like test maintenance and linting fixes can be efficiently handled using Cursor's YOLO mode, freeing up valuable time for more strategic coding work. I explore these automation opportunities in more depth in my Cursor tips and tricks article.

For non-engineers excited about vibe coding, keep the 80:20 rule in mind: what seems easier at the beginning often becomes significantly more challenging later in the development process.

Tips for better Vibe Coding

From my experience, the best use case for vibe coding is to test the vibe of an idea. As per Pieter Levels recommendation - creating a prototype in 3 hours to see if the idea is even feasible is a great use case for vibe coding. It produces a lot of thought about the use cases of the idea and information about how it would work.

Here's some tips for being better at vibe coding:

1. Use AI to first make a PRD (Product Requirements Document) before writing code. Include the PRD file in your codebase. Grok, o1 Pro or GPT 4.5 are particularly good at creating these.
2. Be less specific. Vibe coding is about getting things "almost right" and accepting compromises. AI has a habit of getting stuck in the most unusual situations.
3. Vibe coding frequently won't go right. So start over when things go wrong. Learn lessons with each iteration on what did and didn't work with your prompts until you get something good. Cursor also has a handy 'revert' feature that allows you to step back through code changes.
4. Utilise TDD to get the AI to test it's own code, and ask it when you want it to break code up in to smaller pieces.

As of March 2025, for production code of complex applications however, you're probably best keeping it in the safe hands of your engineers.

As I wrote at the top of the article, coding in AI is moving fast - so let's see how long it takes for that to change.

The real world applications for this would include knowledgebases; help and support centres and SaaS product search bars. Companies can create knowledgebases of their systems and products without requiring mass manual creation of content - they simply handle curation.

How it works

The system works as follows:

• The user visits the site or product on a subject matter they are interested in
• There is a prominent search bar encouraging the user to find what they are looking for which they use to search for content
• If the content exists, it is directly served to the user
• If the content does not exist, then we use AI coupled with Retrieval Augmented Generation to generate the content on the fly
• This content is immediately presented to the user who searched for it.
• The user can mark the content as useful if it is appropriate - which will then trigger it to be published and added to the site and site map for SEO.

With this approach, we no longer turn a user away when they don't find something relevant - we instead offer a way for them to find

Checks and balance

Of course, with any content being generated automatically we need checks and moderation. There's two areas we need to be careful of here:

• User input - Is this input a valid input? We don't just need to check for bad language - we also need to check it's relevant to the subject matter of our website (and not sending users to our competitors).
• AI output - Is the output from the AI correct and relevant, or has it been hallucinating?

We can use a set of AI and non-AI checks to ensure our inputs and outputs are correct.

Input

Before anything happens, we check to see if the content already exists in our system using the regular search techniques.

If the content doesn't exist, then we do some rundementary checks - is the query of a minimum viable length (or not overly wordy) and does it pass a bad words filter.

Next a cheaper AI model (in my case Claude Haiku) handles our initial screening - verifying whether the search term is relevant to our subject matter.

Once we are happy, we can send it through to our more expensive AI model (Claude Sonnect) together with any relevant content from our RAG (Retrieval Augmented Generation) database to create our new content.

Output

For the output, we specify a JSON structure we would like the AI to return our content, and then we run a secondary check with another AI prompt to ensure that this secondary model agrees the content is relevant to our subject matter.

This content is then surfaced back to the user to help with their query, but it remains unpublished on the site.

A secondary threshold (did the user find it useful, is it a common search term) determines if the content becomes a published article on the site.

Putting it all together

The content generation process

The diagram above illustrates how it all fits together and how AI components (marked in purple) are integrated with traditional content management processes (in white) and decision points (in green) to create a comprehensive content workflow system.

A working prototype

I have built a working prototype of this system as a directory for technical terms.

A knowledgebase for technical terms

The prototype behaves as follows:

• it is connected to a content database filled with technical terms
• if the user searches and a term isn't found, then the content is generated and served to the user
• an alert is triggered to notify me for review and if I approve it, the content will be published on the site

If you'd like to explore more about how this system works and how we could partner in developing this or similar systems, please contact me on LinkedIn.

I've been using Cursor daily for some time now and it's been a interesting learning experience. Sometimes it feels like my greatest co-worker - it's reading my mind, it's saving me a heap of time; and then suddenly it turns on me and it starts to produce convulated, broken solutions to what should be a simple problem, or it creates a bunch of new components rather than use what we already have.

Be explicit

The general rule is: the more precise you are with your instructions to Cursor, the better the output. Cursor isn't a mind reader, it needs context if you want it to perform in a particular way.

For example, if you know it is going to need to call a particular API or function, let it know by @ the relevant file. This will help avoid the danger of it creating repetition in your code base.

Also make sure your prompt doesn't ask too many things - Cursor is much better at implementing functionality in smaller pieces. Plus with smaller pieces, you are likely to be more precise with your ask.

Making better prompts

Regardless of how clear you make your prompt, it's unlikely AI is going to be on exactly the same wavelength as you and it's unlikely it will get everything right on it's first go.

Test Driven Development (TDD) can help you get a better handle on this. The TDD cycle follows three primary steps:

• Write a failing test that defines the functionality you want to implement.
• Write the minimal amount of code to make the test pass.
• Clean up and optimize the code while ensuring tests still pass.

To get Cursor to do this for us we can suffix our build AI prompt with an instruction to write our tests before writing the code. Furthermore, if we enable and configure YOLO mode in Cursor's Settings > Cursor Settings > Features, we can also give it permission to run npm test which means it can run our tests iand iterate on the code until they all tests pass. We can also use this method to specify any test edge cases we need the AI to consider.

Get Cursor to think it through

Cursor's chat box has both 'Agent' and 'Ask' functionality. While the 'Agent' is useful for most things, if Cursor isn't giving you the results you want, then getting it to think about the problem in the 'Ask'. Ask for three different solutions to the problem, and get Cursor to discuss the pros and cons for each. Then you can get it to build the solution you think will work best.

Try something else

Sometimes Cursor just can't fix a problem. If it's tried two or three times and it's not finding a suitable resolution, then it's likely you need to change something about the ask. There's three ways we can change this:

• present the problem differently
• try another tool
• do it ourselves

I've actually found a lot of success with taking the problem statement away from the contextbuilt up in Cursor and instead using a fresh Claude or OpenAI chat window. Talking to an AI that isn't living your app can give a secondary perspective to understand the problem which then will either help you come to a better solution, or it will help you chat to Cursor in a way it finds easier to understand.

Try a different model

Speaking of using something else, there is a lot of value in trying a different model within the Cursor IDE itself.

Currently using the new Claude 3.7 agent in particular seems to cause a lot of extra unwanted activity and change. For example, it may add the requested functionality to a file and then decide it will go on a refactoring journey across the codebase whilst you're frantically looking for the 'stop' button.

You can swap models within Cursor whenever you like - simply hit the dropdown next to Agent (which has the model name or 'default'); and try again with another model. You'll find some AI models are better for planning, some are better for coding, some are better for debugging.

Create rules

Previously we'd create a .cursorrules file in our root directory, but Cursor has recently moved to allowing multiple rules through a new MDC format hosted in /.cursor/rules. With MDC, you can break up your rules in to separate files and then apply it to specific files or directories using globs. For example, if I wanted to apply a set of rules only to React components, I could create a file like:

---
description: Generating React Components
globs: *.tsx, *.jsx
---
# Coding style guide
- Style guide goes here

As well as style guides you can also add other information to assist Cursor around your code base - for example, consider adding information on the following:

• App Flow - how users navigate through your app
• Backend - the structure of the backend and any techniques you want to consistently use
• Frontend - the structure of front end code
• Requirements - how the app should behave
• Implementation plan - a numbered implementation plan, broken down in to well defined, small steps so the AI can concentrate on one thing at a time

You can get AI to help you create these through conversation AI such as Claude, though make sure you review the documents manually too.

Commit often, review your commits

Though it is possible to rollback to previous versions with Cursor, it's quite easy to get lost within lots of untracked changes. Having a sensible git commit history allows you to quickly revert if something goes badly wrong.

You can commit changes from within Cursor's source control panel and then @ tag your Git commit within Cursor's Ask chat prompt to ask for improvements and potential bugs.

Will Cursor replace me?

While it's undeniable that the speed of progression with AI coding has been phenomenal, the requirement for real developers is unlikely to go away in, at least in the short term. The advancements in code quality that AI is making are starting to reach diminishing returns and the solutions built with AI tend to ignore the sensibilities of writing good code.

Developers are likely to take more of an orchestrator role with AI ensuring that the code that is written is of good quality and fit for purpose. Remember, code readability is far more important than how quickly we write, so don't blindly accept code - make sure it is something you will understand when the context of the chat window is long past and your debugging an issue in production.

Good luck out there!

Play Containment DX in your web browser. Best played in Chrome on desktop.

The original "Containment" game was created by Rich Hodgson and had quite a following on the high scoreboards on Natomic's website. In the game, the player controls both paddles and has to stop the ball from escaping the boundaries of the circle. As time progresses, the ball gets faster adding extra complexity.

You can watch a playthrough on YouTube. As you can see, the gameplay is fairly straightforward - the times were simplier back then!

Rebuilding in JavaScript with Generative AI

I thought it'd be an interesting challenge to see if we could easily replicate this game on the web with help from Claude and Cursor. For this project, my approach was to use Claude's web interface to build an initial version and then move over to Cursor when I needed to start editing the code. I then wanted to use AI to produce extra visual effects, audio and music.

Earlier in the day, I'd been trying to replicate a LucasArts adventure game with AI which had proved too much of a challenge to overcome in a few hours - but with this much simpler game and the assistance of Claude AI, it was very easy to get a simple remake of the core game concept working.

Once the initial gameplay was working, I then used Cursor AI to help me improve the original game with power-ups and particle effects, and other AI tools to assist with music, voice overs and sound effects. This article breaks down my journey building this game with AI.

Initial Prompt

After playing and reviewing the original game, I settled on the following prompt for Claude Sonnet 3.7:

I want to make a special version of Pong in JavaScript and Canvas 2D where the player controls both paddles and they rotate 360 degrees around a circle.

The paddles are controlled with the left and right cursor keys.

The ball needs to be contained within the circle and should bounce when colliding with the paddles. Each bounce should add 100 points to the users score. As the ball gets faster, a multiplier should be added to the score.

As time progresses, the ball should gradually get faster. (every 15 seconds)

The player starts with three lives. If the ball leaves the play area, the player loses a life.

When they have lost all their lives, they are presented with a game over screen and their score.

Before starting the game, there should be a title screen with the word "Containment" and "Press Any Key to Start" on it.

This got me started with an initial version of the game with circular paddles and a ball that bounced around the screen. I then needed to provide AI instructions for some adjustments to the initial gameplay - e.g. slow down the ball as it's unplayable!

I chose to use Canvas 2D as it allows me to manipulate the entire screen like a bitmap, and is perfectly suitable for a 2D game.

Drawing and Animating the 360° Circular Paddles

The game uses a circular arena with paddles that rotate around its perimeter. Let's take a look at how this is implemented:

Paddle Initialization

The arena is positioned at the center of the canvas, with a radius that ensures it fits within the canvas boundaries, and the paddles are initialised to fit in that.

function initPaddles() {
  paddles = [];
  const angleStep = (2 * Math.PI) / paddleCount;

  for (let i = 0; i < paddleCount; i++) {
    paddles.push({
      angle: i * angleStep,
      length: paddleBaseLength,
      width: paddleWidth,
      active: true,
    });
  }
}

This function creates paddles evenly distributed around the circle. Each paddle has:

• An angle (in radians) representing its position
• A length (arc length along the circle)
• A width (thickness)

Rotating Paddles

function updatePaddles() {
  if (rightPressed) {
    paddles.forEach((paddle) => {
      paddle.angle += paddleRotationSpeed;
    });
  } else if (leftPressed) {
    paddles.forEach((paddle) => {
      paddle.angle -= paddleRotationSpeed;
    });
  }
}

When the player presses the left or right arrow keys, all paddles rotate in the corresponding direction at a constant speed.

Drawing Paddles

function renderGame() {
  paddles.forEach((paddle) => {
    const paddleAngle = paddle.angle;
    const paddleLength = paddle.length;

    const halfLength = paddleLength / 2;
    const startAngle = paddleAngle - halfLength / arenaRadius;
    const endAngle = paddleAngle + halfLength / arenaRadius;

    ctx.beginPath();
    ctx.arc(centerX, centerY, arenaRadius, startAngle, endAngle);
    ctx.lineWidth = paddle.width;
    ctx.strokeStyle = "#FFF";

    ctx.stroke();
  });
}

The challenge here is that the paddles are drawn as arc segments on the arena's perimeter rather than the tradional rectangles. To do this:

1. We calculate the start and end angles for each paddle
2. The formula paddleAngle ± (halfLength / arenaRadius) converts the paddle's linear length to an angular span
3. The ctx.arc() method draws the arc segment at the arena's radius
4. We set lineWidth to control the paddle's thickness
5. Special effects like the flashing colors I added later for power ups are applied conditionally

Patterned Paddles

There was another challenge with the paddles. In the original game, they were represented with yellow and black diagonal lines as traditionally seen in construction signs. I really wanted to implement this by my canvas was drawing an arc.

function createHazardPattern() {
  const patternCanvas = document.createElement("canvas");
  const patternContext = patternCanvas.getContext("2d");

  patternCanvas.width = 20;
  patternCanvas.height = 20;

  patternContext.fillStyle = "#FFD700";
  patternContext.fillRect(0, 0, 20, 20);

  patternContext.fillStyle = "#000000";
  patternContext.beginPath();
  for (let i = -20; i < 40; i += 20) {
    patternContext.moveTo(i, 0);
    patternContext.lineTo(i + 10, 0);
    patternContext.lineTo(i + 30, 20);
    patternContext.lineTo(i + 20, 20);
    patternContext.closePath();
  }
  patternContext.fill();

  return ctx.createPattern(patternCanvas, "repeat");
}

This code draws a hazard pattern which can be applied to the paddles. However, we couldn't apply it directly as the pattern needed to rotate as the paddles rotated! So instead, we clip the paddle shape and apply a pattern to a rectangle drawn around the paddle.

paddles.forEach((paddle) => {
  // as above
  const paddleAngle = paddle.angle;
  const paddleLength = paddle.length;

  const halfLength = paddleLength / 2;
  const startAngle = paddleAngle - halfLength / arenaRadius;
  const endAngle = paddleAngle + halfLength / arenaRadius;

  ctx.save();

  const outerRadius = arenaRadius + paddle.width / 2;
  const innerRadius = arenaRadius - paddle.width / 2;

  ctx.beginPath();
  ctx.arc(centerX, centerY, outerRadius, startAngle, endAngle);
  ctx.lineTo(
    centerX + innerRadius * Math.cos(endAngle),
    centerY + innerRadius * Math.sin(endAngle)
  );
  ctx.arc(centerX, centerY, innerRadius, endAngle, startAngle, true);
  ctx.closePath();

  ctx.clip();

  ctx.translate(centerX, centerY);
  ctx.rotate(paddleAngle);
  ctx.fillStyle = hazardPattern;
  ctx.fillRect(
    -arenaRadius * 1.5,
    -arenaRadius * 1.5,
    arenaRadius * 3,
    arenaRadius * 3
  );

  ctx.restore();
});

Handling Collisions

The collision system determines what happens when a ball hits (or misses) a paddle.

Ball Movement

  ball.x += Math.cos(ball.angle) * ball.speed * speedMultiplier;
  ball.y += Math.sin(ball.angle) * ball.speed * speedMultiplier;

  const dx = ball.x - centerX;
  const dy = ball.y - centerY;
  const distance = Math.sqrt(dx * dx + dy * dy);

  if (distance + ball.radius > arenaRadius) {
    if (!checkPaddleCollision(ball)) {
      // Ball escaped, handle life loss...
    }
  }
}

For each ball:

1. We update its position based on angle and speed
2. We calculate its distance from the center
3. If the ball reaches the arena boundary, we check for paddle collisions

For the movement, the game uses polar coordinates converted to Cartesian (x,y) movement. The ball.angle represents the direction of travel in radians (0 to 2π) with Math.cos(ball.angle) calculating the x-component of movement and Math.sin(ball.angle) calculates the y-component.

To help visualise the movement, consider:

• When ball.angle = 0: Ball moves right (cos(0)=1, sin(0)=0)
• When ball.angle = π/2 (90°): Ball moves down (cos(π/2)=0, sin(π/2)=1)
• When ball.angle = π (180°): Ball moves left (cos(π)=-1, sin(π)=0)
• When ball.angle = 3π/2 (270°): Ball moves up (cos(3π/2)=0, sin(3π/2)=-1)

Paddle Collision Detection

function checkPaddleCollision(ball) {
  const dx = ball.x - centerX;
  const dy = ball.y - centerY;
  const ballAngle = Math.atan2(dy, dx);

  for (const paddle of paddles) {
    let angleDiff = (ballAngle - paddle.angle) % (2 * Math.PI);
    if (angleDiff < 0) angleDiff += 2 * Math.PI;
    if (angleDiff > Math.PI) angleDiff = 2 * Math.PI - angleDiff;

    const arcLength = angleDiff * arenaRadius;

    if (arcLength <= paddle.length / 2) {
      return true;
    }
  }

  return false;
}

The collision detection has several key steps:

1. Calculate the angle between the center and the ball's position
2. For each paddle, find the angular difference between the ball and paddle
3. Convert this angular difference to an arc length along the arena boundary
4. If this arc length is less than half the paddle's length, a collision occurred

Power-up System

The original Containment game didn't include power-ups. When I played around with the original, it felt like it would benefit from such a feature. Originally power-ups spawned from the middle circle in the same way the ball did. But it wasn't satisifying and it felt too difficult to obtain a power up. So instead, I moved the power ups to appear in an empty space around the arena boundary, and so can be collected by paddles as they rotate. Power ups include gaining an extra life or getting a bigger paddle, but can also include negative effects like a faster ball or smaller paddle. As there are dual paddles, it becomes a challenge for the user to avoid certain power-ups. However, successfully using these negative power ups provides a larger score increase.

Spawning Power-ups

Power-ups spawn with these characteristics:

1. A random type is selected
2. The system tries to position them away from paddles (to prevent immediate collection)
3. They appear exactly on the arena boundary
4. They have visual effects (fade in/out) and a limited lifetime

function spawnPowerUp() {
  const randomIndex = Math.floor(Math.random() * powerUpTypes.length);
  const powerUpType = powerUpTypes[randomIndex];

  let angle;
  let validPosition = false;
  let maxAttempts = 10;
  let attempts = 0;

  const posX = centerX + Math.cos(angle) * arenaRadius;
  const posY = centerY + Math.sin(angle) * arenaRadius;

  // Create the power-up
  powerUps.push({
    x: posX,
    y: posY,
    type: powerUpType,
    expiresAt: Date.now() + 2000,
    opacity: 0,
    fadeDirection: "in",
    fadeSpeed: 0.05,
  });
}

Power-up Collision Detection

For collision detection, we calculate the angular distance between the power-up and the paddle. There's a lot of Math involved here, and Claude AI was great in doing the heavy lifting.

for (const paddle of paddles) {
  let angleDiff = Math.abs(angle - paddle.angle) % (Math.PI * 2);
  if (angleDiff > Math.PI) angleDiff = Math.PI * 2 - angleDiff;

  const arcLength = angleDiff * arenaRadius;

  if (arcLength <= paddle.length / 2 + powerUpRadius) {
    activatePowerUp(powerUp.type);

    showPowerUpMessage(powerUp.type);

    powerUps.splice(i, 1);
    break;
  }
}

The collision detection is similar to ball collisions, but with a more generous collision area.

Each power-up:

1. Applies an immediate effect (changing paddle size, adding balls, etc.)
2. May have visual feedback (flashing)
3. For timed effects, schedules a deactivation

Particles

Although I've written a fair number of particle systems in my time, I got AI to help me write all of the particle systems for this project. It wrote it far quicker than I would and created more impressive effects.

After playing around with space starfield background for a while, I asked AI to produce a Bokeh effect for the background instead which looked really cool. When implementing changing the colours of the Bokeh effect when the score changed, I accidentally stumbled across a way to make the background interact with the game. I had to tone down the intensity as it started to make me feel sick, but I think the tamer version helps tie everything together.

Music and Sound Effects

For the music, I wanted to create something quite basey. I took inspiration from Disclosure - King Steps. I asked Claude AI to summarise the beat and sounds of the song.

Please describe the beat and sounds of King Steps by Disclosure. Ignore the vocals, imagine you had to ask someone to replicate the music. Describe the sound in 200 characters.

It output the following:

Four-on-the-floor house beat with crisp hi-hats & punchy kicks. Deep, wobbling bass groove creates momentum. Atmospheric synth pads float overhead while melodic synth hooks provide catchy motifs.

I then took that prompt in to AI Music.so and generated two tracks which are used in the game (chosen at random).

Sound effects came from Mixkit.co which is an awesome resource that doesn't require a sign in for a lot of sounds.

I decided the power ups needed to be more prominently announced, so I used ElevenLabs text-to-speech to produce spoken words for each. The voice is Brian on a very slow speed.

Conclusion

In the days gone past, building a indie game like Containment would either mean skipping extra visual or sound effects, or spending a unreasonably large amount of time on getting it right.

AI has helped me recreate this game which had been lost to old versions of Windows, and I'm thankful for that. However, if you start to dig around the source code you'll see it has become quite a mess. I decided to stay relatively hands-off in this project, only intervening when it was easier to make a manual edit (e.g. update a power up icon) or one bizarre time where Cursor told me I needed to go and manually remove a bracket as it couldn't do it.

So there's still a way to go with AI, but given this project wouldn't exist at all without AI I can live with some messy code.

Play Containment DX here!

I had an application where there were multiple components which needed to load and change independently. My use case was more than just needing different props - I essentially needed to have multiple children that sat in different parts of my layout.

And that's when I discovered NextJS Parallel Routes, which were introduced in NextJS 14.

What Are Parallel Routes?

Parallel Routes are an advanced routing mechanism that lets you show multiple pages at once within the same layout.

In regular websites, when you click a link, the whole page changes. But with Parallel Routes, only certain parts change while others stay the same. This is perfect for:

• Data-heavy dashboards where you need to see multiple sections
• An e-commerce site where you want to show products and a trolley independently
• Social media feeds with different content types
• Authentication flows where only part of the page changes when the user is logged in

How Do Parallel Routes Work?

The magic of Parallel Routes happens with special folders known as 'slots' which are prefixed with an @ symbol. For example @analytics. Let's say you're building a dashboard with three sections:

1. Main dashboard
2. Analytics section
3. Revenue section

Here's how you'd set up your folder structure:

app/
└── dashboard/
    ├── layout.tsx
    ├── page.tsx (Main dashboard page)
    ├── @analytics/
    │   └── page.tsx (Analytics section)
    └── @revenue/
        └── page.tsx (Revenue section)

These slots automatically become props that are passed to the layout - you don't need to import them. So you can use them like so:

export default function DashboardLayout({
  children,
  analytics,
  revenue,
}) {
  return (
    <div>
      <nav>Dashboard Links</nav>
      <div>{children}</div>
      <div>{analytics}</div>
      <div>{revenue}</div>
    </div>
  );
}

Now you understand how they work, let's take a look at some of the cool things you can do with them:

1. Independent Loading and Error States

NextJS's App Router already has great handling for loading states, and this is extended with parallel routes which are able to have their own loading states!

This enables you to partially load your page and allow your users to interact even while other sections are still loading. Like you would for any NextJS loading state you can add loading to parallel route by simply adding a loading.tsx file inside each folder. e.g:

app/dashboard/@analytics/loading.tsx
app/dashboard/@revenue/loading.tsx

The same is the case for error handling. Just add an error.tsx file in each section's folder, and if something goes wrong, only that section will show an error while the rest of the page continues working.

2. Conditional Rendering

It's up to you what you do with the props sent to the layout.tsx file - you don't have to display them. Instead, you may want to show different sections based on conditions. For example, show an admin panel only if the user is an admin, or a log in screen if the user is not logged in:

export default function Layout({ admin, user }) {
  const isAdmin = checkIfUserIsAdmin();

  return isAdmin ? admin : user;
}

3. Creating Modals

You can also make pop-up windows that can be bookmarked and shared, and maintain their state when refreshed.

app/
├── layout.tsx
├── page.tsx
└── @auth/
    ├── default.tsx (Shows nothing)
    └── (.)login/
        └── page.tsx (Shows login modal)

The modal becomes a real route in your application while maintaining the user experience of a traditional modal.

Navigating with Parallel Routes

Things start to get a little more complicated when you start navigating beyond your initial page in to child pages of your content. By default, NextJS will look for a similar child page in your slot.

So, for example, if you had a page at dashboard/settings, NextJS would look for a @analytics/settings too instead of using the original component.

There are a couple of ways to resolve this - the first is by creating a default.tsx page to show a fallback. However, this starts to cause complications with your state when you are changing between server (when a user initially lands on your page) and client (when a user navigates to your page) side rendering.

A safer bet is to create a catch all folder using the same mechanic you'd use to create a NextJS slug - for example, [...catch]/page.tsx. This will catch any pages that do not exist and serve this page instead.

Why Parallel Routes Are Awesome

• They make complex layouts simpler
• Each section can have its own loading state and error handling
• You can stream content as it becomes ready
• Perfect for conditional content (like showing different things to logged-in users)
• They work great with tabs, modals, and multi-section pages
• Makes your code more organized by keeping related features together

Next time you need to build a dashboard or any page with multiple independent sections, give Parallel Routes a try! It's your new superpower for website routing!

If you've ever had to deal with stakeholder management as an engineering leader, there's undoubtedly one question that keeps resurfacing again and again: "How do we make the developers go faster?"

The pressures of a deadline and the risk of being too late to the market - particularly in startups - and a common misconception about software development productivity often drive this feeling of not going fast enough - but what can we do about it?

The Velocity Trap

Early in my career as a technical leader, I fell into a velocity trap – we just needed to write more code in less time. The problem is, people who chase this goal quickly find themselves running faster toward bigger problems.

The reality I've learned is counterintuitive: sustainable speed requires intentional slowdown at critical moments.

The Hidden Costs of Cutting Corners

We've all been there - when the time spent firefighting overtakes the time spent building new value. It can normally be traced back to one of the following - skipping proper requirement gathering; failing to get team agreement; rushing through architecture and design thinking or just coding without thinking.

Each shortcut taken compounds, creating a snowball effect that eventually brings development to a crawl and the result is we spend the next three months firefighting production issues, dealing with unhappy customers, and ultimately rewriting large portions of the codebase.

Don't get me wrong - sometimes it's ok to cut corners. If you have a short lived project or minisite, then you build it in a different way than you would an entire digital platform. As a leader we need to recognise when it's ok to apply speed vs move slower.

So How Can We Go Faster?

As leaders, there's still things we can do we speed up development without taking these shortcuts:

• Should we even do this? - To quote the book Rework, from the team at 37signals, it is "better to build half a product, than a half assed product". Make a small but great thing, rather than a big but bad thing. And sometimes, maybe you don't need to build the feature at all. Your team will thank you for not wasting their time.

• Focus on execution - Execution isn't about doing more things, but about doing the right things well. To do this, you need to:

  • Identify the core value drivers that matter most to users
  • Resist the temptation to spread resources too thin
  • Measure impact, not just output
  • Create space for deep work and meaningful iteration

• Starting in manual mode - Rather than automating everything at the start, look at what you can do manually. I've used this technique a lot to help gauge what we should and shouldn't do; and when you know it works and it's starting to become a scaling problem, then you look to make it automated. If it doesn't work - great don't build it.

• Buy vs build - At my last startup, we needed to deliver a lot of features in a short amount of time - so we looked at what was truely important to the product - the differential - and we found off-the-shelf solutions for the remaining items.

• Be realistic with what you can achieve - Heroics only get you so far. Estimating story points with only the best case scenario never works - there will be issues with the approach and your developer will get distracted by other meetings, tasks or other people. Even if they manage to get a day or two of complete uninterruption, it won't last. There will be unplanned work - like finding a bug in production or a unhappy client. So listen to your team's capacity signals and make sure you account for them before agreeing on a release date with the business.

• Understand how your team works - As a leader, it is your responsibility to learn how your team performs best and give them that environment. I often find a happy team is a more productive team - and you can achieve a happy team by fostering an environment where they can succeed without fear of failure, where no question is a stupid question and without constant distraction.

• Avoid burnout - You need to know how far you can push your team and when you need to stop pushing. If your a good leader, your team will go that extra mile for you from time to time. But if you keep asking to go the extra mile, then they will burnout and start to look elsewhere.

Essentially, what we are looking for is sustainable, consistent progress.

What Else Can We Do?

Of course, there are other things we can do as leaders to help our teams:

• Reduce the distractions - How important is the production bug? Is it affecting a few or a lot of users? Similarly, do they really need to be in every meeting - or could this meeting be shared as a Loom instead? A lot of companies look at meeting-free days as a way to allow for improved productivity. Agreeing with your team if there's a day or time of day (e.g any meetings should happen in the mornings) can help.

• Keep the focus on now - Allow the team to focus on the current priorities rather than what is coming along the pipeline in two or three months time.

• Tell your team it's ok to be in focus time - Set expectations around when you want them to be active on Slack, Teams, email etc. Sometimes we feel constant pressure to reply on Slack to prove we are working. I normally tell my team to answer when they have time, and follow more of a path toward asynchronous team communication.

• Make sure you have some time for being social - Allow time for your team to have fun and let off steam. There are lots of online games you can play with remote teams, or a coffee or bar visit for those who are in office. Sprint demos are also a great way to celebrate the work achieved and spend some time understanding what everyone has sacrificed to reach that point.

If you're working in a B2B business in some kind of security capacity, chances are that you spent a fair amount of time filling in InfoSec surveys from perspective clients. These surveys are important to make clients feel at ease, but they can be painstaking to fill in; they often come in different formats and with slightly different wording and they can take a serious chunk of time to complete.

Enter Claude

I've been using Claude 3.5 Sonnet and it's Projects feature to take the pain out of answering these questions. It's not perfect - but it gives a good starting point which you can then review and submit.

To do this you will need:

• A paid Claude account.
• All of the InfoSec policies and agreements your company has.
• Your company's privacy policy.
• Any previous InfoSec surveys that are relevant.

How to make your InfoSec life better

1. Create a new project in Claude AI

Go to Claude Projects and select 'Create Project'. Give your project a name - e.g. 'InfoSec' and a description - e.g. Answer questions on InfoSec.

Once it is created, check your project is private by checking the padlock is showing next to the project name.

2. Add the project instructions

On the new project page, click 'Set project instructions' and add the following prompt:

You are an InfoSec expert who works for [Company name]. [Add description of company].

You will be given prospective client security questions and you will need to provide accurate client-facing answers.

• Use a professional tone, use precise wording.
• The response is for a technical audience, so you can use common technology and security terms, but keep the wording simple.
• You should not say "Based on the information available", you know the information.
• Keep answers optimistic
• Always start with a positive outlook - your answers may determine whether the prospective client becomes a paying customer.
• Answers should be concise and kept to less than 250 words.
• Avoid becoming a sales person and promoting the product in your answers. This is for InfoSec.

3. Upload your data

Now it's time to add your project data. Upload your policies to the project. Some of the policies you may want to add include:

• Acceptable Use
• Asset Management Policy
• Backup Policy
• Change Management Policy
• Code of Conduct
• Data Classification Policy
• Data Protection Policy
• Data Retention Policy
• Encryption Policy
• Information Security Policy
• Logging and Monitoring Policy
• Password Policy
• Physical Security Policy
• Risk Assessment Policy
• System Access Control Policy
• Vendor Management Policy
• Vulnerability Management Policy

You may also want to include:

• Business Continuity Plan
• Disaster Recovery Plan
• Incident Response Plan
• A description of the system tech stack
• Software Development LifeCycle

If you have any Data Processing Agreements or Master Service Agreements you can also include these.

4. Adjust the writing style

Once you have uploaded some documents, Claude allows you to configure a custom writing style. Under the text entry area and next to the model name is a 'Choose style' option. If you click 'Create', you can add some of your previously answered questions and AI will respond with a similar style.

5. Test your output

All that is left to do now is test your output! Give it a whirl and then see what needs to be tweaked!

And that's how you make InfoSec documentation more innovative!

There's been a lot of noise in the last couple of weeks over an interview with Brian Chesky from Airbnb on 1-1s (one to ones).

I don't believe in 1-on-1s and almost no great CEO in history has ever done 1-on-1s

It's an interesting statement - for as long as I can remember we've always been told how important it is to do 1:1s with your team. Should we stop?

Communication is key

Regardless of your stance on 1-1s, you have to agree that communication is a key to success in any business. If you aren't having 1-1s then having those discussions with the team in a different format is still important for visibility you still need to know what is going on in the business. The problem with having these discussions in a different format is you no longer have a safe space for your team to talk to you about issues.

Sometimes an issue can't be properly discussed in an office or group setting, and by cancelling or removing their 1-1s what you are actually saying to your direct reports is that you don't care about them or their career. They are just an expendable resource to you.

Ouch, that doesn't feel good.

Building relationships

As a leader, I find 1-1 catch ups are important to ensure a good healthy relationship with your reports and ultimately to boost productivity, morale and engagement. It allows you to build a rapport with your team in a non-stressful environment. It allows you to understand about how your team think and communicate. And this becomes an incredibly powerful tool for situations where things do get stressful.

What makes a successful 1-1?

For 1-1s to be successful, they should be:

• Regular - An meeting that both of you expect to happen on the same day at the same time each week (or 2 weeks).
• Face-to-face - either in-person or via a video call.
• Private - a safe space to discuss and feel comfortable about discussing anything.
• Personal - It should be about your direct report and their needs, not about the status of a project.

So as leaders, how should we be starting a 1-1? I've recently been reading a book called "The Coaching Habit" by Michael Bungay Stanier which covers exactly how to ask a kickstart question, and it's actually very simple.

What's on your mind?

It's a question that gets right to the heart of the problem and allows our reports to immediately feel safe enough to talk about what they've been thinking about.

Now the question is out there, it's time for us as leaders to be good listeners, be genuinely interested in what your report has to say and actually listen to the answer.

Through this answer you want to understand if they are feeling supported; what is concerning them; what are the opportunities and if they have any news or feedback. If you don't feel like the first question has given you these answers, then there is a very simple follow-up question.

And what else?

1-1s are an integral part of working in a team

1-1s are important for the line report to have a space to feel heard and important, and they are an important tool for a manager to understand how your report is doing. It is the only meeting where you have the undivided attention of the other person.

They are also a chance for you to give feedback on ways of working and share what is on your mind.

If you want to get better at 1-1s, I strongly recommend The Coaching Habit for opening your eyes on how you can better communicate with your team and have more useful and productive 1-1s. And remember, communication is key.

We've seen a real change in AI over the last year or so. OpenAI's release of GPT-4 really changed the AI landscape; Claude's Sonnet 3.5 which released in June is equally impressive; and Google's Gemini is also not too far behind.

The speed at which these companies are moving forward and upgrading their AI offerings is staggering. New features and new releases are available frequently which substantial new features such as OpenAI's Assistant Threads and Claude's Projects and Artifacts.

Whilst building your own AI model seemed like a viable option just two years ago, now it feels like something that is difficult to recommend. Any development is going to become quickly out of date without serious investment. And the returns on that investment are going to be difficult to achieve unless your moat is wide and use case is incredibly unique.

Supplementing knowledge

Instead, using techniques such as Retrieval-Augmented Generation (RAG) seem to be more efficient approach. RAG supplements the AI model with additional information through either structured documents or a vector database to allow the AI to be better informed about the context in which the user is interacting with AI. For example, if your AI was providing career advice to the user you may use RAG to supply the users' work history, some information about the companies they have worked for and information about the job role they are applying for.

With these techniques, you can get the best of both worlds - all the updates and model improvements from the heavy hitters with the context from your own business - and at a fraction of the cost.

When should we use a model?

There are of course times when using a model is still worth it. You should consider using a model when:

• You have highly specialised domain data that existing models do not understand
• You need complete control over the model's behaviour
• You have strict privacy requirements

Removing the stigma of wrappers

Over the last 12 months there's been a bit of a stigma put on AI wrappers. A feeling that if you are not using your own model then what is the moat of your business. But I feel this stigma is unfair.

If we think about a lot of successful products, quite often what we find is that users are looking for convienence. If you can cut the time down that it takes a user to complete a task (and you market it well), then they really don't care about how you are doing it.

At this point in time, combining AI wrappers with Retrieval-Augmented Generation feels like a very valid way to build a successful business; doesn't require deep machine learning expertise and has a much shorter time to market. The challenge from an entrepreneurial point of view is to find a pain point that people would be willing to pay money toward fixing and finding a way to distribute and market your application.

And that, dear reader, is up to you.

AI agents aren't a new concept. LangChain has been around for quite some time - but I hear a lot of people have pain with it in production environments and the AI landscape is moving on so quickly with OpenAI can I find a better way to create chained AI agents?

Turns out I can. What follows is an application that can work across multiple contexts whilst maintaining a consistent chat history.

The concept

The concept of this approach is as follows:

Whenever a message is sent to the application, a proxy router agent analyses the message and determines which 'journey' the user should be on. Depending on the journey, the router will pass the message to one of many AI agents who each specialise in completing a different job.

The router keeps a context of the user message stream so it can understand if the user is in an existing conversation with an agent, or it needs to pick an agent to start this conversation.

So the proxy router' response looks like this: { agent: 'ONBOARD' }

While all the other AI agents respond with JSON in a format that looks more like this: { content: 'This is the message', completed: true | false }

When an AI agent deems a conversation as completed, it will set the completed flag to true and the proxy router will then know to stop directing messages to that agent.

Like my previous article on AI Assistants with WhatsApp, for the demo data will be stored against an object locally. Obviously, in production you'd want an encrypted database.

The proxy

The proxy agent evaluates each request made to the system and works out the agent that should be used. The prompt would look something like the below, with the keywords matching the problem your AI assistant is trying to solve:

You are an operator managing conversations with AI agents. You will be given one or more sentences that form part of a dialogue of a conversation and you need to respond with the relevant keyword.

The keywords are:
* "GREETING" - if the user says hello or hi
* "CONTINUE" - continue talking about the same subject. This should be used if the latest sentence is the same topic as the previous sentence.
* "HISTORY" - the user is referring to something they have spoke about before
* "PROGRESS" - the user wants to discuss their progress, understand what they are learning or change their focus
* "PROFILE" - the user wants to change or view their profile

You should respond with the JSON:

{ "agent": "GREETING" | "CONTINUE" | "HISTORY" | "PROGRESS" | "PROFILE" }

The proxy service uses this prompt to decide where to send the user request. We simply pass in the user request in to

import openai from "../lib/openai";

const prompt = 'OUR PROMPT';

type Message = {
  content: string;
  role: "system" | "user" | "assistant";
  type?: string;
};

async function main(request: string) {
  if (!request) {
    return { agent: "ERROR", message: "Invalid request" };
  }

  if (request.toUpperCase() === "HELP") {
    return { agent: "HELP" };
  }

We have a shortcut method of 'HELP' for if a user gets stuck in a path.

  try {
    const chatCompletion = await openai.chat.completions.create({
      messages: [
        { role: "system", content: prompt },
        { role: "user", content: request },
      ],
      model: "gpt-4o", // you could use a different model here
      response_format: { type: "json_object" },
    });

    const response = chatCompletion.choices[0].message.content;

    if (response) {
      try {
        return JSON.parse(response);
      } catch (error) {
        return { agent: "ERROR", message: error.message };
      }
    }

    return { agent: "ERROR", message: "Invalid response" };
  } catch (error) {
    return {
      agent: "ERROR",
      message:
        "Unable to contact the server at this time. Please try again later.",
    };
  }
}

The try/catch around the response parsing is to ensure we are receiving JSON from the AI response. Normally setting the type as json_object is enough, but it's worth having a safety check.

async function routeChat(content: string, id: string): Promise<RouteResponses> {
  const userData = getUserData(id);

  let route: Route = { agent: Agent.ONBOARDING };

  if (userData.state?.isOnboarded || false) {
    if (userData.state?.journey) {
      route = { agent: userData.state?.journey };
    } else {
      route = await proxy(content);
    }
  }

  let threadId = userData.threadId;

  if (!threadId) {
    const thread = await openai.beta.threads.create();
    threadId = thread.id;
    setThreadId(id, threadId);
  }

  let responseList: Array<any> = [];

  if (route.agent === Agent.ONBOARDING) {
    const onboardingResponse = parseResponse(
      await onboarding(content, threadId, id)
    );
    responseList.push({
      ...onboardingResponse,
    });

    if (onboardingResponse.completed === true) {
      setUserData(id, { state: { isOnboarded: true, journey: Agent.TRIAGE } });
      const coachingResponse = parseResponse(await triage(content, threadId));
      responseList.push({
        ...coachingResponse,
        agent: Agent.TRIAGE,
      });
    }
  }

  if (route.agent === Agent.TRIAGE) {
    responseList.push(parseResponse(await triage(content, threadId)));
  }

  if (route.agent === Agent.COACH) {
    if (userData.state?.journey !== Agent.COACH) {
      setUserData(id, { state: { ...userData.state, journey: Agent.COACH } });
    }
    responseList.push(parseResponse(await coach(content, threadId)));
  }

  if (route.agent === Agent.GREETING) {
    responseList.push(greeting(userData));
  }

  if (route.agent === "HELP") {
    responseList.push({
      content: `I can help you with X.

      What would you like to talk about?`,
    });
  }
}

As you can see, each 'agent' uses the same consistent OpenAI thread, but has a different context.

Writing one involves understanding where the organisation currently is and what specific goals and objectives need to be achieved to align with the overall business goals. It can be used to provide transparency to the rest of the organisation on what your team are trying to achieve, and can be used as part of a business case for where you need investments to directly support broader business objectives.

I tend to split my technical strategies in to three sections:

• Where we are
• Where we are going
• How we are going to get there

Let's take a closer look at those sections below.

Where we are

The "where we are" section looks at the current technological landscape for your organisation. It should give an overview of where you are at, and then discuss the strengths and weaknesses of your existing tech stack.

There may be many reasons why your tech stack needs improvement. Maybe your product requirements have changed and your stack isn't there right fit. Maybe technology has moved on and there is a better solution available. Maybe you took a lot of shortcuts to get to where you are now such as buy vs build. Maybe a competitor has found a better way.

Where we are going

The "where we are going" section should detail what the technical strategy is to meet the upcoming business goals.

Look at the vision and the mission of the company and that should guide how you prioritize what to work on. For example, if there are ambitious targets in the sales team then scaling the solution may be high on the list of what needs to be done. You can use SMART goals to help you understand what you need to accomplish.

How we are going to get there

The "how we are going to get there" is a great place to lay out your blueprint for the "what" needs to be done. It should be in a format that everyone can easily understand and refer to when they needed. As a technical leader, your team will use it to guide them in what to build whilst other teams and leaders will be able to use it to understand what you are planning to achieve.

With these three areas documented and updated as the business goals change, it will always be clear to the organisation how the technology teams are supporting the business.

I'm a big fan of the Obsidian writing app and have been using it's calendar and template plugins to produce a daily note template which I fill out each morning before stand-up.

I've experimented for a while with which details I would like to capture each day to plan and record my day, and here's where I have landed:

1. I need to know how much of my day is going to be spent in meetings vs doing - so I track my meetings for the day. Ideally I would sync this to my calendar, but I haven't done this yet.
2. I need to prioritise my tasks. I'm using the time management analogy "rocks, pebbles and sand" to ensure the important tasks are surfaced to the top.
3. I have some honest questions in there - I don't answer them every day, but I do think about them. For example, "What is keeping me at night?". It may be work related or personal, but it's something I may want to solve within today's schedule.
4. Finally I have some start of day and end of day tasks such as checking email, Slack and reviewing the teams progress and any new bugs identified. You can find new bugs in JIRA with the JQL query issuetype = Bug AND created >= -1d ORDER BY created DESC.

So without further ado, here is my Markdown template!

## Start of Day

* [ ] Check email
* [ ] Check Slack
* [ ] Review JIRA task board
* [ ] Review new JIRA bugs

## Thoughts

**What's keeping me up at night?**


**What do I feel stuck on?**


**What am I avoiding?**


**What's making me uncomfortable?**


## Today's Meetings

**Meetings duration: x hrs**
* [ ] 9:45 - 10:00 - Engineering Stand Up

## Today will be successful if...

?

## Today's Tasks

**≤ 1 Big Task**
* [ ] Task 1

**≤ 2 Medium Tasks**
* [ ] Task 1
* [ ] Task 2

**≤ 3 Small Tasks**
* [ ] Task 1
* [ ] Task 2
* [ ] Task 3

## End of Day

* [ ] Add tags to daily note
* [ ] Check email
* [ ] Clean up inbox
* [ ] Check tomorrow's calendar
* [ ] Clean up desktop, downloads

## Notes

#dailynote #jan2024 #year2024

Being able to recover quickly from failure is more important than having failures less often.

• John Allspaw

In technology, failure is inevitable. Things will go wrong. So rather than hoping they don't, it's better to plan that they do.

Here are some of the things I think work well for when you have an incident. As you'll notice, they mostly require upfront planning. If you've found yourself already in the incident, it's likely too late.

Know what to do

Ensure there is a procedure for what to do in an incident. It should cover the following areas:

• Identification
• Containment
• Resolution
• Maintenance/Actions

Know how to contact the team

Set up a call tree with the team's numbers and locations. There may be a on-call rota, so link to that too.

Also include the numbers for stakeholders who will need to know how to handle customer complaints, the press .etc

Create an incident check-list

Often, incidents follow the same patterns so having a check-list will allow you to quickly find or disregard common issues. Some of the items to include on the list would be:

• Has there been a new deployment at the same time as the incident?
• Has anyone changed a configuration setting recently?
• Are our system dashboards reporting healthy?
• Are any of our vendors down?
• Is there a spike in errors in your logging software?
• Have we hit any API limits?

You can add links to the checklist so whoever is running the incident can just click through to check each one.

Agree your war room strategy

When there is an incident, know how your team will collaborate.

• Is it a video call or a Slack Huddle? Is it an existing room, or a room created especially for the incident?
• Who will communicate to the rest of the business what is going on? How often will they do that?

Agree on it and document it so everybody knows.

Run a Post-Mortem

Running a post-mortem on an incident is a great way to stop it happening again. Even smaller incidents can bring light to issues they may cause bigger problems later on.

The post-mortem should be carried out with the team that were involved in the incident and any other security or developers that work in that area. Allow the team to talk through the problem and capture notes.

Most importantly, make sure you review the incident reports once a quarter to ensure the actions recorded actually get actioned!

Here's a Markdown template of my Incident Post-Mortem report:

## Executive Summary

- 3 or 4 bullet points of what went wrong and how it was resolved.

## Stats

- Number of affected users:
- Time to acknowledge:
- Time to resolve:
- Total downtime:

## Timeline of Events
| Date/Time | Event |
| --------- | ----- |
|           |       |

## Client Impact

Details on any annoyed clients or critical client problems that were caused by the incident.

## Analysis
* Lead-up:
* Fault:
* Detection:
* Response:
* Recovery:
* Recurrence:

## Root Cause (5 whys)
### Why?

### Why?

### Why?

### Why?

### Why?

## Resolution
### Short term
* What was done in the heat of the moment (or shortly after) to resolve?

### Long term
* What needs to be done longer term to stop this from happening again?

## Lessons Learned
* 2 or 3 bullet points on what was learnt

## Action Items
* Links to JIRA tickets with resolution dates

Good luck with your next incident!

Please note: Since writing this article, OpenAI have introduced threads which is a far better way of handling message streams.

By now, you cannot have avoided hearing about the hype train that is ChatGPT. AI is here, and it's likely to take over a lot of the tasks we used to do manually.

One of the things ChatGPT is good for is impersonating a persona and having a discussion. In fact, it's pretty easy to build a simple wrapper to do just that and chat to AI on your favourite platform. Let's take a look at how we can do this with ChatGPT on WhatsApp using Twilio.

How does it work?

First, let's take a look at what we need to build:

DIAGRAM

So essentially we will build some kind of middleware that sits between WhatsApp and ChatGPT to be able to provide the right context to the system. In a production system, you would likely put this into a database but for the purposes of today's example, we will keep it in memory.

To run the AI Assistant, you'll need to set up a Twilio trial account. They have a WhatsApp sandbox service you can use until you are ready to use a real phone number.

Building the app

The app will run on Node.js and Express; use dotenv for environment configurations; and use the OpenAI and Twilio APIs.

npm install dotenv express openai twilio

We will have a single POST endpoint. I'm not going to detail how to use Express here - there are plenty of tutorials for that - but the base of your code will look something like this:

const express = require("express");

const app = express();
const port = 3000;

app.use(express.json());

app.post('/message', async (req, res) => {
  // code will go here
});

app.listen(port, () => {
  console.log(`Starting app on port ${port}`)
})

We'll need to grab some API keys and config to make this work:

• An OpenAI key
• A Twilio Account ID
• A Twilio Auth Token
• A phone number on Twilio

These should live in a .env file like the one below:

TWILIO_ACCOUNT_SID=
TWILIO_AUTH_TOKEN=
TWILIO_NUMBER=
OPENAI_API_KEY=

We can then refer to them at the top of our file:

const { Configuration, OpenAIApi } = require("openai");

require("dotenv").config();

const configuration = new Configuration({
  apiKey: process.env.OPENAI_API_KEY
});

const client = require('twilio')(process.env.TWILIO_ACCOUNT_SID, process.env.TWILIO_AUTH_TOKEN)
const twilioNumber = process.env.TWILIO_NUMBER;

const openai = new OpenAIApi(configuration);

We also probably want to include our prompt toward the top of the file (or in a secondary file):

const prompt = `Add prompt here`;

Our POST endpoint will be responsible for handling:

• receiving a message from the user
• sending the message stream to OpenAI
• and then sending the response to the user.

For this simple demo, I've created an in-memory JSON object that stores the user's phone number and message stream - but you will want to store this in an encrypted database on a production environment.

app.post('/message', async (req, res) => {
  const { From, Body, ProfileName } = req.body;

  // create a new user if the number doesn't exist
  if (!messages[From]) {

    messages[From] = {
      name: ProfileName,
      chat: [prompt] // add the base prompt
    };
  }

The message is received by the POST endpoint. We then determine if we already have this user in our object. If we don't, we create them and add the initial prompt to our chat message stream. If we do, we retreive the chat history.

  const currentMessageStream = messages[From].chat;

  // add the user message to our message stream
  currentMessageStream.push({"role": "user", "content": Body});

Now we have the message stream, we can push the user's new message to the array.

  const response = await openai.createChatCompletion({
        model: "gpt-4",
        messages: currentMessageStream,
        max_tokens: 120,
        temperature: 0.5
      });
  const reply = await response.data.choices[0].message.content;

  currentMessageStream.push({"role": "system", "content": reply});

Next, we send the user's message to OpenAI and wait for a response, before recording that in our message stream.

  return await client.messages.create({
      from: `whatsapp:${twilioNumber}`,
      body,
      to
    });

  res.send('')
});

Finally, we send the message back via WhatsApp to the user, and tell Express we are done with the request.

Running our app

With that complete, it's now time to run our Node app with node start. If you've been following along, you should have the app available on PORT 3000.

With the app up and running we need to configure Twilio's WhatsApp to use the service. The easiest way to do this locally is to use Ngrok (brew install ngrok/ngrok/ngrok). Once ngrok is installed you can run ngrok http 3000 and copy the forwarding address.

Log in to Twilio and paste the forwarding address in to Twilio's WhatsApp webhook

Within the same page, use the 'Sandbox participants' details at the bottom of the page to add the WhatsApp number, and then type and send the code as join [code].

With these steps complete, you should now be able to chat to your very own WhatsApp chat bot :)

Imagine it's your first day at a new employer. You're equal parts excited, equal parts nervous. You turn up, get handed a laptop (hopefully) and get told to get on with it. So you sit down, and you turn on the laptop. Maybe set up your username and password if they haven't been done for you.

As a first install, you go to download our favourite browser. So you open Safari (sorry Safari you're not my favourite) and then you realise it... you don't have the WiFi code. You're sitting in a room full of people you've never met. You're meant to know what your doing, and you don't even have the WiFi code.

You pluck up the courage to get the code, log in to the WiFi and start downloading software. Everyone is busy dealing with whatever feature is running late and needs to be delivered yesterday. And you're sitting there again... any chance of some kind of onboarding? Or at least a onboarding Confluence page?

This has happened to me... I joined a company and there was no onboarding documentation whatsoever. And guess what? It took ages to get anyone up to speed on the systems! Hmmm.. I wonder why.

In my case, I made it my mission to make sure that there was good onboarding documentation. And I've made it my mission in every company since. Getting my team up to speed when they join is a top priority. So what can we do?

Create a Slack welcome workflow

If you're using Slack, you can use it's built-in Workflow builder to generate a message when new members join your Slack community. You can use this message to share important links with your new starters - such as the Code of Conduct and any useful onboarding documentation.

Setting up a Slack welcome message

Create a hub

Start by having a central place where new starters can access all the information in one place. I find Confluence works really well for this. You can have pages with information about your systems and link out to documentation that lives elsewhere. You can also link out to important tools and repos. Great.

So what kind of pages should we have in this hub?

• Who are you people? - The new starter is sitting in a room full of people they don't know. Or worse, they are at home wondering who all these people are. A 'meet the team' page is a great place to start introducing the who. I find it works best when there's a photo, the person's name, how to contact them and the days they are in the office.

My entry in who is who.

• Why are we doing this? - Context is everything and a new starter has none. How can they sign up to your mission if they don't know what it is? Depending on the age of the company, this could be one or two parts.

  • I like to set up a 'Technical Strategy' which outlines the following: "Where we are"; "Where we are going" and "How we are going to get there".
  • If the company has a long history of technology changes or acquisitions, then it can also be useful to have a page that just shares some context on that. e.g. this service was named this because....; or this codebase was a result of the merger with....

• Onboarding checklist - Tell the employee what they need to do to have a successful first day. Are there company policies to agree to? Is there particular software that everyone needs (Slack?)? Do they need to spend some time with the product so they understand it?

• Software checklist - Usually I'd also have a page that shares links out to what different disciplines need to install to get the product up and running on their machine. Include some 'troubleshooting gotchas' here to help out with the common stumbling blocks - and encourage new starters to add to it.

• Day 1 glossary - It's likely when your new starter joins, they will think everyone else is speaking a different language. Creating a day 1 glossary which covers some of the main terms people use can really help. It doesn't need to be a complete glossary, just anything to give your new starter a power-up on day one.

• Set some engineering responsibilties - With some things like housekeeping, you can be clear at the start on your expectations and therefore create a baseline. My personal recommendations are:

  • Done is better than perfect
  • Always leave something better than you found it
  • Communication is critical (don't sit on a problem)
  • Ensure features are well-documented (this can be self-documented)
  • Don't get stuck in analysis paralysis
  • Update dependencies as we go
  • Don't be afraid of the unknown

• Coding principles - Lastly, set some coding principles. What are the things you want the developer to keep in mind during their tenure in your team? My personal choices are:

  • KISS - Keep it simple stupid
  • AHA - Avoid hasty abstractions (DRY with care)
  • YAGNI - You ain't gonna need it
  • Single Responsibility Principle
  • Loose Coupling Principle

Assigning a buddy

Even if you're the most prepared onboarder in the world, your new starter is going to have questions. Assign them a buddy for their first couple of weeks - a go to that they can speak to regardless of the question. It'll double up as allowing them to create a real bond with someone.

Don't forget to check-in yourself at the end of the week too - both with your new starter and their manager. Understanding what is working and what's not early on means you have a much better chance of course correction if needed, and getting to know what your new starter thinks of your team and processes if not.

Defining culture

Team culture is a very important part of any team. Getting it wrong can have a serious effect on everyone’s productivity - and their well-being too. Culture can't be dictated - it has to be a team effort. You can however, give your team some pointers on what they should be thinking about whilst working in the team. Things like:

• assume good intentions
• be the support you would like to have yourself
• don't hide or control information are good starts.

With these techniques in your arsenal, you'll be onboarding new starters in no time!

When I took over leading the UK & European team at LifeWorks, one of my first tasks was to ensure everyone on the team was aligned properly. Historically, there had been siloed disciplines and a bit of a blame culture. For example, we being are blocked by X team I don't know what they are doing.

I fully believe that to change the culture you need to start at the top and lead by example. I also believe that one person cannot dictate a culture by themselves, it needs to be something that everyone is willing to invest in.

So I sat down with my leadership team and a pile of post it notes and I asked them to write down on these post-it notes the values they thought were important to have within their teams.

After around 15 minutes, we started grouping the post-its in to similar categories, and then proceeded in a round of (dot voting)[https://www.nngroup.com/articles/dot-voting/] to establish which values we wanted to bring forward. We then took the top six values and wrote up what they meant.

Once we had agreed our values, it was important for us to be able to keep ourselves and each other honest on them. So in our fortnightly team lead meetings, I asked everyone to come with two "awards" and we would go round the room at the start of the session and share our picks.

The first was an award to one person in the leadership team who had demonstrating one of these value, and explain why, to ensure we hold others accountable.

The second was award to ourselves for demonstrating one of the values, and explain why, to ensure we hold ourselves accountable.

It felt a bit strange at first, handing out pretend awards to each other - but it got us in the mindset for how we wanted to interact with each other. Once the teams were working better with each other we reduced the frequency - but at that point, the values were embedded in leaderships mind and collaboration and culture massively improved.

Here are the values we came up with:

• Accountability

  • Being responsible for your actions
  • Being responsible for the actions of your team
  • Don't blame - fix, learn and move on

• Collaboration

  • Working together
  • Being one team
  • Keeping integrity as a team

• Empowerment

  • Empower our teams to make their own decisions
  • Empower our teams to succeed
  • Empower and challenge our teams to be better versions of themselves

• Transparency

  • Not hiding or controlling information
  • Better communication
  • Understanding others perspectives and listening to the team
  • Don't ignore problems - we might not be able to fix something right now, but we should record and be aware of the issue

• Trust

  • Be the support you would like to have
  • Live what we preach as a business
  • Belief that other have good intentions and work to the best of their abilities

• Vision

  • A compelling and clear reason to take your team in a certain direction
  • One common vision within the business
  • Understand our business
  • Make a difference

It would seem impossible to 24 year old Andi that I would stay at the same company for almost a third of my life. After a couple of years at two previous jobs I found myself sitting in an interview to be a web developer at AKQA. From the interview I could tell that this company would challenge me in ways I had never been challenged before - with an unrivaled design team, a drive for innovation and a fine eye for detail AKQA has responsible for producing a wealth of incredible experiences.

It's been a wild adventure working for one of the world's most respected and innovative agencies. I worked my way up the ranks and it's been my absolute pleasure to lead the web development team for the last few years.

We've gone through many changes in my time at the agency. When I started designers used to throw fixed sized PSDs over the fence to developers who would sit in a different part of the building trying to make transparent PNGs work for rounded corners in IE6. Nowadays, we have a wealth of different device resolutions and a collaborative environment where Creative, UX and developers work together with not a rounded corner in sight (now it's easy to code them).

I feel so incredibly lucky to have worked on so many projects for so many different respected clients on such a wide variety of projects.

• I've helped build massive digital platforms, car configurators, online games, competitions and many smaller campaign pieces.
• We've built web applications, mobile applications, hybrid applications, chat bots, Alexa skills and retail experiences.
• We've built car configurators, shoe configurators, running configurators and front end build configurators.
• We've used content management solutions of all scales from experience manager AEM to CMS solutions Sitecore, Wordpress and Drupal to headless CMS with Contentful and good old plain JSON.
• I've worked first hand with technical teams from other AKQA offices, BMW, Nike, Delta and Facebook.
• The work I've completed has won many awards including Cannes Gold Lions, Webby awards and a few FWA Site of the Days.
• And I've got to see parts of the world I never thought I would when I travelled to Amsterdam, San Francisco, Munich, Zurich, Boston and Atlanta to work with clients on a huge variety of solutions.

I have many, many fond memories of working at AKQA, but the highlight has to be when we launched Heineken Star Player at the Emirates Stadium to a room full of the press. To see something we built used and loved by a room full of people was incredible. Walking around the room and watching football fanatics and sports pundits enjoying the game alongside the beautiful game was an unforgettable experience.

And with all those memories I leave with a heavy heart. Although my journey at AKQA has come to an end, AKQA will always be a part of me. I have learnt and gained so much from my time at the company. I feel so incredibly privileged. Don't get me wrong - it has been hard at times. But it's also been very rewarding.

AKQA are currently hiring - so if you'd like to experience some of the things I mentioned above and work with a great team, please do get in touch with them.

I can't wait to share with you what I'm up to next very soon. To the next adventure!

Today I spoke at jQuery UK on my quest to find the Perfect Workflow.

Unfortunately, we couldn't fit everyone who wanted to come to the talk in the room. If you missed the talk, I've recorded this screencast. There's more information below the video.

Part of my job as a Technical Architect is to make sure that projects start with the right set of base tools and the right workflow. But during my quest I realised that there is no such thing as a perfect workflow for everybody, because everyone’s requirements are different. We all use different tools and have different coding styles. And a workflow that enforces any rules that conflict with these requirements is going to get cursed from start to finish.

So my quest morphed in to looking in to ways how we can improve our workflow.

I started by splitting our workflow in to three sections to make sure that we are using the right tasks for the right part of project:

Setup, Develop and Build

• The Setup stage should focus on the foundations of our project
• The Develop stage should focus on performance, so that you can make changes to your site and see the results immediately.
• The Build stage should focus on file size optimisations, concatenation, minification .etc.

The tasks and tools I covered were:

Setup

• GruntJS
• GulpJS
• Yeoman
• Auto load tasks
  • Grunt - npm install load-grunt-tasks
  • Gulp - npm install gulp-load-plugins
• Start a local server
  • Grunt - npm install grunt-contrib-connect
  • Gulp - npm install gulp-connect
• Workflow Performance
  • Grunt - npm install time-grunt
  • Gulp - npm install gulp-duration
• Make Grunt Faster - npm install grunt-concurrent

Develop

• Use Autoprefixer
  • Grunt - npm install grunt-autoprefixer
  • Gulp - npm install gulp-autoprefixer
• Watch & LiveReload
  • Grunt - npm install grunt-contrib-watch
  • Gulp - gulp.watch
  • LiveReload extensions:
    • Chrome
    • Firefox
    • Safari
• Compile Changed Files
  • Grunt - npm install grunt-newer
  • Gulp - npm install gulp-changed
• Live Editing Our Files

Build

• Compile CSS/JS and replace references in HTML.
  • Grunt - npm install grunt-usemin
  • Gulp - npm install gulp-usemin
• Combine Media Queries
  • Grunt - npm install grunt-combine-media-queries
  • Gulp - npm install gulp-combine-media-queries
• UnCSS
  • Grunt - npm install grunt-uncss
  • Gulp - npm install gulp-uncss
• Streamline Modernizr
  • Grunt - npm install grunt-modernizr
  • Gulp - npm install gulp-modernizr
• Minify Images
  • Grunt - npm install grunt-imagemin
  • Gulp - npm install gulp-imagemin
• Compress Files
  • Grunt - npm install grunt-contrib-compress
  • Gulp - npm install gulp-gzip
• Compress Files with Zopfli
  • Grunt - npm install grunt-zopfli
  • Gulp - npm install gulp-zopfli
• Shrinkwrap - npm shrinkwrap

Thanks to everyone who came along to the talk today, I hope you found it useful! Please let me know your thoughts in the comments below, or @andismith on Twitter.

Creating a list of posts

Assemble allows us to specify lists of posts and/or pages as collections, which we can then use to loop through and get our content. To specify a collection, we need to edit our Gruntfile.js and add a collections object to our posts:

options: {
  collections: [{
    name: 'post',
    sortby: 'posted',
    sortorder: 'descending'
  }],
  ...

This collection looks for a YAML parameter of post to choose which posts to contain, so we need to add a new value to our file src/content/blog/first-post.md:

---
title: "First!"
posted: 2014-01-28
post: true
---

This is my first post!

This will allow us to identify our blog posts as posts, and keep our pages out of the collection.

With our posts marked up we need to create a loop for our collection. Open up src/bonnet/layouts/page.hbs and include the following code after our closing {{/markdown}} tag:

<ul> {{#withSort post 'data.posted'}} {{#each this.pages }} <li>{{
this.data.title }}</li> {{/each}} {{/withSort}} </ul>

Here we are telling Assemble that with our collection 'post' ordered by the date posted, we want to loop through the collection and output the page title.

If you re-run grunt from the Terminal/Command Prompt you should now see a list of a single item on all your pages. Let's add another post at src/content/blog/second-post.md:

---
title: "Second!"
posted: 2014-01-30
post: true
---

This is my second post!

If we re-run grunt again we should see two items in our list. Horrah!

A list with links

A list is great, but it would be great if users could click our list to go to a blog post.

In an ideal world, we would be able to output the path of the post with {{ this.dest }}, but this path includes the 'dist/' folder and to my knowledge there is no way to remove this through Assemble. Instead, we need to create our first Handlebars helper.

Create a new folder called helpers in your bonnet directory and add a file called helpers.js. Inside, we'll create our first helper:

module.exports.register = function (Handlebars, options) {
  "use strict";

  Handlebars.registerHelper(
    "replaceStr",
    function (haystack, needle, replacement) {
      if (haystack && needle) {
        return haystack.replace(needle, replacement);
      } else {
        return "";
      }
    }
  );
};

Our helper is called replaceStr and will search haystack for needle and replace it with replacement.

We need to tell Assemble where our helpers live, so in our Gruntfile add the following line to Assemble's options:

helpers: './src/bonnet/helpers/**/*.js',

With these parts completed, we can now add the blog URL to our code:

<li><a href="{{ replaceStr this.dest 'dist' '' }}">{{ this.data.title
}}</a></li>

If we re-run grunt now, our index page will now link to our post pages; and our post pages will link to each other. And thus, we have now created a list of posts for our blog that sits on each page.

If you've not been coding, you can access our progress so far by cloning the example repo:

git clone https://github.com/andismith/assemble-blog-template.git
git checkout v2
npm install

Coming Up

I'll be posting a number of shorter tutorials showing how to add extra functionality to your blog starting with adding categories and pagination.

Stay tuned!

If you're unsure what a static site is, that's ok. It's a site where the pages are compiled, constructed and stored before the user requests them, usually at build time. So when the user hits the page, they are just requesting the pre-generated HTML output. Static sites can still use JavaScript for client side functionality, so AJAX GET requests, animations and interactivity are still all possible - but there is no dynamic data.

With the redesign of my blog, I wanted to move from Wordpress to a static site so I could simplify my setup and so I could write my posts in Markdown. Wordpress is a great blog CMS, but it can be difficult to insert code in to blog posts. In Markdown, I have full control over how each of my posts look.

Assemble vs Jekyll

Originally when I began the redesign I used Jekyll - a static site generator from the creators of Github. But I found Jekyll had a couple of things I wasn't happy about.

The main reason was because of a couple of limitations in Jekyll. I wanted to have multiple sets/collections of posts on my site - a set of posts about my blog; a set of posts for my portfolio; and another set of posts; and I wanted to use the lists of posts on multiple pages. I also wanted to have the freedom to re-order them. In Jekyll you can only have one set of posts and the filenames must be prefixed by a date (which is how they are ordered). Happily, in Assemble you can have as many as you like in any order you require.

In Jekyll you can only have one set of posts in descending date order. In Assemble you can have multiple in any order.

The JavaScript purist in me wanted to run everything in JavaScript, and Jekyll has a dependency on Ruby. At the time I was having to run Grunt and then run Jekyll to build my site. I really wanted to combine these two processes in to one and use grunt-connect and grunt-watch to ensure immediate generation of new content. There is now a Grunt task for generating Jekyll sites which solves this issue.

Assemble is still fairly new and features are being added as they are requested. Being on the very bleeding edge can be a little frustrating when something that should work doesn't and I found myself having to come back to Assemble every few weeks to see if it was now possible for me to do what I wanted to do with it. Happily, Assemble is in active development and raising an issue in Github generally results in a response and the right functionality being added.

Assemble is in active development and raising an issue in Github generally results in functionality being added.

There's lots of documentation for Assemble but what you want is often hidden away so deep you have to know exactly what to look for. The documentation and example repositories never really cover the use case of something like creating a normal blog (hence these posts) - there is an example Assemble blog repository but it requires both the post files and a JSON file with a list of the posts which means you have to maintain two areas to write a new post. I really didn't want to do this.

So is Assemble right for you? It depends on your use case. If you just want one stream of posts and to be up and running in a few hours then I'd probably recommend Jekyll. If you're comfortable with JavaScript; want more flexibility and feel like you'd be happy writing additional helpers for the Handlebars templating language then Assemble may be what you're looking for.

If you want more flexibility than Jekyll, then Assemble may be what you're looking for.

This series of posts will aim to guide you through how to create a site not dissimilar to the one here. By the time we've finished the series, you'll have a site that includes:

• A homepage.
• A blog section (and the knowledge of how to create new sections).
• Categories.
• Pagination.
• The ability to add custom CSS and JavaScript on a per blog basis.
• Comments from Disqus and code syntax highlighting from Prism.
• A RSS feed.
• A contact form.

How Assemble works

Before we start building in Assemble it is important to know how it works.

A page is constructed from the data we make available to it. It takes the Markdown content and YAML data we specify in our Markdown file and combines it with any extra data files we have specified, together with a number of other useful data pieces such as the filename.

This data combination creates a JavaScript object that we can output and manipulate on our page using Handlebars templating.

Every page requires a layout, which acts as a container. Inside the layout, we can include multiple partials that include segments of our page - for example, we may have our site navigation in a partial, so it can be included in multiple layouts or even at the top and bottom of our site. Partials can be included within partials.

As shown in this diagram, the layout forms the shell of the page. Inside, partials contain modules of code such as the header, navigation and sidebar. The sidebar contains partials itself such as social, latest and categories. The page content (or the post content) is included inside the post partial.

With that in mind, let's begin!

Starting With Assemble

This tutorial assumes you already have some knowledge of how Grunt works, and that you have already installed grunt-cli. If you don't, here's a couple of articles to take a look at:

• For the beginner afraid of the command line, Chris Coyier's excellent Grunt tutorial for 24 ways is a great place to start.
• My tutorial on maintaining a better workflow with Grunt for 12 Devs of Xmas is also worth a read.

Creating an empty project in Grunt

Assuming you don't already have an empty project folder, open up Windows Command Prompt or Mac Terminal and navigate to your normal workspace directory. Create a new project folder using mkdir:

mkdir assemble-blog

Move in to the assemble-blog directory and run npm init to create an initial package.json file:

cd assemble-blog
npm init

We'll need to tell our project we want to use Grunt by including it in our package.json, so run the following command to add Grunt:

npm install grunt --save-dev

We will also want to use grunt-contrib-connect, which is a task for running a local server with Grunt. Assemble doesn't require a server to run (it is a static site solution afterall), it reduces complications later.

npm install grunt-contrib-connect --save-dev

Next, we'll want to create a file called Gruntfile.js within our project directory, with the following contents:

module.exports = function (grunt) {
  "use strict";

  grunt.initConfig({
    pkg: grunt.file.readJSON("./package.json"),

    connect: {
      dev: {
        options: {
          port: 8000,
          base: "./dist/",
        },
      },
    },
  });

  /* load every plugin in package.json */
  grunt.loadNpmTasks("grunt-contrib-connect");

  /* grunt tasks */
  grunt.registerTask("default", ["connect"]);
};

Installing Assemble

Now we have a base project directory with grunt and grunt-contrib-connect installed, run the following command:

npm install assemble --save-dev

Once Assemble has been installed, we need to create our project structure. Our directory layout is completely configurable so it can match your requirements, but I found the following works well:

I like to group the parts that compile the pages in to a folder called 'bonnet' (as in car bonnet - let's look under the bonnet to see how the car works), but you could call it anything.

I also include a folder called _pages which is where root level page content will live to stop the content directory getting cluttered.

Rather than manually create this folder and file structure, you can download a zip of the structure here.

We need to tell the Assemble task about our structure, so let's open up our Gruntfile.js and make some changes.

We'll need to load the Assemble task and include a section for Assemble within our grunt.initConfig object. At it's simplest, and if you've followed the structure I've suggested above, your Grunt file should look like this:

module.exports = function (grunt) {
  'use strict';

  grunt.initConfig({
    pkg: grunt.file.readJSON('./package.json'),

    connect: {
      dev: {
        options: {
          port: 8000,
          base: './dist/'
        }
      }
    },

    assemble: {
      options: {
        layout: 'page.hbs',
        layoutdir: './src/bonnet/layouts/',
        partials: './src/bonnet/partials/**/*.hbs'
      },
      posts: {
        files: [{
          cwd: './src/content/',
          dest: './dist/'
          expand: true,
          src: ['**/*.hbs', '!_pages/**/*.hbs']
        }, {
          cwd: './src/content/_pages/',
          dest: './dist/'
          expand: true,
          src: '**/*.hbs'
        }]
      }
    }
  });

  /* load every plugin in package.json */
  grunt.loadNpmTasks('grunt-contrib-connect');
  grunt.loadNpmTasks('assemble');

  /* grunt tasks */
  grunt.registerTask('default', ['assemble', 'connect']);

};

Like most Grunt tasks, Assembles accepts an options object and any number of tasks. Here we've created a task called 'posts' which will (surprise, surprise) process all our posts.

Within our options section, we have added paths to match the directory structure we created earlier and have included the settings Assemble requires to get up and running.

• layoutdir: Should be set to the path where any layouts we create will be located.
• layout: This is the default layout that should be used for our files, the file will be suffixed with .hbs.
• partials: Should be set to the path where any partial layouts we create will be located.

Our posts task files object contains two arrays with file settings.

The first tells Assemble to look for all our content pages (with the extension .hbs), which is any file not in the _pages directory. Once these files are processed they will be placed in the ./dist/ folder.

The second tells Assemble to compile the contents of the _pages directory. We also want these files to be placed in the ./dist folder, so we include the _pages page in our cwd.

Now we've set up Grunt, it's time to add some files!

Creating our base site

To get us started, let's create some files that will construct our site:

The layout

src/bonnet/layouts/page.hbs contains three partials - the site header, the page content and the site footer. We include a partial in Assemble using {{>partial-name}}.

{{>site-header}} <div class="page-content"> <h2>{{ this.page.title
}}</h2> {{#markdown}} {{> body}} {{/markdown}} </div> {{>site-footer}}

The partials

src/bonnet/partials/site-header.hbs contains the top of our HTML document, and it is just static HTML (for the moment):

<!DOCTYPE html> <html> <head> <meta charset="utf-8" /> <title>My
Site</title> </head> <body> <div class="header"> <h1>My
Site</h1> </div>

Finally, we need to create src/bonnet/partials/site-footer.hbs which contains the bottom of our HTML document, and again is just static HTML:

</body> </html>

With our site building blocks completed, it's time to add some content!

The content

To start with, we will add two content files. The first is the homepage of the site and the second will be a test blog post. Our content files contain YAML (Yet Another Markup Language) for page data before using traditional Markdown for their content. If you've not used YAML before don't panic, it should be easy to see how it works from the examples below.

src/content/_pages/index.hbs will look like this:

---
title: "Welcome"
posted: 2014-01-28
---

Welcome to my site, built in Assemble!

Our first post located at src/content/blog/first-post.md will look like this:

---
title: "First!"
posted: 2014-01-28
---

This is my first post!

With all this complete, it's time to see what it looks like when generated. Back on your Terminal/Command Prompt pointing at your project directory type:

grunt assemble

Let's see what we've got!

If it has worked correctly, Assemble should generate two pages - dist/blog/first-post.html and dist/index.html. And when we open up our site (at http://localhost:8000/) in our browser, we should get this:

Beautiful!

If you've not been coding, you can retreive our progress so far from Git by running:

git clone https://github.com/andismith/assemble-blog-template.git
git checkout v1
npm install

Coming Up

Now we've got up and running with the basics, we're ready to look in to bigger and better things. The next post covers creating a list of posts in Assemble - and is available right now!

Stay tuned!

Thanks to our package.json files, it's easy for another developer to get set up on our project in seconds by typing npm install. But what happens when some time has passed and your project dependencies have moved on? A new version of a package may introduce a new bug, or completely change its functionality altogether.

It's possible to have some control over dependency versions with the version numbers you put in your package.json file, but it's extremely difficult to have control over the version numbers of your dependencies dependencies.

For this reason, it's a good idea to run npm's shrinkwrap feature to lock down the versions of dependencies you are using once you have reached a stable point in development.

To do this, open up Command Prompt or Terminal and navigate to your project's root folder. Then type:

npm shrinkwrap

Calling npm shrinkwrap scans your node_modules folder and creates a npm-shrinkwrap.json file that contains a complete breakdown of all the dependencies (and versions) of your project, which npm will then use as its reference when creating a new install.

You can read more about shrinkwrap in the npm documentation.

January had only just begun when I was flown over to San Jose to work at Facebook for a two week time-intensive project for one of our clients. The brief was to come up with a tightly integrated social experience for a fitness application.

January had only just begun when I was flown
over to San Jose to work at Facebook.

I learnt so much about how social works from the team at Facebook as well as gaining an insight in to their philosophies on shipping software, it was truly inspiring. I think we were also able to teach the Facebook developers a few things about their API coming from the perspective of users of the API.

In March, I got married to the beautiful Amy Adams (now Smith) after 7 years together. We got married in a manor house in Dorking. It tried to snow four times during the day, but it didn't put a dampener on our special event. We went to Mexico for our honeymoon in April.

In May, I launched Dev Tool Secrets - a site dedicated to exposing more about the developer tools included within each browser. The site is hosted on Github so anyone can add contributions, I will be adding more tips during the next few months. I went on to do a number of presentations during June and July at London meet ups on developer tool secrets.

My Can I Use widget which allows bloggers to list browser compatibility when discussing features also gained a lot of traction during May thanks to a blog post from Bruce Lawson, and is now featured on several sites (such as CSS3 Click Chart) as well as in print on the "projects" front page of NET Magazine!

In July I launched [Grunt Responsive Images](https://github.com/andismith /grunt-responsive-images), a Grunt task that resizes images based on a number of configurable parameters, especially useful for responsive websites. The plugin came about when I was architecting a solution for using responsive images uploaded by content authors. Grunt seemed like the perfect solution for this problem, and it only took a couple of evenings to get the first version of the plugin up and running.

In July, I also attended Hacked.io, a 24 hackathon in London's O2 arena. Working alongside Abid Dinn, Chris Marsh and Tom Maton we produced a music quiz that hooked in to the Nokia Music API. We won 2 prizes - the Nokia Music API challenge, and one of the Heroku challenges. It was an awesome weekend.

In July, I also attended Hacked.io, a 24 hour hackathon in London's O2 arena. We won 2 prizes.

In September, I wrote an 7 page article for NET Magazine on browser developer tools which became the cover article. It was exciting to see my article displayed proudly on the shelves of the local newsagents; especially as I'd been obsessed with creating my own magazines as a child. I don't think my parents realised back then that one day I would be in print.

During November and December I've been working in Munich working on a exciting AngularJS web application due to launch in the Spring.

For two years prior I'd led a development team prototyping ideas and designs, and this launch will be the first part of the culmination of these efforts. To my knowledge this is one of the most exciting and in depth uses of AngularJS yet.

2013 was full of exciting moments and varied challenges; and I'm looking forward to further challenges in 2014. I already have a couple of articles and talks lined up; and I've got a couple of open source projects that I'll be revealing over the next month or two. If you have a challenge you think I'd be interested in, please do get in touch. Happy New Year!

Being able to apply and remove events with on() and off() is great, but sometimes there is a requirement to either trigger or remove a subset of events that have been added to an element. For example:

$(".item").on("click", doThisCoolThing);
$(".item").on("click", doThisOtherCoolThing);

$(".item").trigger("click"); // both functions are triggered
$(".item").off("click"); // both functions are removed.

Using event namespacing we can assign names to event handlers when we create them, and then use them later on to target specific functionality when we call trigger() or off(). The name you choose for your event namespace should be relevant for the functionality you are calling. For example:

$(".item").on("click.navigate", doThisCoolThing);
$(".item").on("click.notify", doThisOtherCoolThing);

// only the function assigned to the namespace navigate would be triggered.
$(".item").trigger("click.navigate");
// only the function assigned to the namespace notify would be removed.
$(".item").off("click.notify");

It's also possible to use multiple namespaces, like so:

$('.item').on('click.navigate.notify', doThisCoolThing);

// trigger the click event
$('.item').trigger('click.navigate');
function.
// remove the click event.
$('.item').off('click.notify');

Namespacing events in jQuery has been available for some time and isn't limited to just on() and off(). It also works with .bind() and .unbind() too.

This post does not include any code or best practices and it is not a tutorial or guide to writing web pages. Instead the points below are aimed toward explaining what to expect as a web developer, and some of the key things you should consider as early in to your journey as possible.

There are so many things to learn in web development now that it can feel incredibly overwhelming - but it can also be very rewarding. What fascinated me about web development was the ability to create - I love to create - and when I started out building web pages I found it incredibly easy to express my creativity with HTML and CSS in just a few lines of code. I could create something and then publish it on the web for others to see very quickly (which at the start of your career will likely just be your Dad and your best friend).

1. There Are Multiple Ways To Do The Same Thing.

One of the hardest concepts to get your head around when you start working in web development is that there can be be multiple ways to do exactly the same thing.

For example, if you want to create a 2 column blog layout, there are a multitude of ways to do this. For most things, there is no single answer - there are multiple solutions to the same problem. Sometimes there will be solutions that are better suited than others, but there are also solutions that are equally valid as others; or solutions that are better in certain scenarios.

Use variation as a way to encourage your creativity.

Try not to look at this as a negative thing, but instead use it as a way to encourage your creativity. Make a decision on the solution to use this time around and as you use it see what works and what doesn't work. You'll learn more by trying a solution than forever searching the Internet for the perfect answer, because the truth is...

2. Your Code Will Never Be Perfect.

When you look back at the code you have written previously - whether it's one, two or six months later, or even the next day or after the weekend - you will see ways you can make things better. This is a good thing. It means you are learning and improving.

Don't be afraid to write
imperfect code.

Don't be afraid to write imperfect code. With every site you develop, there will be a time that you have to let it go. It is better to be feature complete than to have 5 immaculate lines of code that do 10% of what you were trying to achieve. If someone wants to discuss with you about what you have written, it's an opportunity to ask them how you can make it better. It's a great way to learn; and you will find that different people with different backgrounds will have different experiences they can share.

3. You Will Never Know Everything About Web Development.

(But that doesn't mean you should stop trying)

Nobody can honestly say that they know everything about web development - not every feature, every property and every browser bug. The scope of front end web development is so broad that it covers three completely different languages - HTML (markup), CSS (design and style) and JavaScript (logic).

Each has their own structure, concepts and quirks and each is continually updated with new features. Unless you are building pages from a template, each site you build is likely to require a different configuration and with that come new challenges. There are also libraries, frameworks and APIs that you will need to become accustomed with over time as the situation demands.

The truth is that you don't need to know everything straight away. You need to know how to build a web page that meets your initial basic requirements. Then going forward, you will need to know how to learn; who to talk to or where to go to find out what you need to know to do your next task.

Knowing where to look and how to pick things apart in a skill in itself.

Knowing where to look and how to pick things apart in a skill in itself and one that is very useful. You'll pick up knowledge and learnings as you go along.

4. Google, MDN and Stack Overflow Are Your New Best Friends.

If you have a problem, there is a 99.99% chance that it has already been solved. Multiple times. Using Google to search for a problem can often return the right results if you include the language and browser you are experiencing the issue in, e.g. "css ie6 margin".

MDN (the Mozilla Developer Network) is an excellent source for finding out more detail about HTML elements and attributes; CSS styles and properties; and JavaScript APIs and methods. You can use Google to search MDN by prefixing your search with "MDN", e.g. "mdn box sizing".

Stack Overflow is a place where developers can ask questions and receive answers from other members of the community. It is always worth searching their answers database - particularly if you are unsure of the exact term as the chances are someone with a similar amount of knowledge has asked the question before. In fact so many people have asked questions, I often find I skip the Google search and go straight to Stack Overflow for an answer nowadays.

If you've yet to start your web development journey, Code Academy is as good a place to start as any.

If you're looking to improve your CSS, CSS Tricks is a great site to bookmark.

5. Not Everyone or Everything on the Web is Right.

(Especially me)

Just because someone has written a blog on a subject and that blog is the number one result on Google, it doesn't make what your reading correct. The author may just be really good at optimising their site for search engines (known as Seach Engine Optimisation or SEO).

For instance, there are lots of articles and tutorials online but it can easy to be mislead by one that is out of date. Check the date timestamp on the tutorial you are reading to check if it is using current best practices. If the tutorial doesn't have a date, then its worth cross referencing the material against another article.

Check the date timestamp on the tutorial you are reading.

You can check comments on articles to see if others have left feedback saying something doesn't work (people tend to be more vocal when something is broken) before you go ahead and implement it.

Stack Overflow and MDN work well for getting the right answers. On Stack Overflow, the first or second answer will usually be the answer that you are looking for; and you can see how well received an answer is by the community by looking at the number of votes it has next to it. On MDN, the wiki nature of the documentation means that it can be kept up to date by anybody rather than relying on one particular person to make updates - meaning it is current most of the time.

Knowledge sites that are not community driven like W3Schools often contain outdated information, so use with caution.

This also goes for libraries and APIs. Just because a library exists and has a nice site doesn't mean the library is actually any good. Running a quick Google search for problems with the library takes minutes and can save hours of frustration.

6. Things Will Always Change.

The web is constantly evolving. It has to. It needs to keep up with all the new devices and the functionality that comes with those devices. Some browser vendors now release new versions of their software every 6 weeks and with that new release comes new features.

As an example of change, look at the devices people now use the browse the web. Increasingly people browse on their mobile phones or tablet. Just 3 years ago, the majority of people browsed the web on their computer. Not long before that, there was no such thing as a tablet! Who knows what will happen next.
Don't ever expect to stop learning. There will always be something new to learn.

7. Know Your Tools.

In any career, you can do a better job if you know the tools you are working with. In web development as well as three separate languages, there are lots of tools to learn.

Pick a text editor which highlights HTML, CSS and JavaScript syntax for you and learn useful keyboard shortcuts so you have a smooth development experience.

Choose a browser that will be your primary browser for development and get accustomed to it's Browser Developer Tools. The first thing to find out how to do in the Browser Developer Tools is to see a list of the files that have loaded on your page as an incorrect URL to something the page relies on can stop styles, scripts or images from loading. A 404 error means the file could not be found.

Finally, know the tools your user will visit your site in - download as many browsers as your machine allows - there's Safari, Chrome, Opera, Firefox and Internet Explorer. Get used to checking your work in each of these to learn the quirks and differences between them. The developer tools in each of these browsers include similar functionality, so if you find something useful to debug in one browser, generally there will be a way to do it in the other browsers' tools.

8. Experiment.

When children are learning they often go through a phase of trying things that they know are wrong in order to see what effect it has. They are experimenting, and if you are developing for the web - so should you. I could tell you to make sure you always close your brackets in CSS, but then you are getting second hand information. Try it yourself, see what happens. If you ever see the problem later on in your career (and you will) you will know exactly what to do and where to start looking in order to fix it.

9. Pick Apart Other People's Code.

One of the best things about the web is that it is open. You can view the source of any page and see the HTML markup, CSS and JavaScript using the Browser Developer Tools. Do you like the rounded corners used on your mates' blog? Right click on it and select "Inspect Element" in most browsers* to see how they did it.

Open projects such as the HTML5 Boilerplate and read the comments to analyse why certain parts of code are included. Look at other people's projects on CodePen to see how certain visual effects and techniques were produced.

* In Safari, you'll need to enable the developer toolbar. Go to Safari in the Menu Bar, then "Preferences" > "Advanced" > "Show Develop Menu in Menu Bar".

10. Start a Blog.

The best way to remember what you have learnt is to keep a log of your findings. Writing down what you have learnt will reinforce it in your head and may encourage you to think of "what if" situations.

Writing down what you have learnt will reinforce what you've learnt.

Since we live in a digital age, why not start a blog? This way, people are invited to read what you have learnt and contribute advice to help make you a better developer; and you can use your blog as a test bed for trying out your new coding skills!

For the web developers who are beginning their career, I hope that you have found this list useful and wish you the best of luck with your future webpages! For me, becoming a web developer was the best career choice I ever made.

I'm always looking for talking opportunities so if any schools, colleges or universities (particularly in the UK) would like me to come give a talk on this, please contact me.

If you are a web developer and have any further points to add to this list, feel free to leave a comment! If this post proves popular, I will likely write a follow up that focuses on tips for each of the languages.

In parallel, using a responsive grid became popular as a convienent way of handling column configurations over breakpoints. From simple grids like the one used in Twitter Bootstrap to the SASS driven SUSY that allows you to keep semantic markup while managing columns over breakpoints; grids in a responsive design became popular.

Using these techniques, we could ensure that content was king and provide the optimal experience for our users regardless of how they were viewing our web page.

There Appears To Be a Problem.

But for all the possibilities media queries allow, there appears to be a problem with the current selection of available conditions. We're often told that we should build for content first and not design, yet the most widely used media queries are built in completely the opposite way: min- width and max-width. These two media queries measure the width of the page

• often this is useful but there are situations where this isn't helpful, particularly on larger scale websites.

Suppose we were to create a small module on our page, for example a carousel, which sits across two columns of our three column grid. This module will be used across multiple pages and we are unsure how it will be configured over these pages.

In a responsive design, we may create two or more breakpoints for this module to ensure that items resize as the page gets smaller, such as reducing the size of the font. Our module is responsive. But the media queries that determine when these breakpoints occur are based on the page width not the container width, so this module is actually only responsive within the context of placing it within two columns.

You can view a demo of the responsive two column carousel here (note the carousel is static for the purposes of this demo).

If we use the same module on another page, but give it a different number of columns, then the breakpoints we created before may be rendered impractical (or worse). Let's look at the same carousel module but sitting across three columns:

Because we've changed the size of the container, the breakpoints set for this search module are now sub-optimal for the configuration of columns. The things we reduced in size before now shrink too early, and we are left with a lot of extra space.

[You can view a demo of the responsive three column carousel with our original breakpoints here](http://www.andismith.com/examples/media-queries- problem/index-3-col.html).

This is not such a big problem for three columns, it's a bit small but we can usually get away with this. Let's see what happens when we reduce the number of columns our module spans.

If we change our module container to span a single column the problem is much worse. Now the module container is too small, so the media queries we provided to shrink our content are inappropriate. Our page looks a mess.

[You can view a demo of the responsive one column carousel with our original breakpoints here](http://www.andismith.com/examples/media-queries- problem/index-1-col.html).

A Solution

There's no point complaining about a problem without proposing a solution; and the solution in this case seems to be the argument for a new type of media query which can react to a container's properties rather than the page properties. In the case of our example, this would be a media query that can react based on the width of a container defined by the user rather than the whole width of the page.

In an ideal world, perhaps we'd solve this problem in CSS like this:

.container {

  @media screen and (max-width: 400px) {
    h3 {
      /* narrow styles */
    }
  }

  @media screen and (min-width: 401px) and (max-width: 800px) {
    h3 {
      /* wider styles */
    }
  }

}

But CSS doesn't support nested queries like SASS and LESS does, so perhaps a more suitable solution to the problem would be to create new media queries conditions min-width-of and max-width-of (and the equivalent height conditions) like so:

@media screen and (max-width-of(.container): 400px) {

  .container h3 {
    /* narrow styles */
  }
}

@media screen and (min-width-of(.container): 401px) and (max-width-of(.container): 800px) {

  .container h3 {
    /* wider styles */
  }

}

Now when we resize the page, our content would be able to resize when the container meets the condition, rather the page.

Conclusion

For rich content web sites, responsive web design can be a complicated procedure; and as developers push responsive in to 2013 the problem is only going to get more complicated.

Grids can help reduce complexity, but we are still reliant on measuring page properties rather than the properties of the actual container that holds our content. Here's hoping that in the future it becomes possible to create media queries based on containers so that we can allow greater flexibility on our web pages.

Appendix: Until Then

Not wanting to detract from the article above, I did want to share a solution that is possible in today's browsers, although it isn't particularly 'nice' and relies on JavaScript.

By using JavaScript to calculate and compare the container and page widths, we could apply a class to our container to determine how many columns it is currently occupying. This class would then drive the size of our content in the same way our media queries were in the above examples. Like I said, not a pretty solution - but a workaround until the bigger issue is resolved.

The more you know about the tools, the better you'll get at performing the task at hand. There are now many tools that can speed up web development - from Browser Developer Tools to build scripts like Grunt; but the most important tool of all is the tool you write your code in - your code editor. For me, that's Sublime Text 2 and there are a ton of keyboard shortcuts available to make life easier available.

So as my Christmas present to you, here are 2 cheatsheets (one for Mac, one for Windows) so you can learn and reference those shortcuts to improve yourself and your developer skills.

PC (click thumbnail to open):

MAC (click thumbnail to open):

Have a great Christmas everyone!

For those who've not come across the concept of a PechaKucha before, the idea is to present on a topic for 20 slides with 20 seconds per slide. The event I attended was slightly different with just 5 minutes to show those 20 slides (so 15 seconds a slide).

Whenever I talk to web developers I find that the canvas element still remains a mystery to most, so I wanted to do a short presentation that could introduce developers who had not used the canvas element before to the concepts and show how it's not quite as scary as it seems.

It was my first PechaKucha, and during rehearsal I learnt that the format doesn't lend itself too well to explaining how to implement lines and lines of code. I tried to balance out the slides so there wasn't too much new information on each. The aim of the talk was less about teaching developers everything about canvas and more about showing how simple it can be to create an effect.

Below is a write up of the talk, and I'm going to purposefully keep it short (hopefully a 5 minute read) to allow you time to experiment. You can view the original presentation here, the slides move on every 15 seconds and the animated demos start themselves - each demo is deliberately self contained so you can dive in to the code. Please use, abuse and learn.

The 5 Minute 3D Effect

Quick note: this is a 3D effect in 2D, not a WebGL demo. The effect we are going for is a simple space effect with particles flying out of the center of the canvas element, it looks like the following:

The Canvas element

• Allows us to place a 2D drawing canvas on our page
• Interfaced with JavaScript
• Default dimensions: 300 x 150
• Works in IE9+

<canvas id="particles">
  Stop running IE6-8 dude, it's not cool!
</canvas>

The Canvas Context

The context is like an artists toolbox. We use it to:

• Draw lines, rectangles and arcs
• Set colours and styles
• Fill shapes
• Clear the canvas
• Get/use image data

var canvas = document.getElementById('particles');
var context = canvas.getContext('2d');

Set up our Drawing Area

We will create a function called draw() that will be called for each frame of our animation. This function will need to carry out a number of tasks:

• Clear the canvas - as our canvas is a bitmap we cannot move items on it, so for each frame we have to redraw the canvas.
• Translate our canvas so our point of origin (0, 0) is the center, not the top left.
• We use save() and restore() to save/restore the state of the context (e.g. point of origin, colors). It does not save an image of the canvas.

function draw() {
  context.clearRect(0, 0, width, height);

  context.save();
  context.translate((width/2), (height/2));

  // draw particles

  context.restore();
}

Decide On a Amount of Particles

We need to decide how many particles we wish to show. Naturally in a presentation, the audience will always choose the highest number you offer (10,000) - but in real life consider number of particles vs. performance. Our particles will live in an array in JavaScript.

var AMOUNT = 10000;
var particles = [];

Create Those Particles!

Each particle is an object and for each particle we:

• Make an object with x, y, z co-ordinates
• Push it on to our particles array

function create() {
  var i = AMOUNT;
  var particle;

  while (i--) {
    particle = {
      x: 0,
      y: 0,
      z: 0
    };
    particles.push(particle);
  }
}

Generate Random Numbers

At the moment all of our particles are sitting at the same co-ordinates (the center), so we need to give them some random coordinates, which means we need a simple function to generate random numbers. This function:

• Gets the difference between max and min
• Multiplies the difference by Math.random()
• Adds min back to our value to ensure it's within our range

function randomNumber(min, max) {
    return (Math.random() * (max - min)) + min;
}

Create Random Particles!

Now we've done that, we adjust our particle creation loop for each particle to:

• Set x to a random number based on half the width (remember our origin is the center)
• Set y to a random number based on half the height
• Set z to 0 (for the moment)

particle = {
  x: randomNumber(-(width/2), (width/2)),
  y: randomNumber(-(height/2), (height/2)),
  z: 0
};

Draw Our Particles!

Now we have differing co-ordinates, we loop through our particles array and make each particle a circle using context.arc(x, y, radius, startAngle, endAngle, antiClockwise).

context.fillStyle='rgba(255,255,255,0.3)';
context.beginPath();
context.arc(particle.x, particle.y, radius, 0, Math.PI*2, true);
context.fill();

Here, we are choosing to color our particles white, during our arc and then filling it. I've added a nice semi-transparent effect to the color by specifying an alpha in our rgba color value. You can improve performance by only setting the colour once rather than for each particle.

Field of Vision

The z coordinate measures how close or far away our particle is from our view. If it gets too close, it will obscure our view so we want to simulate it going past us at some point. If it gets too far away, we are spending time rendering a particle that is practically invisible. So we use this value to tell our draw function when to draw the particle. It's up to you which value you use, ~250 seems to work well.

var FIELDOFVISION = 250;
particle = {
  x: randomNumber(-(width/2),(width/2)),
  y: randomNumber(-(height/2),(height/2)),
  z: randomNumber(-FIELDOFVISION,FIELDOFVISION)
};

Scaling Our Particles

Particles should be different sizes at different points on the z axis, so we use scale to position them and to change the radius of our circles.

scale = (FIELDOFVISION/(particle.z+FIELDOFVISION));
x = (particle.x * scale);
y = (particle.y * scale);
context.arc(x, y, scale, 0, Math.PI*2, true);

Animation

Our particles are now pretty, scaled and scattered, but still static. We use requestAnimationFrame to draw when the browser reflows, for the best performance.

Add a quick shim:

window.requestAnimationFrame ||
  (window.requestAnimationFrame = window.webkitRequestAnimationFrame ||
  window.mozRequestAnimationFrame ||
  window.oRequestAnimationFrame ||
  window.msRequestAnimationFrame ||
  function( callback ){
    window.setTimeout(callback, 1000 / 60);
  });

Then we call draw() like so:

requestAnimationFrame(draw);

Make Our Particles Move!

To make the particles move, for each frame we need to change the z co- ordinate.

SPEED = -4;

Within our draw loop:

particle.z += SPEED;

We also want to test for the field of vision and move our particles to the front or back when they are no longer in vision. This has the bonus of reducing the amount of array manipulation (we're just editing values rather than splicing and splitting arrays) improving performance.

if (particle.z < -FIELDOFVISION) {
  particle.z = FIELDOFVISION;
}

Done!

And that's it, we have particles that move! Simple, and nothing really to be scared of.

Check out my presentation for demos; a few more effects and a nice picture of a cat! Enjoy!

What we'll cover in this post:

• Photo Booth - Using canvas to take screenshots.
• Effects Studio - Using canvas to apply different effects to the webcam feed.

Now we know what we're doing and we've given them funky names, let's begin!

Extending with Canvas

If you've not come across the canvas element before, it is used to render a bitmap image to the user's screen via JavaScript. Unlike SVG, it has no DOM; and it also has no history of previous renders.

Our first step is to add a canvas element to our page.

<canvas id="photo"></canvas>

Photo Booth

To take screenshots, we will need to add a button to our page; and attach an event.

The following function creates a button programatically and attaches an event to call the function takePhoto() (which we've yet to write) when the user clicks the button.

function setupPhotoBooth() {
  var photoButton = document.createElement("button");
  photoButton.innerText = "Smile!";
  photoButton.addEventListener("click", takePhoto, true);
  document.body.appendChild(photoButton);
}

Taking our Photo

Taking the photo isn't too difficult. First, we need to set our photo canvas element to have the same width and height as our video otherwise our picture will be squished into canvas' 300 x 150 default dimensions. If you are having difficulty getting video's height and width, you may need to explicitly size the video element.

Next, we need to get the 2D context of the photo canvas. If you're unfamiliar with how canvas works, the context is like an artist - it will get and set our image data.

Finally, we call drawImage with the parameters of our video element, and the area we wish to paint in.

function takePhoto() {
  var video = document.querySelector("video");
  var photo = document.getElementById("photo");
  var context = photo.getContext("2d");

  // set our canvas to the same size as our video
  photo.width = video.width;
  photo.height = video.height;

  context.drawImage(video, 0, 0, photo.width, photo.height);
}

Running the page in a browser that supports getUserMedia, you should now be able to take a photo. Unlike me, you may want to sort out your hair before hitting the "Smile!" button.

The view on the left is our feed, the one on the right is our picture.

Saving our Image

If you would like to extend your photo booth to save the image being taken, you can add a save button to your page and hook up an event to save the photo. To trigger a download, we need to change the MIME type to image/octet-stream like below.

function savePhoto() {
  var data = photo.toDataURL("image/png");
  data = data.replace("image/png", "image/octet-stream");
  document.location.href = data;
}

This will save the image as a PNG. If you wish to save as other image formats, take a look at Jacob Siedelin's Canvas2Image library.

If you'd like to look at and play with the photo booth web cam demo, [I've uploaded a demo to Github](http://andismith.github.com/getUserMedia- examples/). Don't forget, you'll need [a browser that supports getUserMedia](http://www.andismith.com/blog/2012/06/introduction-to- getusermedia/) to use your webcam.

[You can view and fork the code on Github.](https://github.com/andismith /getUserMedia-examples)

Effects Studio

One of the first things I ever remember using on the Mac was PhotoBooth, where you can adjust your image to make a variety of different effects - such as changing the colours or saturation. Let's have some fun with our webcam feed.

We could use CSS filters to add effects to our images.. this would be a perfectly valid way of adding effects, except if we saved the image, our effect would not be applied. So let's take the more complicated route.

As we want to manipulate our live feed and we cannot change the video feed directly, the first thing we need to do is change our video feed to show in a canvas element. We've already covered how to grab a video image and draw it in the canvas, but this time we are going to need to continually refresh the canvas element to keep a live feed.

Previously in JavaScript, timed events could be achieved with setInterval or setTimeout; but more recently requestAnimationFrame has been introduced. requestAnimationFrame allows the browser to synchronise our animation with the browser paint cycle and won't run the animation while the tab is not active. Sadly, it's another case of vendor prefixing for requestAnimationFrame so we need another shim (Paul Irish goes in to more detail about this shim on his blog).

window.requestAnimationFrame ||
  (window.requestAnimationFrame =
    window.webkitRequestAnimationFrame ||
    window.mozRequestAnimationFrame ||
    window.oRequestAnimationFrame ||
    window.msRequestAnimationFrame ||
    function (callback) {
      window.setTimeout(callback, 1000 / 60);
    });

requestAnimationFrame works in the same way as setTimeout - it is only called once and we are required to call it each time we want to use it. We fallback to setTimeout for browsers that don't support it (which shouldn't be any of the browsers that support getUserMedia, but it's best to be safe.

Now, we need to add the additional canvas element to our page:

<canvas id="feed"></canvas>

We need to create a new function to stream the feed. Using the same method we used to take a photo, we draw an image to the feed context. This time round we also make the function call itself via requestAnimationFrame.

function streamFeed() {
  var context = feed.getContext("2d");
  requestAnimationFrame(streamFeed);
  context.drawImage(video, 0, 0, feed.width, feed.height);
}

The final thing to do to get our stream working is to add a call to initiate streamFeed() within our getUserMedia success function (called onSuccess in our previous post).

Although our stream will now work, we don't want both the video and canvas feed to appear at the same time, so we need to hide our video.

video.style.display = "none";

Separating the Raw Feed from Display

We've finished doing the setup work, now it's time to add some effects. To add effects, we are going to want to add another canvas element called display. Our feed will provide the image data, and our display will show the finished result. Let's add the element, hide our feed, and also give our feed and display canvas elements a width and height to avoid the default canvas dimensions when we are manipulating data.

feed.style.display = "none";
feed.width = 640;
feed.height = 480;

display.width = 640;
display.height = 480;

Effects Groundwork

We'll store our applied effects in an options array, but we need a way to allow the user to trigger our effects. The following function creates an effects button for each of our effects. The effects we are going to add are: "invert", "red", "blue" and "green".

function setupEffectsButtons() {
  var effects = ["invert", "red", "blue", "green"];
  var effectButton;

  for (var i = 0, l = effects.length; i < l; i++) {
    effectButton = document.createElement("button");
    effectButton.id = effects[i];
    effectButton.innerText = effects[i];
    effectButton.addEventListener("click", toggleEffect, true);
    document.body.appendChild(effectButton);
  }
}

These buttons trigger the toggleEffect function which adds and removes items from our options array when the user clicks the button. The actual effects will be added during our animation loop, which we will cover afterwards.

function toggleEffect(e) {
  var effect = this.id;
  if (options.indexOf(effect) > -1) {
    options.splice(options.indexOf(effect), 1);
  } else {
    options.push(effect);
  }
}

Now we have a way for the user to add and remove effects, it's time to manipulate our feed image data!

Changing the Stream Feed

We need to alter our stream feed function to include a call to the function that will add our effects (addEffects()).

First we need to draw our video to the feed canvas so we can extract the image data. Next, we call getImageData to extract the image data. This is what we will pass through to addEffects(). Finally, we will output the returned image data on to our display context.

function streamFeed() {
  var feedContext = feed.getContext("2d");
  var displayContext = display.getContext("2d");
  var imageData;

  requestAnimationFrame(streamFeed);
  feedContext.drawImage(video, 0, 0, display.width, display.height);
  imageData = feedContext.getImageData(0, 0, display.width, display.height);
  imageData = addEffects(imageData);
  displayContext.putImageData(imageData, 0, 0);
}

Adding Effects

Our addEffects() function loops through our options and applies each of them to our image data. First, let's write the skeleton.

function addEffects(imageData) {
  var data = imageData.data;
  var type = {};

  for (var i = 0; i < options.length; i++) {
    type = options[i];

    for (var j = 0; j < data.length; j += 4) {
      switch (type) {
        case "invert":
          // code to go here
          break;

        case "red":
          // code to go here
          break;

        case "blue":
          // code to go here
          break;

        case "green":
          // code to go here
          break;

        default:
          break;
      }
    }
  }
  return imageData;
}

For each option, we will need to loop through the image data. Each pixel in our image data is represented by four numeric values - the first is red (from 0 to 255), the second blue, the third green and the fourth is alpha - known as RGBA. Therefore our loop will increment by 4 each time to reach the next pixel.

After checking our page still works, it's time to add our effects. The effects for red, blue and green are created in a similar fashion. For each effect, we increase the corresponding RGB value and decrease the other colour values. Using Math.min, we can choose whether it should be twice the value from the feed data, or 255 - whichever is lower. The following code is for red. The effects for green and blue are the same formula, but on the other related values in the array:

case "red":
  data[j] = Math.min(255,data[j] * 2);
  data[j + 1] = data[j + 1] / 2;
  data[j + 2] = data[j + 2] / 2;
  break;

Finally, let's add our code for invert. Invert is a straightforward effect to create - we just invert the pixel value by subtracting the value from 255, like so:

case "invert":
  data[j] = 255 - data[j];
  data[j + 1] = 255 - data[j + 1];
  data[j + 2] = 255 - data[j + 2];
  break;

And... Done!

Now we've created our effects, we can now apply effects to our webcam feed. Multiple effects can be applied by pressing multiple buttons. If we wish to apply our effects to our photo snaps, we need to change our photo booth takePhoto() code to look at the display canvas rather than the feed canvas.

If you'd like to look at and play with the effects web cam demo, [I've uploaded a demo to Github](http://andismith.github.com/getUserMedia- examples/). Don't forget, you'll need [a browser that supports getUserMedia](http://www.andismith.com/blog/2012/06/introduction-to- getusermedia/) to use your webcam.

[You can view and fork the code on Github.](https://github.com/andismith /getUserMedia-examples)

If you create effects code for other different effects, feel free to share it below!

For a long time in the "Flash vs HTML5″ comparison arguments, one advantage Flash had was the ability to capture audio and video from the users computer. With upcoming browser releases, it is now possible to do this with JavaScript and the HTML5 video element, and its very simple to do. Unfortunately, audio doesn't work through the <audio> element at the time of writing, but video does - so let's use that!

Implementation

Firstly you'll need a browser that supports getUserMedia. Currently this list is Chrome Canary 18+ (turned on from about:flags) and Opera 12+ - although it will be [Firefox nightly](http://mozillamediagoddess.org/2012/06/25/the-first- part-of-webrtc-has-landed/) any minute now. You'll also need a machine that has a webcam and microphone, which should be any laptop nowadays.

On your HTML page, you need to include an empty <video> element. This will be used to show the feed from the video stream.

Due to the joy of vendor prefixes, we need to make sure we're referencing getUserMedia correctly. This quick shim helps us out:

navigator.getUserMedia || (navigator.getUserMedia = navigator.mozGetUserMedia || navigator.webkitGetUserMedia || navigator.msGetUserMedia);

Note, I haven't left out the Opera prefix because I hate Opera (I don't) - but instead because Opera have implemented getUserMedia unprefixed.

Checking for Browser Support

The next step is to check the browser we're using has an implementation of getUserMedia and if it does, request a video and audio stream.

if (navigator.getUserMedia) {
  navigator.getUserMedia({video: true, audio: true, toString : function() {
      return "video,audio";
    }
  }, onSuccess, onError);
} else {
    // getUserMedia is not supported in this browser.
}

We pass an the object with video and audio set to true ({ video: true, audio: true }) to tell the browser we wish to capture both video and audio, but we could set either of these to false to only capture one (when audio works, that is). Unfortunately before Chrome Canary 20, Chrome required a string for this parameter so the included toString function hack is actually a way around this (credit to @agektmr).

The next two parameters are the function to call when getUserMedia is successful, and what to call when there is an error (such as the user declines the invitation to capture video and audio). So, our next step is to write these functions!

Handling Success

function onSuccess(stream) {

  var source;

  if (window.webkitURL) {
    source = window.webkitURL.createObjectURL(stream);
  } else {
    source = stream; // Opera and Firefox
  }

  var video = document.querySelector('video');
  video.autoplay = true;
  video.src = source;

}

A successful connection provides us with a stream object. Different browsers have different implementations of this - Opera and Firefox set this directly to the stream object, while WebKit provides a Blob URL.

We then need to tell our <video> element to autoplay; set the source and we have written our success function.

Handling Failure

An error may occur in our request such as if the user denies us permission to capture their video, so we need to create an error function that alerts the user to this (you could print something out to the screen, or use an alert). Once that's done, we're good to go!

See Yourself!

Load your page in your favourite browser - you'll need to set it up to run on a HTTP server as permissions won't be requested from the file protocol - and your page should ask for you to share your webcam and microphone. Hit accept, and you should hopefully see a face prettier than mine.

I've created a [really simple demo](http://www.andismith.com/examples/blog /getusermedia-simple/) if you'd like to play and poke around with the code.

Recently I've been using the nth-child CSS pseudo selector when building CSS3 demos for my "Introduction to CSS3″ series on The Daily Egg; to the point where nth-child became a bit of a habit. For those of you who have not come across nth-child, it allows you to target a particular child element by number or a simple formula.

So I was building a carousel the other week and I used nth-child to create my dummy carousel items. Each item had a different background color.

It was all working splendidly until I needed to make the carousel loop. Then as it looped, my nth-child changed. As you are probably aware, the problem with looping carousels is that you have to repeat your items so something can animate in from the left or right.

Repeating items in a carousel has always bothered me. It feels like a messysolution, but it gives the right visual appearance and works cross browser.

Then I began thinking about a presentation I gave recently on "Layouts of the Future", in which I spoke about current hacks we have to make to create CSS layouts and how help is round the corner with the likes of columns; CSS Regions and… flexbox.

Flexbox allows us to build layouts horizontal or vertical layouts with relative ease and flexes the contained boxes to fill the area available. But, one of the other cool things about flexbox is that you can rearrange your layout by using the box-ordinal-group property.

For example, here are three boxes, layed out with Flexbox:

To change the order of these boxes, we simply change the box-ordinal-group property on each item. For item 2, I've set the box-ordinal-group property to 1 so that it is first; item 1 is now set to 2, and the third item remains 3.

#item2 {
  -moz-box-ordinal-group: 1;
  -ms-box-ordinal-group: 1;
  -webkit-box-ordinal-group: 1;
  -o-box-ordinal-group: 1;
  box-ordinal-group: 1;
}

This is pretty cool as we no longer have to worry about markup order or floats. And thus my trail of thought moved on to flexbox for carousels.

If you don't wish to read more about how the carousel was made, you can play with it here.

Implementation

With a carousel, you probably wouldn't want to flex your items to fill the space (which is ok, as flexing has to be turned on) but we are concerned with the order of the items.

Building a carousel with flexbox is relatively straightforward once you get past the vendor prefixes:

#carousel {
  overflow: hidden;
  position: relative;
  width: auto;
}

#carousel ul {
  -moz-box-orient: horizontal;
  -ms-box-orient: horizontal;
  -webkit-box-orient: horizontal;
  -o-box-orient: horizontal;
  box-orient: horizontal;

  display: -moz-box;
  display: -ms-box;
  display: -webkit-box;
  display: -o-box;
  display: box;

  list-style-type: none;
  margin: 0;
  padding: 0;
}

#carousel li {
  height: 200px;
  margin-right: 10px;
  width: 200px;
}

Here, we are telling our un-ordered list that we wish to display as a flexbox layout on a horizontal plane. (As an aside, I've started placing Opera's vendor prefixes below Webkit's so that if Opera supports the Webkit property, it cascades to receive the O version. Not that Opera supports flexbox at the moment.)

If we maintain an active counter on our carousel, we can change the box-ordinal-group whenever the user clicks next or previous and never have to worry about repeating items again.

The functionality in our JavaScript for changing the ordinal is relatively straightforward, but to ensure we have an element on the left to animate to we need to start our ordinal at the active value-1, and then add a left margin to our carousel that is one item wide.

function changeOrdinal() {
  var length = items.children.length,
    ordinal = 0;

  // start at the item BEFORE the active one.
  var index = active - 1;

  /* if the active item was 0, we're now at -1 so
      set to the last item */
  if (index < 0) {
    index = length - 1;
  }

  // now run through adding the ordinals
  while (ordinal < length) {
    // add 1 to the ordinal - ordinal cannot be 0.
    ordinal++;

    // check the item definitely exists :)
    var item = items.children[index];
    if (item && item.style) {
      // new ordinal value
      item.style[boxOrdinalGroup] = ordinal;
    }

    /* as we are working from active we need to go back to
         the start if we reach the end of the item list */
    if (index < length - 1) {
      index++;
    } else {
      index = 0;
    }
  }
}

I've commented the [code on Github](http://andismith.github.com/flexbox- carousel/) if you wish to dive deeper in to how it works.

Summary

The final flexbox carousel is available to play with on Github.

Using flexbox comes at a browser support cost, however. The specification was recently changed, which means most browsers only partially support parts of Flexbox - but the parts used in this demo work in Chrome, Firefox and Safari. Flexbox also doesn't work in Opera, or IE9 or below. But perhaps this is a solution we can use in the future once everything has settled down?

The code is available on Github. Enjoy!

Disclaimer: I am not a lawyer, not am I a representative from any authority on cookies. These are my interpretations of the cookie law and (like all my blog articles) these views do not represent the views of my employer or associates. If this subject matter is of interest to you, it is important that you do your own research on the cookie law to ensure your website is complying with the law.

What is the Cookie Law?

The cookie law is a new EU privacy legislation that requires websites to provide clear and comprehensive information about the cookies being stored; and obtain consent from visitors in order to store or retrieve any information about the user.

In the UK, this becomes law on 26th May 2012 and sites that do not comply could be fined up to £500,000.

Types of Cookie

Before we talk about what cookies are good or bad, let's quickly recap on the different types of cookies. Cookies can either be permanent or session based; and they can either be first party or third party.

• Permanent Cookies are cookies which outlast the user's session. So if a user closes their browser or turns off their computer, they will still be remembered when they return to the site.
• Session Based Cookies only last until the user closes the browser window.
• First Party Cookies are cookies which are hosted on the same domain as the website the user is visiting.
• Third Party Cookies are not hosted on the domain the user is currently visiting, but are actually hosted on another domain.

Although it is dependent on the functionality the cookie is providing, as a general rule permanent third party cookies are the most intrusive types of cookie, whilst session based first party cookies are considered the least intrusive.


In the browser, there is currently no way to filter out a type of cookie - you can only block all cookies from a particular site.

If you are unsure what types of cookies are present on your website, sites such as CookieCert can help with this process and quickly give you an understanding of the problem. CookieCert analyses your site to evaluate how many first party, third party, permanent and session based cookies are being used. It also provides a tally on HTML5 and Flash 'cookies' (such as local storage) which could also be considered harmful to users' privacy. Please be aware that CookieCert may not be able capture cookies at all stages of the users journey (such as when the user is logged in).


Browser Developer Tools can also help with a cookie audit. In Chrome and Safari, click the "Resources" tab to see a list of cookies used on the current site organised by domain. In "Opera", the storage tab provides this information.

What Types of Cookies Are Effected?

So how do you comply with the cookie law in the UK?

ICO Guidelines

[The ICO (Information Commissioner's Office) say](http://www.ico.gov.uk/for_or ganisations/privacy_and_electronic_communications/the_guide/cookies.aspx) that all cookies that do not facilitate the transmission of communication, or are not strictly necessary for a service requested by a user need to be consented to or removed.

Strictly Necessary Cookies

Strictly necessary means that storage of or access to information should be essential to the user journey. The ICO would class the following types of content as "strictly necessary":

• Transaction specific (such as shopping baskets)
• Security (such as online banking)

Transmission of Communication Cookies

Cookies for the transmission of communication would include:

• Stop multiple form submissions
• Load balancing

Other Cookies

All other cookies would require consent from the user. These cookies would include:

• Embedded third-party content and social media-plugins
• Advertising campaign optimisation
• Web analytics / metrics
• Personalised content / interface (such as remember me)

GDS Guidelines

In a strange twist, [the GDS (Government Digital Service) have recently posted a document](http://alphagov.files.wordpress.com/2012/03/gds-cookies- implementer-guide.pdf) which slightly differs in opinion from the ICO's own guidelines. They believe the new law is not specifically about cookies, but about privacy; and that website owners should focus their efforts on the most intrusive types of cookies.

Moderately Intrusive Cookies

The GDS class the following types of content as moderately intrusive (and therefore requiring attention):

• Embedded third-party content and social media-plugins
• Advertising campaign optimisation

Minimally Intrusive Cookies

The following would be minimally intrusive:

• Web analytics / metrics
• Personalised content / interface (such as remember me)

Exempt Cookies

The following would be exempt from changes to privacy regulations:

• Stop multiple form submissions
• Load balancing
• Transaction specific (such as shopping baskets)
• Security (such as online banking)

How Does This Affect Analytics?

The [ICO guidelines document (PDF)](http://www.ico.gov.uk/news/latest_news/201 1/~/media/documents/library/Privacy_and_electronic/Practical_application/guidance_on_the_new_cookies_regulations.ashx) states on page 25 that:

Although the Information Commissioner cannot completely exclude the possibility of formal action in any area, it is highly unlikely that priority for any formal action would be given to focusing on uses of cookies where there is a low level of intrusiveness and risk of harm to individuals, if an organisation can demonstrate they have done everything they can clearly to inform users about the cookies in question and to provide them clear details of how to make choices. Whilst he does not consider they are exempt from the rules the Commissioner is therefore unlikely to prioritise, for example, first party cookies used for analytical purposes and cookies that support the accessibility of sites and services, in any consideration of regulatory action.

So assuming your analytics are first party (that is, they set a cookie on your domain and not a different domain), this should apply.

So, What is Affected?

Based on this information, it is reasonable to assume that sites with embedded third-party content and social media-plugins and/or advertising campaign optimisation are going to be the most affected by this law. However, even the least intrusive types of cookies require some effort to achieve compliance.

7 Steps To Comply

There are a large number of points that need to be considered with the new law and each website needs to be considered on a case by case basis.

The below steps are numbered in order of implementation difficulty and impact but are by no means a comprehensive guide on how to comply.

Step 1. Carry out a Cookie Audit

The first, and easiest step, is to carry out an audit of your website. That is, create a document listing each cookie used on your website together with the following information about it. Your audit could include the following fields:

• Cookie Name - The name used in implementation (e.g. UID)
• Cookie Friendly Name (e.g. Username)
• Description - The description should provide as much detail about the purpose of the cookie as possible.
• Potential Intrusiveness to User - Using a guide such as the one provided by the GDS (shown above), each cookie should be rated for its intrusiveness.
• Expiry - The number of days it takes for the cookie to expire.

Step 2. Updated Your Privacy Policy

Make sure that your privacy policy has a clear section on cookies and how your site uses them. If you want to be 100% transparent, you could include the findings of your cookie audit on these pages, as Dominos and the UK Government do.


Step 3. Include Clear Links to Cookie Information

Ensure that you have included a clear link to cookie information on every page. For example, if you currently have a link to "privacy policy" and "terms and conditions" in your footer, you could add a third link directing users to "cookie information". If information about cookies exists on the same page as your privacy policy, use a hash tag to jump the user to this information. Amazon UK and Gov UK have a good example of this.

Step 4. Remove Unnecessary Cookies

Now you've completed your cookie audit, if there are any unnecessary cookies remove them. Try to keep your cookie list to as few as possible.

Step 5. Examine Expiry Dates

For each cookie in your cookie audit, examine the cookie expiry dates and check that they are reasonable. For example, a cookie which remembers a user for two weeks would be considered reasonable, whilst a cookie that remembers the user for 20 years would not. There should be no reason to have a cookie that lives that long, so shorten its lifespan.

Step 6. Ask For Consent At User Interaction Points

There are points in the user journey where it is possible to ask for consent to use cookies. For example, when a user logs in and ticks the "remember me" checkbox - including an additional line of text to inform the user checking this box will also mean they agree to being remembered won't affect your user journey but will bring additional compliance.

Step 7. Alert the User About Cookies

If you do still require use of the most intrusive types of cookies, then your best bet is to provide an alert to the user about cookies. The ICO use one of these on their own site but it is visually displeasing.

Reading further in to cookie law, [page 16 of the ICO guidelines (PDF)](http:/ /www.ico.gov.uk/news/latest_news/2011/~/media/documents/library/Privacy_and_el ectronic/Practical_application/guidance_on_the_new_cookies_regulations.ashx) states that:

Many websites routinely and regularly use pop ups or ‘splash pages’ to make users aware of changes to the site or to ask for user feedback. Similar techniques could, if designed well enough, be a useful way of highlighting the use of cookies and obtaining consent. Using this technique you could ensure you are compliant by not switching on any cookies unless the person clicks I agree. Some users might not click on either of the options available and go straight through to another part of the site. If they do, you might decide that you could set a cookie and infer consent from the fact that the user has seen a clear notice and actively indicated that they are comfortable with cookies by clicking through and using the site.

In other words, as long as you provide a clear message to the user about cookies and give them a chance to decline, by using your site you can infer consent. This is the approach Qubit have taken.


But by far the best implementation I've seen of a cookie prompt is BT.com who prompt the user with a pop-up in the bottom right hand corner. Pressing the "Settings" button then allows the user to configure what cookies will be used.

Conclusion

As I stated at the beginning of the article, if you need to know more about cookies and the law then it really is best to do individual research and involve your companies legal team.

The most important point to take from this article is that it is vital that you take action on your corporate sites to avoid being penalised, and I hope the information listed above can help guide you with that.

The two documents I have referred to in this article are available at:

• Link to the ICO document (PDF).
• Link to the GDS document (PDF).

Additional resources include:

• The Cookie Collective
• SilkTide

The idea behind JS1k is to produce a cool JavaScript application in under 1k (1024bytes) of code. I had not done any JavaScript golfing before, so I thought it would be a nice little challenge for myself. I didn't realise at the time quite how addictive or time-consuming JavaScript golfing was going to be!

My Entry

My entry in to the competition is a jetpack style game. As the theme of this years js1k competition was 'love', the game is called "Cupid's Heart Collection" and revolves around the user playing as Cupid who has to fly through his love cavern collecting hearts and avoiding spikes. As you venture further in to the cave, things speed up. Your final score is based on Distance * Number of Hearts collected.

You can play it here!

I had originally intended to create a Canabalt style game for my entry. For completely illogical reasons I started with the parallax background - two arrays containing random numbers to determine the height of the blocks before I eventually joined them together to save space.

By the time I had created the parallax background I found myself with under half my space left, so my entry became a jet pack game. I wanted to make sure there was more than just avoidables, and hearts seemed like a perfect fit based on the competitions theme. I used character for both the heart and spike.

I also wanted my character to be more than a square - Cupid seemed to fit perfectly for the theme, and using the letters C, U, P, I, D actually gave me the basis for a character design. C for the head, U for the body, P and I for the legs and D for the wings.

Once I had finished, I found myself at around 1800 bytes. I managed to reduce the amount to around 1400 bytes before I introduced gradients. Gradients in canvas take up a lot of bytes thanks to names like 'createLinearGradient' and 'addColorStop'. But I was determined to make them fit. I was also determined I wasn't going to cut anything. Some of the techniques used are listed below.

And so began a process of working hard to reduce the number of bytes to 1,024. It was addictive, too addictive. I found myself writing code until the early hours of the morning on several occasions. And every time I figured out a way of reducing the bytes to slightly below 1,024, I decided to add a new feature. Which meant further reduction. Simple things like giving a final score, turning Cupid red and even restarting the game without a page refresh were added very late in the process.

1k doesn't look like much code, but it certainly took a long time to create. Every time a byte was saved it became more difficult to remove another. Golfing continued right up until submission with the 20 character limit on submission names meaning I had to use the heart symbol for the title.

Techniques I Used

There are so many useful resources available for JavaScript golfing now. It's just a case of figuring out when to apply them. I learnt so much doing this exercise, most of it couldn't be used in production code - but I feel closer to JavaScript than I ever have before.

Resources:

• 140 bytes Byte Saving Techniques
• Stack Exchange Tips for Golfing
• Ben Alman's blog
• Marijn Haverbeke's blog

Techniques:

• Renaming methods within the canvas context to 2 letters. I played around with a few different letter combos, but the best was using the first and sixth letter (which Marijn had also found) - I had to take a hit on .rotate because of this, but other options yielded worse results. I didn't worry about the 7th letter being undefined as I didn't need any of those methods.
• Reducing the number of times I called function - I originally had around 6 functions, but most of these became 1 loop in the end. Using variables meant I could call pieces of code within the loop at different times.
• Declaring variables by including them in the function arguments - this helped me a lot
• Changing values to the same as other variables to reduce declaration size.

If I had more bytes..

I really wanted to include a particle engine in the game, where the hearts would explode on collection and lava would jump out of the floor - but I just didn't have enough space. In reality, the game sometimes feels like it jerks a bit at the higher speeds so the biggest consideration with more bytes would have to be performance; and adding a pause so the game doesn't instantly restart if the player holds down a key for too long.

Play "Cupid's Heart Collection" here!

• background-size
• background-clip
• and background-origin

These features have been hiding behind their more popular gradient background color cousins; but are worth making a note of, especially if you're creating sites for mobile phones and recent browsers; and the best news is that they are completely prefix-free!

Let's take a look at what these properties are, what they do and afterwards we'll have some fun with animating backgrounds. Yay!

To demonstrate how these features work, I've put together some demos. For each demo, unless otherwise stated the following CSS background properties are set:

• background-image: red url(img/ice.jpg)
• background-position: top left (default)
• background-repeat: no-repeat

Please note, as these are live demos, you will need Firefox 4+, Internet Explorer 9+, Opera 10.5+, Safari 3+ or any Chrome to view them.

background-size

If you've been developing for mobile phones with high density pixels, you may have already come across background-size. For a long time on the web we were unable to resize images when they were used as a background but with CSS3 property background-size, not only are we able to specify the size of a background we are able to make it relative to the containing element.

Here's the syntax and the possible options:

background-size: auto | cover | contain | value [value];

To show how each option works, let's use some examples:

auto, contain and cover

• background-size:auto;

• background-size:contain;

• background-size:cover;

You'll already be familiar with background-size: auto (the example on the left). This is the default setting for background-size and what almost every background on the web so far uses. This setting doesn't resize your image at all - if it's too big it'll cut off a chunk of the image. If it's too small it'll either leave a gap or repeat, depending on the value of your background-repeat.

With background-size:contain (middle), the background image will be resized so that the entire image fits in the space whilst keeping its original proportions. This will mean that unless your container is to the same proportion as your background image there will be a gap. In our case it's at the bottom and in red as the background-color has filled in the gap for us.

If you can't guarantee the size of the background and you don't want a gap, background-size:cover may be exactly what your looking for (on the right). This option will resize the image so that the shortest dimension (width or height) exactly fits the space whilst keeping the images original proportion. What this means is part of your image will be cut off. Depending on the proportions of the image will depend on how much.

So to recap:

• Use contain and your background image height and width will be <= to the container.
• Use cover and your background image height and width will be >= to the container.

Percentages

• background-size:100%;

• background-size:50%;

• background-size:100% 100%;

Now we've covered the three keywords, it's time to take a look at the other values that can be placed in to background-size. All values can either be specified as a single value or two separate values - one for the width and one for the height.

In the case where only one percentage value is specified, background-size will use the value specified to resize the width regardless of whether the width or height is the bigger dimension, which is why in our first example (above left) there is a small gap at the bottom of the container.

Using percentage values allow us to specify what the percentage of the containing element the image appears in - NOT what percentage of the overall image dimensions we wish to show. In our middle example above the image is 50% of the total container. Again, the 50% is taken from the width value.

Even though the images are appearing at a smaller size, the image is still loaded from the server at its full size - resizing is occuring client-side, so the browser will still have to download the full size image.

We can use multiple values to specify different dimensions for the width and height. In the case of our example above on the right, we have specified a width of 100% and a height of 100%. This is not the same as cover mode - as we are specifying both dimensions the image will be resized disproportionally, which depending on the image and the values used may or may not be noticeable.

• background-size: 50% 100%;

• background-size: 150%;

• background-size: 150%;

background-position:center

As you can see in our first example here the image has been disproportionally stretched when I've specified one dimension as half of the other. Much more noticeable!

In our second two examples, a percentage value larger than 100% is used. In these examples, the image is shown as 150% bigger than the containing element (again, not 150% of the image). The third example here also centers the image, as it's entirely possible to use all the other background css properties whilst using background-size.

• background-size:50%; background-position:right bottom;

• background-size:50%; background-position:center;

• background-size:50%; background-repeat:repeat;

The first two examples here use background-position to change the positioning of the background image. Don't forget you can use percentages and other values for positioning images if you wish.

In our third example, we are repeating the image, which creates a tile effect even though it has been resized to 50% of the size of the original image.

Percentages are very useful, but sometimes you want to be explicit with the size of your background image. Let's continue.

Length values

• background-size:80px auto;

• background-size:auto 200px;

• background-size:80px 200px;

The most common length values are pixels (px), but you could use other valid length measurements if you wish. In the first example (left), background-size is set to 80px auto; which means that the width will be set to exactly 80px and the height will be proportionate to that value. In this example, the auto value is actually superfluous - the default is already auto so it is not required. In our second example (middle), we have set the width to auto and the height to 200px which means the width will be set in proportion to the height. In our final background-size example, we've stretched the image by specifying a width and height that isn't suited for the image.

Multiple backgrounds

If you're using multiple backgrounds, you can have multiple background sizes by separating the values with a comma.

• background-image:url(img/bg-grid.gif),url(img/ice.jpg);
  background-size:auto, 50%;

• background-image:url(img/bg-grid.gif),url(img/ice.jpg);
  background-size:60%, 100%;

• background-image:url(img/bg-grid.gif),url(img/ice.jpg);
  background-size:32px 100%, 90% 150px;

These examples have different background sizes for each image - simply list the background sizes in the same order as your images. Remember that multiple images are stacked with the first listed image at the top and the last listed image at the bottom (top to bottom).

The third example (right) mixes percentages and lengths to create a cocktail of background-size goodness.

Let's move on to background-clip, but if you're interested you can [read more about background size on MDN](https://developer.mozilla.org/en/CSS /background-size).

background-clip

background-clip allows us to specify what area of the container we wish to clip our backgrounds to. There are three options available: border-box, padding-box and content-box.

background-clip: border-box | padding-box | content-box

• background-clip:border-box;
  (this is the default, you don't need to specify it!)

• background-clip:padding-box;

• background-clip:content-box;

border-box (left) is the default option, and this means the background will sit under the border. This isn't noticeable unless you have a transparent, semi transparent or semi solid border (as we have here). As you can see in our example on the left, the background sits under the border. If you're wondering why the background sits under the border on the bottom right, but not the top left; it's due to the background-origin, which I'll explain shortly.

padding-box (middle) clips the image so it no longer appears under the border. The background image will start at the top left of the inside of the containing element and finish at the bottom right of the containing element.

content-box (right) clips the image to the area where the content can sit. That is - the background begins where the padding finishes. In the case of our example, the padding is 5px wide all the way round so this creates a 5px clipping border.

More information on background-clip is available on MDN.

background-origin

The final CSS3 background property I wanted to cover was background-origin. As you would have noticed from our example above, the background for the border-box didn't sit under the left and top borders. The reason for this is because of the background-origin which determines where the background should start - and it's default value is padding-box.

background-origin: padding-box | border-box | content-box;

• background-origin:padding-box;

• background-origin:border-box;

• background-origin:content-box;

As before, padding-box starts our background at the point where padding begins.

border-box allows us to start our background where the border starts - at the top left of the container element.

content-box starts our background where our content begins (after the padding). If you look back to our example of background-clip:content-box you may notice that the image in our container starts 5px after it does in this example. This is because background-origin determines where an image starts, not background-clip.

There's more information on background-origin at MDN!

Animations

Now we're done with learning the properties, let's have some fun with background animations using CSS3 transitions and animations! There's nothing really to learn in this section, I was just playing around. If you want to know more about CSS3 transitions and animations there are lots of useful resources already out there - Google is your friend!

Of the three CSS3 properties we've covered today, only background-size can be animated. However, background-color and background-position can also be animated, as you'll see below (providing your browser supports animation - sorry Opera/IE9 users).

• Hover to zoom!

• Hover to move background!

• Hover to move background!

The first example uses background-size to increase the size of the image on hover. The second (middle) example actually uses background-repeat and background-position to create a film reel effect. The third example uses background-size again to zoom in from a small image.

• Hover to change color!

• Hover to change size!

• Hover to Mother Effing Rainbow!

In these examples, the first example (left) changes the background color from red to blue on hover; the second example uses both width and height background sizes to go from a lamppost to a letterbox effect; and the third example is a Mother Effing Rainbow effect in tribute to mothereffingtextshadow.com.

Enjoy the animations, and I hope this has been useful to you! Thanks for reading!

Yesterday I travelled to Oxford to attend the jQuery UK conference, which the team at White October carefully crafted together. The snow threatened to stop me, but thankfully calmed down by the morning. So a quick hop, skip and jump on to a train and coach; and I found myself in Oxford at the Saïd Business School.

After discovering I was pretty much the only person who hadn't won a Blackberry Playbook, the White October team kicked off the conference by introducing themselves and their keynote speaker Ralph Whitbeck.

Ralph Whitbeck

After promising the UK edition of the jQuery conference would become a yearly experience, Ralph (aka @RedWolves) spoke about how jQuery's popularity had increased and who the current team are before explaining what changes had happened to jQuery in the past year. He went through the changes in version 1.5; 1.6 and 1.7 - most of which sounded familiar, but some of which had passed me by.

When and Then

Version 1.5 introduced $.when and $.then which I haven't really looked into before, but the basic syntax is:

$.when(deferreds).then(successFunction, failFunction);

So, for example, if you loading a page or data through AJAX you could do:

$.when($.ajax("myUrl.json")).then(doSomething, handleError);

Relative CSS

In Version 1.6, I was unaware that it was now possible to use jQuery's .css() function to change values relatively. For example:

$("#myElement").css("width", "+=100px");

On and Off, and AMD

In Version 1.7, jQuery .on() and .off() was introduced, which I've written about before; and jQuery introduced AMD support which you can read more about on the amd-js api Github page.

Ralph also spoke about the internal workings of jQuery and how we could be more involved with. jQuery has a status updates page which is updated by each sub-team of jQuery every Friday and a jQuery meetings page where you can find out what meetings are forthcoming.

There was also talk of 1.8 and beyond. The main focus at the moment is to cut down the size of the library and clean up the codebase. jQuery 1.8′s focus is this, and is unlikely to contain any new APIs. It's possible that jQuery may drop IE6/7 support in to a plugin in the future. At the moment, this is just being discussed and is not official - just an idea. As Christian Heilmann pointed out on Twitter, jQuery's main purpose is to support cross-browser functionality and without IE6/7 it starts to reduce the need for using jQuery at all.

Going forwards, jQuery's site is going to see an infrastructure overhaul and site refresh. There will be a new plugin site, this time with backups - and a new learn site, which sounds like something I'd like to get involved with.

[Ralph's slides are available online](http://speakerdeck.com/u/rwhitbeck/p /state-of-jquery-jquery-conference-2012-uk).

Todd Parker

Next up was Todd Parker (@toddmparker) to talk about jQuery Mobile. As someone who has spent the last 1 and a half months working with jQuery Mobile and PhoneGap trying to get an animation heavy Android application up and running; it was refreshing to hear that everything we had encountered was being spoken about. At the start of the presentation, Todd asked everyone what phone they used as their primary device. Over 60% of the room had Android devices; most others had iOS; with a few having BlackBerries, Windows Phones .etc. Interestingly, there only seemed to be 1 person using a Nokia, but I'm sure I saw at least 3 people from Nokia at the conference.

jQuery Mobile is awesome - a great tool for mobile development. When I first used jQuery Mobile I wasn't sure. I was never a fan of jQuery UI - it always felt like too much bloat, unless you were using the majority of its features. jQuery Mobile felt the same the first time I used it. It changes your DOM - which really made me unhappy; but after playing around with it for a while you begin to understand why, and see how much help it is giving you by making things work on multiple devices; so then you start to play jQuery Mobile to its powers.

But for anyone considering building an Android application which uses the default browser (like PhoneGap is forced to do), the browser sucks. It doesn't do what you need. It actually turned out we'd managed to force Android to do more effects than was claimed on the presentation (thanks to sheer determination to find a workable solution), but generally throughout the conference it was advised not to develop Android web apps to package natively.

The future of jQuery Mobile

Todd revealed some awesome changes coming to jQuery Mobile. Version 1.1, which is due at the end of February should feature a better loader; new transitions (and a default of fade for Android because it sucks at everything else); fixed toolbars; data-mini - which allows smaller buttons and text (which can be placed in headers for example); a fix to the iOS orientation bug where content is cut off when changing device orientation; and most importantly (for me), data-enhance="false" which will tell jQuery mobile to stop screwing with your DOM for all child elements. They will be left alone. jQuery Mobile v1.1 is available online for testing already.

Version 1.2 also promises some interesting features such as Fetchlinks which allow you to specify a data-target for a link - and jQuery Mobile will load content in to this container.

[Todd's slides are available online](http://speakerdeck.com/u/toddparker/p /jquery-mobile-keynote-uk-conference).

Dion Almaer and Ben Galbraith

After a quick break, Dion Almaer (@dalmaer) and Ben Galbraith (@bgalbs) were up on stage and talking about Native vs Web applications. It's clear from their presentation that Dion and Ben know each other well and work together just by how they could easily alternate speaking roles - I've done that before and it's a tricky thing to get right, but they nailed it.

They had several learnings in this area, first talking about native vs web applications and their advantages and disadvantages and how the Android browser meant that it wasn't really ready for animation rich web based applications yet - which is interesting as my recent work found that although it is an absolute pain in the ass, if you spend enough time tinkering it is possible to get something relatively nice animating on Android.

Dion and Ben have released a couple of tools to help with their development. Thorax is an opinionated application framework built upon Backbone.js; whilst Lumbar is a build tool that generates modular platform specific applications.

Jorn Zeafferer

You may not have heard of Jorn (@bassistance) before, but you have probably used his products - Jorn has created a bunch of jQuery plugins, including the [awesome jQuery Validate plugin](http://bassistance.de/jquery- plugins/jquery-plugin-validation/). Today Jorn spoke about the pitfalls and opportunities of single page web applications.

After going through some advantages and disadvantages, Jorn talked about the JavaScript History API, showing us the second biggest shocker of the day* - the History API browser support matrix, and more specifically how Android used to support it, but now doesn't! (See Can I Use? for more info).

Like all good web features, there are polyfills available - html5please.us is a great resource for finding out whether you should use what you want to use and whether you need to use any polyfills.

• The biggest shocker of the day was that around half the attendees hadn't read JavaScript: The Good Parts. If you are one of those people who hasn't, it's really worth reading.

Lunch

Next up was lunch, and two lunch time talks. I missed Wes Nolte's (@wesnolte) 10 jQuery tips talk as I was eating lunch (sorry Wes). The QUnit talk by Laurent Delcambre (@tquila_laurent) seemed like a good introduction to using QUnit. Laurent explained that using 'same' is preferable to using 'equals' for the same reason using === is preferable to using == (you are checking for same type as well as value so don't get truthy/falsey results). Also, 'same' checks the contents of your object.

At this point I won a book on JavaScript, which at 1080 pages is going to take some time to read; but was awesome.

Christian Heilmann

To be honest, Christian Heilmann's (@codepo8) talk was so captivating I didn't write any notes. Chris is an excellent speaker, and his talk was perfectly pitched to the audience he was speaking to - some JavaScript developers, some people that use jQuery (yes, they are different). Interestingly for a jQuery Conference, Chris' talk was about how we should stop relying so much on jQuery, especially on mobile devices.

On mobile phones, we do not need to worry about old versions of Internet Explorer; and including the jQuery library adds a chunk of extra downloading over 3G.

Chris spoke about two things that stuck firmly in my mind - one I was aware of, the other I was not.

Selecting elements with JavaScript (the simple way)

document.querySelector( selector ) allows us to grab the first element on the page that matches our CSS selector (read more on MDN).
Use document.querySelectorAll( selector ) to return all matching elements (read more on MDN).

This functionality is supported in all browsers except IE6 and IE7, so if you do not need to support these browsers (e.g. on mobile) you can use this functionality.

Using classList

element.classList was new to me. classList basically replaces the need for jQuery's addClass, removeClass and hasClass by providing this functionality natively.

To add a class from an element you use:

element.classList.add("my-class");

To remove a class from an element you use:

element.classList.remove("my-class");

To check whether an element has a particular style you can use:

element.classList.contains("my-class");

There is also functionality to toggle a class, so you do not need to check whether it exists before adding or removing it (very handy):

element.classList.toggle("my-class");

classList has less browser support than querySelector but looks as though it could be incredibly handy in the future. (read more on MDN)

Chris' big plea to his audience was to not just answer everything with "we'll use jQuery" - which was very fitting for the audience (considering half of them hadn't read The Good Parts). Keep animations in CSS where possible, keep logic in JavaScript - jQuery shouldn't be the solution to everything. It's very true, and a very big problem I find when interviewing developers.

Chris' slides are available online. Chris also had the honour of being the first speaker to use a 'to-do' list example.

Haymo Meran

Talking after Chris was always going to be a challenge, and to be honest Haymo's (@draftkraft) talk seemed more like a sales pitch than anything. I generally dislike WYSIWYG editors but the Aloha Editor looks very cool. It uses 'contenteditable' (which can be a absolute pain to work with thanks to different browser interpretations). The Aloha collaborative wiki seemed like a well thought out idea. Next time I'm looking for a WYSIWYG editor, I'll definitely consider it.

Paul Irish

Paul Irish's (@paul_irish) talk was also awesome, and I again took very few notes as I was busy being attentive; but Paul was explaining to the audience the web development stack and how it could help your development. Again, this was an excellent talk for the audience as half the audience didn't seem to be aware of most of these front end tools.

There were too many tools for me to list here (and if you keep up with the web, you've probably heard of or used most of them) - but they are all listed on [Paul's slides](http://dl.dropbox.com/u/39519/talks/jquk- tooling%2Bappstack/index.html). Paul's slides were using CSS3 transitions and animations to create 3D carousels, it was all very impressive and a quick check of the code shows it was using Reveal.js. (thanks @Autarc)

One tool I wasn't aware of was the HTML Email Boilerplate. I don't have to build HTML emails anymore (thankfully), but it's something I want to look in to as it could be useful at work.

Paul wrapped up his talk with some demonstrations of upcoming Chrome Developer Tools functionality. As he was running short on time, he went quite quickly and I got the feeling there were some participants that weren't aware you could do most of the older functionality that he was whizzing through to get to the new stuff.

First up was the ability to search all JavaScript files to find a particular piece of code with the search returning a list of all the results. Next (using a webcam so we could see the phone), he showed how he was connecting to Chrome on his Android and selecting elements on the phone through the Chrome Developer tools. It was very impressive to show how it was working, and he finished it with a cheeky wink.

[Paul's slides are available online](http://dl.dropbox.com/u/39519/talks/jquk- tooling%2Bappstack/index.html).

Addy Osmani

Addy's (@addyosmani) talk was quite technical, probably a bit too technical for the some of the attendees who came from a design based background. But for the techies, it was very informative.

Addy spoke about how developers should break down large chunks of code in to smaller, reusable pieces. By separating units of code so that they do not relyvon one another (decoupling) you reduce the risk of parts of your code failingvand causing catastrophic errors.

Publish and Subscribe

By using publish and subscribe, you can allow modules of code to listen for events and react to them accordingly (known as "Event Driven"). In jQuery, this can already be done with .trigger() and .on().

To listen for a custom event, you would use:

$(element).on("customEvent", myFunction);

To trigger that custom event, you would use:

$(element).trigger("customEvent");

There are a few alternatives to using these jQuery methods which are detailed on his slides.

Patterns

Next, Addy spoke about two patterns - the Facade pattern, which hides complex functionality behind a simple API; and the Mediator pattern, which is like Air Traffic control where a module handles all the communication between other modules.

Modules

At the lowest level, a solution to modules could be Object Literals. At a higher level, modules could be created using the Module Pattern where privacy can be simulated (I've written about this before). At an even higher level, modules can be implemented with AMD - which is something I need to look in to in more detail (perhaps a future blog post?).

Addy had explained a lot of concepts, so it was time to merge them together. To build a large scale app, Addy was proposing that we separate our code into:

1. The Application Core - Using the Mediator pattern
2. The Sandbox - Using the Facade patten
3. Modules - Using one of the module solutions

At the end of his talk, Addy showed us an impressive demo (another to-do list) where he swapped jQuery for Dojo and his app just carried on working.

[Addy's slides are available online](http://speakerdeck.com/u/addyosmani/p /building-large-scale-applications-with-javascript-and-jquery).

Doug Neiner

Doug (@dougneiner) is an excellent speaker and really got across his point clearly. Having just had a rather technical talk from Addy, Doug's talk was more related to building better jQuery code and felt like it probably should have occurred earlier in the day as it gave some context to the content the other speakers spoke about.

Doug spoke about how you can improve your code by not initialising everything at the start of page load. Use Modernizr to check whether functionality is even supported (what's the point of implementing something that isn't even going to work?); and use tricks like measuring how far the user has scrolled before implementing functionality that is based far down the page (JIT initialisation).

Doug also spoke about making code less brittle by using jQuery functionality such as .prevAll() rather than .prev(); and .closest() instead of .parent(). Whilst these functions may be slightly less performant, in the majority of cases the performance hit is so minor and unimportant it doesn't actually matter. If another developer changes your HTML, your application isn't going to break.

His talk had a couple of excellent quotes:

Write code like you spend money!

Don't invest everything in to your code at the start, get something up and running - and then invest in it later on if the code proves useful.

Write code like you buy a car!

While we'd all like a fast car, if we have a car that gets us from A to B that is normally sufficient. Faster cars whilst impressive aren't worth the cost. So weigh the difference between quality and cost.

Doug's slides are available online. Sadly, there was no to-do list.

In Summary

If today was an episode of Sesame Street, the two themes would be to-do lists and how much the Android default browser sucks. But jest aside, it was an awesome day (with an awesome after party) - and all the speakers, and the guys at White October should be very proud. If you want to read more, check out the slides (links throughout) or Jack Franklin's notes.

Can't wait for the next one!

As you are probably aware if you are working with the latest JavaScript APIs and CSS3 technologies available in the browser, these are normally prefixed with a browser vendor tag. The reason for this is usually due to the feature still being in the experimental stage. As a simple example, if we wanted to scale an element on our page (and make it work cross-browser) we would have to write the following CSS:

#myElement {
  -moz-transform: scale(2); /* Firefox */
  -ms-transform: scale(2); /* IE (9+) */
  -o-transform: scale(2); /* Opera */
  -webkit-transform: scale(2); /* Safari and Chrome */
  transform: scale(
    2
  ); /* One day someone will use this so let's keep it future proof */
}

It's a lot of code to scale an element, and there are various arguments on the web about why vendor prefixes are and are not bad; and there are even some solutions to avoid having to write this amount of CSS, such as Lea Verou's -prefix-free or [using a class file in LESS](http://net.tutsplus.com/tutorials/html-css-techniques/quick-tip- never-type-a-vendor-prefix-again/).

But there are other problems which cannot be resolved so easily, such as vendor prefixes in JavaScript. These are used for the same reason as in CSS, but there are some implementation differences - these prefixes are not hyphenated and they are case sensitive.

$("#myElement").on("click", function () {
  var transform = "scale(2)";

  this.style.MozTransform = transform; /* Firefox */
  this.style.msTransform = transform; /* IE (9+) - note ms is lowercase */
  this.style.OTransform = transform; /* Opera */
  this.style.WebkitTransform = transform; /* Safari and Chrome */
  this.style.transform = transform; /* One day, my pretty */
});

But that's a lot of code.. It makes checking for a particular event or piece of JavaScript functionality a total pain - and this is where Modernizr Prefixed comes in.

Modernizr Prefixed to the Rescue

Modernizr.prefixed(str)

At its simplest, Modernizr Prefixed allows us to find the relevant prefix for the browser the user is currently visiting your page on - which is the only browser we need to care about at runtime. For example, to find the relevant prefix for transform we would use:

Modernizr.prefixed("transform");

The value returned in this instance is a string that is relevant to your browser, as per the list above. Therefore, if we include Modernizr 2.5 in our code we can use:

$("#myElement").click(function () {
  var transform = "scale(2)";
  this.style[Modernizr.prefixed("transform")] = transform;
});

As you can see, the saving is immediately apparent. Five lines of code for vendor prefixes has become one. When a particular browser stops uses the prefixing, Modernizr Prefixer will automatically pass the correct non-prefixed value.

Confused about the square brackets? In JavaScript, dot notation and square bracket notation are interchangeable - both are used to access properties of objects. In our example, we are accessing the style property object of our element, and in turn the transform property from our style. Dot notation is tidier to write and easier to read, but does not allow us to use variables to select properties. Using square brackets we can use the result of Modernizr.prefixed('transform') to select the property we want.

But There's More..

Modernizr Prefixed can accept multiple parameters, giving it extra uses.

Modernizr.prefixed(str, obj[, scope])

If you wanted to not only find out the prefixed value but also check whether your prefixed property existed on a particular object, you could use:

$("#myElement").click(function () {
  var transform = "scale(2)";
  this.style[Modernizr.prefixed("transform", this.style, false)] = transform;
});

This code tells Modernizr to look for a transform property within this.style's properties. This example should always return a string containing the vendor prefixed name, but testing other available functionality may return objects or functions; so to be safe we can ensure it does by supplying false as the third property. For example, Modernizr.prefixed('requestAnimationFrame', window) would return a function (as requestAnimationFrame is a function, not a property).

Binding functions to other functions

By returning a function, we can simply other common uses of vendor prefixes. For example, [Paul Irish's shim for requestAnimationFrame](http://paulirish.com/2011/requestanimationframe-for- smart-animating/) (an improved way of animating elements or a canvas on a page at a regular interval) previously looked like this:

window.requestAnimFrame = (function () {
  return (
    window.requestAnimationFrame ||
    window.webkitRequestAnimationFrame ||
    window.mozRequestAnimationFrame ||
    window.oRequestAnimationFrame ||
    window.msRequestAnimationFrame ||
    function (callback) {
      window.setTimeout(callback, 1000 / 60);
    }
  );
})();

But now can be written as follows:

window.requestAnimFrame =
  Modernizr.prefixed("requestAnimationFrame", window) ||
  function (callback) {
    window.setTimeout(callback, 1000 / 60);
  };

Modernizr Prefixed again handles all the vendor prefix nastiness for us - meaning we just have to worry about the timeout condition for browsers that do not support requestAnimationFrame at all.

Vendor Prefix Appendix

If you're confused about which vendor prefix is used on each browser (and their casing), the below table is available to help you:

You can read more about Modernizr Prefixed in the official documentation.

• Language easily understood
• Illustrated
• Organised Thoughts
• Narrow Subject
• Summary

We had 3 minutes to think of an idea and prepare, and 2 minutes to present. I chose to speak about how my role as "Presentation Technical Architect" involves ensuring the web standards model is enforced. That is, the separation of structure, presentation and logic - otherwise known as HTML, CSS and JavaScript, except I couldn't call them that at any point. It's a very basic part of my job, but seemed a useful target for this demo. I decided to liken my representation to that of a smiley face to keep it simple.

• Structure - On a smiley, the structure would be the definition of the face and it's facial features. So, the number of eyes; whether there was a nose and whether there was a mouth. Each of these items belong in the face area.
• Presentation - On a smiley, the presentation would be the colour of the smiley; the shape of the face; the shape of the mouth (smiley, sad .etc).
• Logic - On a smiley face, the logic would be any movements the face can make - e.g. moving the mouth, or eyes - potentially due to some other factor (e.g something to look at).

Okay, most smileys don't move - but the analogy made everyone in the room understand the difference between these layers of a front end website. At the time, I had to illustrate on the board each of these layers. Next time you find yourself talking to someone who just doesn't get it, feel free to use this example.

If you've come here from Google and you're just getting in to developing for the web, the web standards model is something you will want to read more about, so check out [the W3C's introduction to the web standards model](http://www.w3.org/community/webed/wiki/The_web_standards_model_- _HTML_CSS_and_JavaScript).

The other day I mentioned on Twitter that I was playing around with Bartek Szopka's Impress.js library to write a presentation and it seemed to gather some interest. I then gave the presentation, and that gathered some more interest; so I thought I would write a short blog post about how to use Impress.js.

For those of you who aren't aware - Impress.js is a web-based presentation framework which utilises CSS3 transitions and transforms to produce some impressive effects.

Whilst it's primarily use is for presentations, it can also be used for simple web pages due to it's HTML/CSS/JavaScript roots. Employing a variety of different CSS animations, your presentations or pages can be brought to life through scrolling, rotating and scaling on a 3D plane. Impress.js works in the latest Chrome and Safari, as well as Firefox 10+ and Internet Explorer 10+.

So how do you use it?

Content, Content, Content

The most important part of the process of producing any presentation is the presentation itself. There is no point making a whizzy presentation if you have nothing to say.

Your slides should still follow the usual important rules of presentations - a block of text really isn't going to look any better with Impress.js than it is in PowerPoint or Keynote. Instead, keep slides short and to the point so you can expand on them when speaking.

Layout

Once your presentation has been decided, you are almost ready to start using Impress.js. But first, you need to consider how you are going to layout your presentation. Because your Impress.js presentation can move in all directions, rotate in any direction and even move closer or further away from the user, it's very easy to get in a total mess.

The best way to avoid this mess is to draw out what you want to achieve before you start; and also to keep things simple. Like an overused star wipe, if you change direction and/or rotate to a different angle on every slide your viewer is going to start getting a headache; and so are you making it.

Here's the layout we're going to go for in this example.

Now you've decided on your presentation and your layout, it's time to get started with writing the actual code.

Initial Setup

The foundation of any Impress.js presentation is the same as the foundation of any good web page. We start with the usual HTML base (a head, a title and a body tag), and add a <script> element to load in the Impress.js library and a containing element such as a <div> with the id "impress".

<!DOCTYPE html> <html> <head> <meta charset="utf-8" />
<title>Presentation Name</title> </head> <body> <div
id="impress"> <!-- our slides will go here --> </div> <script
src="library/js/impress.js"></script> </body> </html>

If you're using v0.3 or above of Impress you will also need to include the following code after you include the impress.js library:

<script>impress();</script>

Slides should be placed within your "impress" container and will appear in the order they appear in your code. Each slide is represented with the class "step", but they can be created with any block-level element (e.g., <div>, <section>, <header>). You could use the <div> element throughout, but I prefer to create my presentations with the first slide as a header element, subsequent slides as sections and the final slide as a footer as I feel it adds more semantic value. For example:

<div id="impress"> <header class="step"> <h1>Andi's
Presentation</h1> </header> <section class="step"> <p>Here's
something cool on slide 2</p> </section> <section class="step">
<p>Here's something also cool on slide 3</p> </section> <footer>
<p>Visit me at <a href="http://www.andismith.com"
target="_blank">AndiSmith.com</a></p> </footer> </div>

Positioning our Slides

Now we've created some steps, it's time to refer back to our sketch and position our slides accordingly. Impress.js uses the HTML5 data-* attribute to define the positions of our slides. There are a number of options available, which we will use as we build our slideshow.

Position Options

Slides are positioned relative to the centre of the presentation (0,0), rather than in relation to the previous slide.

Attribute - Description - Default

data-x - Position the centre of the slide on the x axis (horizontal) at the pixel coordinate specified. Use negative values to position to the left. - 0

data-y - Position the centre of the slide on the y axis (vertical) at the pixel coordinate specified. Use negative values to position upwards. - 0

data-z - Position the centre of the slide on the z axis (depth) at the pixel coordinate specified. Use negative values to position away from the screen. - 0

We will keep our first slide at the center of the page, and change our second slide to appear 500 pixels below. To do this, we use the following code:

<section class="step" data-y="600"> <p>Here's something cool on slide
2</p> </section>

Our first slide doesn't need any values as it will sit at the default position. We only need to specify the data-y value for slide 2 as it is staying at the same x coordinate.

Rotate Options

Attribute - Description - Default

data-rotate or data-rotate-z - Rotate the slide on the z-axis by n degrees. The centre of the slide is the point where rotation occurs. Use negative values to rotate anticlockwise. - 0

data-rotate-x - Rotate the slide on the x-axis by n degrees. The centre of the slide is the point where rotation occurs. Use negative values to rotate toward the user on the horizontal plane. - 0

data-rotate-y - Rotate the slide on the y-axis by n degrees. The centre of the slide is the point where rotation occurs. Use negative values to rotate toward the user on the vertical plane. - 0

For our third slide we are going to make it appear from the left and rotate 180 degrees (so it is upside down) using the following code:

<section class="step" data-x="1200" data-y="600" data-rotate="180"> <p>Here's something also cool on slide 3</p> </section>

Scale Options

Attribute - Description - Default

data-scale - Scale the slide to make it bigger (e.g. 4) or smaller (e.g. 0.5). - 1

Our footer isn't as important as the other slides, so we will shrink this slide by changing the scale to 0.5 (and, of course, moving it so it doesn't sit in the way of the previous slides).

<footer class="step" data-x="1200" data-scale="0.5"> <p>Visit me at <a
href="http://www.andismith.com" target="_blank">AndiSmith.com</a></p>
</footer>

Styling our Slides

Styling of slides still occurs in a CSS file, just as it would for a website. As we are only able to support newer browsers for our whizzy effects, and you are likely to have control over what browser your presentation is viewed in (at least initially), you may want to consider whether you drop support for older versions of IE. See HTML5Please for information of what extra functionality you could use.

For our slides, I have the following simple stylesheet:

body {
  background: #eee;
  font: 62.5% helvetica, arial, sans-serif;
  margin: 0;
  padding: 0;
}

header,
footer,
section {
  background: #fff;
  border: solid 1px #666;
  border-radius: 12px;
  display: block;
  height: 480px;
  width: 760px;
}

h1 {
  font-size: 8em;
  margin: 0 auto;
}

p {
  font-size: 4em;
  margin: 0 auto;
}

Active Slides

Sometimes you may find you can see parts of other slides on your screen, and you may wish to hide them - or you may wish to highlight the current slide when it's the one you are speaking about. Impress.js dynamically adds a class of "active" to your current slide so you can add styles where you need.

.step {
  opacity: 0.2;
}

.step.active {
  opacity: 1;
}

Linking to a Slide

If you wish to provide quick route to a particular slide in your deck, adding an ID attribute to the slide will provide a quick link. For example, a slide with an ID of "statistics" will be accessible by appending "#/statistics" to the end of the URL.

The Overview Slide

Creating an overview slide is a pretty useful way of showing the user an entire presentation on one screen. Using this view, the user can navigate quickly to the slide they want. If you've created a presentation, this would probably be your last slide for users later reading your deck. If you've created something else, it may be your first slide.

The overview slide is built as an empty slide, centered in your presentation with a large data-scale value. This transparent slide will cause Impress.js to pull its view of the page back toward the user giving them a complete overview. As we want the user to be able to see all the slides at this point, we set some additional CSS properties so that they are clearly visible (and give the users a prompt that they can click on them).

<div id="overview" class="step" data-x="600" data-y="300"
data-scale="2"></div>

.step-overview .step {
  opacity: 1;
  cursor: pointer;
}

The Fallback Message

Creating a fallback message for browsers that do not support Impress.js' functionality is also straightforward. First, we need to add a class of "impress-not-supported" to our body element. When Impress.js loads the page, it will check if it is supported and remove this class if everything is ok. Next, we need to create a fallback message within our HTML that has a CSS display setting of none, unless it has a parent with a class of "impress-not-supported".

<div id="impress" class="impress-not-supported"> <div
class="fallback-message"> <p>Your browser doesn't support the features
required by impress.js, so you are presented with a simplified version of this
presentation.</p> <p>For the best experience please use the latest Chrome,
Safari, or Firefox 10.</p> </div>

/* set some styles to show the slideshow normally for browsers we cannot
support */
.impress-not-supported .step {
  margin: 20px auto;
  opacity: 1;
  position: relative;
}

.fallback-message {
  display: none;
  margin: 20px auto;
}

.impress-not-supported .fallback-message {
  display: block;
}

Get Presenting!

And that's all there is to it! Now you know you're presentation doesn't suck, all you need to work on is your speech skills… Impress.js can't help you there I'm afraid.

I've uploaded the barebones demo presentation for you to check out, or check out Impress.js' much more impressive presentation - and then have a go yourself!

Two of the "activities" listed within this document are "Explore Front End Features" and "Write". To me, these feel like they should be one and the same thing. I was someone who used to explore front end features but never write about them. But as you are probably aware, I have recently started writing about my experiences. And now I am here to convince you to do the same.

Writing for the web can be daunting. As I wrote my first blog posts one thought kept popping up in my head:

What if I write something and someone tells me I'm stupid?

It's a completely silly thought to have, but it's one that kept crossing my mind. Could I get heckled?

In April, I spoke at my first conference. I'd set myself a goal to publicly speak at a conference after attending Full Frontal the November before. It was something that scared me, but a friend convinced me and persevered when I had doubts. I found myself at a conference with 300 people attending in a part of the world I had never ever been to. When I arrived, I was scared. I was petrified. But the important thing to remember was that people weren't attending this conference to see me fail, they were there to share and gain knowledge. No one would have taken any enjoyment if I had screwed up, and no one would have heckled if I had said something considered particularly wrong.

And it's the same with writing on the web. No one will heckle you - people may correct you, they may ask questions, they may provide better answers.

Writing my post on "25 Secrets of the Browser Developer Tools" was an awesome experience for me.

Whilst writing the article I expanded my own knowledge of each of the browsers tools as I tried to figure out whether what I was describing really was the best way to do something and also how you could replicate the same functionality in each browser. I primarily use Chrome Developer Tools and Firebug for development, so using the other tools to discover those features rapidly increased my familiarity with them.

The feedback I received from writing the article was overwhelming. Twitter was filled with people saying that they were unaware of a particular feature, or that they had learnt so much. To be able to enhance so many people's day to day development practices filled me with a warm fuzz, it was so rewarding. I went on to run an internal presentation at work to ensure that my colleagues also had the knowledge to improve their use of the tools.

Even after writing the article I was still learning. I learnt so much from the comments that people left. There were so many people that commented with their own methods, or corrections to my methods. And I was happy to have corrections or enhancements to what I had said, it made writing the article incredibly worthwhile.

Finally, the best part of writing a blog post is you have something to refer back to. If for some reason you stop using a particularly technology or tool for some months, re-reading an old blog post can provide the best refresher course you could ever ask for.

There are so many "big name" developers out there who share their experiences and because they work at Google or Opera or Mozilla it can feel daunting to try and do the same. But it shouldn't feel that way - writing about your experiences is a sure-fire way to increase your knowledge rapidly and to give back to the community.

So if you are nervous about writing, take a subject you know with some familiarity and explore it's extra hidden depths. Write about what you know, and what you find. It doesn't matter if someone else has written about it before - maybe you have a new take on the idea. And when you are done, feel free to add a comment to the end of this post so I can check out what you found..

Historically developers have used Firefox's Firebug add-on to develop and debug their websites, but more recently each browser has developed its own set of tools and each comes with its own advantages and disadvantages. Nowadays it seems hard to imagine ever building a website without one of these handy tools, which are normally accessible by either pressing "F12″ in Windows or "Cmd" ⌘, "Option" ⌥ and "I" on the Mac, or by right clicking on the page and selecting “Inspect Element”.

But are you using the developer tools to their full potential? The biggest positive about the developer tools is that they are incredibly easy to use, but as a result developers often miss out on a large proportion of the functionality provided. Inspired by [a video talk by Paul Irish and Pavel Feldman](http://paulirish.com/2011/a-re-introduction-to-the-chrome-developer- tools/), I've compiled a list of "secrets" of the developer console. I'm not expecting every one of these to be unknown to you, but hopefully some of these will help you to become an even better web developer.

If you have any more secrets, feel free to leave a comment at the end of the article and I'll update the post once I have verified them. I'd also love to know what developer console you use as your primary development tool, let me know below!

The "Console" Tab

The heart of any developer tool is the "console" tab where you can output debug and execute commands in to the current web page.

Referencing the current element

Chrome, Firefox, Opera, Safari - If you have an element currently selected in your "Elements" tab, you can use the reference $0 to call it within your code. For example, to see the elements' contents you would type $0.innerHTML. In Chrome and Safari, you can call the console from any of the other tabs by pressing "Escape" so you don't have to keep switching. In Firebug, the console is available through an icon to the left of the tabs or by pressing either Ctrl, Shift and L on Windows or Cmd ⌘, Shift and L on Mac.

In Opera, you can select the previous element you had highlighted using $1. In Chrome and Safari, you can select the previous elements you have highlighted using $1 - $4.

Using console.log to output multiple values and objects at the same time

All - We know console.log() is incredibly useful for outputting debug to the developer console, and preferred over alerts, but it can be irritating to output a string followed by an object if you're not aware of this feature of logging. Using console.log('message:' + $('#message')) will only tell you that your message is an object, and logging the object by its self can get confusing if the log is happening in the middle of a loop.

console.log() actually accepts multiple parameters, so you can output both the string and the object from the same command using console.log('message:', $('#message')); or any other combination of JavaScript type you can think of.

You can use console.warn() for warning messages; console.error() for error messaging and console.info() for information messages. You can also use console.assert() to test expressions for true or false.

(Thanks to Masklinn for additional information)

Re-using a JavaScript command

All - If you've typed a command in to the JavaScript console and you wish to re-run it, simply hit the up key to scroll through a list of previous commands you have called from the console.

Persist

Chrome, Firefox - There's an obvious button for persisting console content in Firefox right above the console, but it's slightly more hidden in Chrome. Right click in the console to reveal a menu with "Preserve Log upon Navigation" as an option.

Viewing the source of an object

Firefox - Firefox supports the toSource() method which means it's available in Firebug for printing out the contents of an object as a string in to the console.

Changing frame

Firefox - Running JavaScript commands from the console command line is incredibly useful, but if you have an iframe to contend with it quickly becomes a problem. Luckily you can use the following command to focus on the frame in question and execute your commands against.

cd(window.frames['frameName']);

Chrome - Chrome allows you to change frame in a different way. On a page which contains frames, you'll need to go to the "Console" tab and choose your frame from the dropdown at the bottom of the console.

Opera - Opera also has a dropdown for changing frame which is available from the "Console" and "Documents" tab. The dropdown will only appear on the "Console" tab if there are frames to select.

(Thanks to Paul Irish and Daniel Herzog for the additional information)

Copying your code straight to the clipboard

Chrome, Firefox, Safari - Using the copy() command within the developer tools console, you can copy the contents of a command straight to the clipboard.

Making calculations in the browser

All - This tip makes a lot of sense, but it's surprising how many people don't use it! If you need to know the answer to a math calculation quickly (e.g. the width of three columns in a 456px container) you don't need to open Calculator. Just type the math question in to the developer tools' console and it will return your answer. It's 152, by the way.

The "Scripts" Tab

Home to all the JavaScript running on the page, the script(s) tab contains a dropdown to allow you to select the script you wish to debug.

Dealing with minified JavaScript

Chrome, Internet Explorer, Safari - Placing breakpoints on JavaScript makes debugging much easier, but if your code has already made it to production then it's probably been minified. How can you debug minified code? Helpfully, some of the browsers have an option to un-minify your JavaScript.

In Chrome and Safari, simply select the 'Scripts' tab, find the relevant file in the drop down menu and then press the "{ }" (pretty print) icon located in the bottom panel.

In Internet Explorer 9, click the tool icon by the script selection drop down to find the option to format the JavaScript.

Watching variables

All - A common tool with .NET development, 'watch' allows you to monitor a list of variables from one handy area, at the top of the right hand bar on the "scripts" tab. Watching a variable is really easy, just type in the name of the variable and 'watch' will keep its value up to date.

Editing and executing JavaScript on the fly

Chrome - Rather than editing in a separate editor and reloading the page, with Chrome you can edit directly in to the page. Simply double click where you would like to change the code, and type! Hit Ctrl/Cmd and S to save.

Creating a breakpoint whenever a JavaScript error occurs

All - Simply click the pause icon in the Script tab of your developer console to pause the script when the first JavaScript error occurs. The line that has caused the error will be highlighted for you to review.

Creating a script breakpoint based on the DOM changing

Chrome, Firefox - If you know your page is breaking when a certain part of the DOM changes, or you just want to find out what script is responsible for changing that element's attribute, Chrome and Firebug both allow you to set up a JavaScript breakpoint effectively allowing you to find the culprit in your code. Simply highlight the element you want to monitor and right click to select the conditions to break on.

(Thanks to Jason Wilson for the additional information)

The "Elements" tab

Known as the "HTML" tab in Firefox and the "Documents" tab in Opera, the "elements" tab displays the DOM in its current state. On Internet Explorer, you will need to hit the 'refresh' button to see the current DOM.

Getting the dimensions of a container the easy way

Chrome, Safari - I'm a big fan of using overflow:auto to contain floated elements, but it causes problems in older versions of Internet Explorer unless you specify an actual width (auto and 100% won't suffice). The dimensions can be found in the "Computed Style" which is handy but still a number of clicks. Using Chrome or Safari, you can easily view the dimensions of an element by hovering over it in the source code in the "Elements" tab, or alternatively using the magnifying glass in the bottom toolbar.

Firebug, Internet Explorer, Opera - You'll need to select the "Layout" tab in the right hand panel or scroll through the list of computed styles in the right hand sidebar.

(Thanks to Masklinn for the additional information)

Expand view of all elements

Firefox, Opera - In Firebug, on the "HTML" tab pressing asterisk (*) on the num keypad expands all elements except scripts and stylesheets. Holding shift and pressing asterisk will also expand the scripts and stylesheet (link) elements.

In Dragonfly on Opera, there's a button in the "Documents" tab to do the same task, as shown below.

Incrementing margin, padding, width, height, border - even color

All - If you have an element which you need to modify the margin, padding, width or height for, you can use the cursor keys to increment/decrement the size.

• Simply use the up and down cursor keys to increment/decrement by a unit of 1.
• In Chrome, Firebug and Safari you can increment/decrement by a unit of 10 by holding the "Shift" key whilst pressing the up and down cursor keys.
• In Chrome and Safari, you can increment/decrement by a unit of 0.1 hold the "Alt" key whilst pressing the up and down cursor keys.
• In Chrome and Safari, you can also increment/decrement by a unit of 100 by holding down the "Shift" key whilst pressing Page-Up and Page-Down.

These shortcuts are especially helpful when you are unsure of exactly what the correct size should be. In Chrome, Safari and Opera you can also use the up and down keys to increment and decrement color values.

(Thanks to mikkelrom for the additional information)

Styling :active, :hover, :focus, :visited states

Chrome, Firefox, Opera - Styling CSS in the developer console is awesome, but becomes a little more tricky when testing other element states such as hover. Thankfully, there is a solution.

Chrome has a button built for this purpose. In the "Elements" tab's right hand column look for the dotted element/cursor icon which allows you to try other states.

For Firebug, in the right hand column click the arrow menu beside the Style tab and selected your desired state.

In Opera, it's the icon that looks like a list under "Styles".

Rotate through color definition types

Chrome, Safari - Colors can be defined in multiple ways on a web page - by name, through a hexadecimal value (3 or 6 digits), as rgb or hsl (or their alpha transparent versions). You can rotate through these different definitions in Chrome or Safari by clicking the color square next to your color.

(Thanks to Masklinn for the additional information.)

Color picker

Opera - In Opera, clicking the color square next to a color allows you to select a different color via a handy picker.

The "Resources" tab

The resources tab lists all the stylesheets, JavaScript, images used on your page. This tab unfortunately doesn't exist in Firebug or Internet Explorer, although some of its features are integrated in to other tabs.

Saving your changes

Chrome, Internet Explorer, Safari - Making changes to the CSS or JavaScript is great, but it becomes a hassle to re-implement in to your source code once you are happy.

In Internet Explorer, on each tab a "save" icon provides save to file functionality on a per file basis.

Meanwhile the "Resources" tab in Chrome and Safari has a handy feature that stores all your changes as specific revisions enabling you to quickly go back and forth through all your changes. Find the file where you've applied the changes (which can be easily accessed by clicking the file name next to the element you've changed), and a list of revisions will be provided. In Chrome, right click on the filename to save a new version of your file. In Safari you'll unfortunately have to copy and paste.

Cookies and Storage

Chrome, Opera, Safari - Also in the list of resources is a easily accessible list of different storage options together with any data stored for each option. Opera has a "Storage" tab which does the same thing.

The "Network" tab

The network tab shows all the resources and files downloaded to load your page. In most cases the developer tools need to be open for the network tab to show any information, so you may need to refresh. The tab is known as "Net" in Firefox. For Internet Explorer, it is only available in version 9 and later.

Disabling browser cache

All - Each supported browser allows you to disable cache, but there is no consistency with how.

In Chrome, you'll find the option in the settings cog. In Firebug, you'll find the option in the arrow alongside the "Net" tab header. In Internet Explorer, the option is under "Cache" in the menu bar.

In Opera, to clear the cache click the Network tab, select the Network Options secondary tab and choose the first option. In Safari, you can disable your browser cache under the Develop menu in the menu bar.

To bring up the clear cache (and other data) dialog on any browser in Windows press Ctrl, Shift and Delete.

(Thanks to Steven and karl for the additional information)

Latency

All - In Chrome and Safari, the network tab allows you to see how long it takes a server to respond to a request. The faded color line for each resource indicates when the request was sent, and when a response was sent back. The filled color indicates when the resource was downloaded. In Chrome, you can hover over these lines to get a breakdown of where the time was spent.

In Opera, the same principles apply except the latency is measured by a grey line as opposed to a faded line.

In Internet Explorer, latency is marked as yellow and hovering over the line will give more information.

In Firebug, latency is marked in the color purple and labelled as 'Waiting'. Hovering over one of these lines in Firebug also gives a detailed breakdown of where the time was spent.

DOMContentLoaded, load event fired

Chrome, Safari - The network tab for Chrome and Safari also reveals 2 additional pieces of information, DOMContentLoaded as a blue line and load event fired as a red line.

The DOMContentLoaded line indicates when the browser has finished parsing the document (but other resources such as images and stylesheets may not be downloaded), whilst the load event line indicates when these resources are complete.

If the two events fire at the same time, the line will be purple.

(Thanks to Steven and Joey for the additional information)

Other

Crashing

All - Sometimes I find my developer tools have crashed and won't respond to my mouse clicks. Rather than close the entire browser window and re-open, I often find that using the keyboard shortcuts to close and re-open the developer tools fixes the problem.

I hope these features and secrets have been useful to you, although your skill level and experience will determine how many of these are new to you. I deliberately haven't included profiling and remote debugging in this list, as these are topics I want to cover in more detail in a later post. Please feel free to leave feedback, corrections and your own tips below!

Whilst possibly not the most exciting new additions to jQuery's large utility belt, these two additions do unify all types of (good) event handling in jQuery and will help you write tidier and more efficient code in the future.

In this article, I'll give you a short introduction to both these handlers, and how you can move from your existing code of .bind(), .live() or .delegate() to .on() and .off(). Like everything in jQuery, the official documentation for .on() and .off() is pretty awesome and your best starting point for further questions, so I've included links throughout. We'll also take a look at using .one() for single use event handling..

on()

Official documentation: http://api.jquery.com/on/

The on() event handler is designed to replace both the .bind() and .delegate() event handlers. It looks like this:

$(elements).on(events [, selector] [, data], handler);

Where:

• events is the event type(s). It can be one or more space-separated event types, e.g. 'click' or 'click keydown'. It can include an optional namespaces, e.g. "click.myPlugin".
• selector specifies the decendants of the elements that trigger the event. It is optional, and if it is not included the event will always trigger when the element event occurs.
• data is any data you want to pass to the handler when the event is triggered. This is also optional, and if used is normally an object.
• handler is the function to execute when the event is triggered.

You can also use an eventsMap to specify multiple events attached to one element.

$(elements).on(eventsMap [, selector] [, data]);

For example:

$("#container a").on({
  click: function (e) {
    e.preventDefault();
    console.log("item anchor clicked");
  },
  mouseenter: function (e) {
    console.log("enter!");
  },
});

Changing from .bind() to .on()

If you are currently using .bind() in your code, you have the easiest transition to .on(). Simply replacing .bind() with .on() will - in most cases - update your code.

// old way - .bind(events, handler);
$("#container a").bind("click", function (e) {
  e.preventDefault();
  console.log("item anchor clicked");
});

// new way (jQuery 1.7+) - on(events, handler);
$("#container a").on("click", function (e) {
  e.preventDefault();
  console.log("item anchor clicked");
});

Don't feel you have to create the handler function within .on() - a tider way of coding the handler would be to call a separate function:

// handler function
function handleClick(e) {
  e.preventDefault();
  console.log("item anchor clicked");
}

$("#container a").on("click", handleClick);

This has the added benefit of allowing you to remove individual handlers later on using .off().

Changing from .live() to .on()

jQuery's .live() has been deprecated as of version 1.7. .live() was originally used for attaching event handlers to elements that did not currently exist in the DOM. This was useful functionality for pages that dynamically generate or load content, but this method has been considered bad practice for some time now.

There are a number of problems with .live(), most are to do with poor performance on large pages, a slower response or unexpected behaviour due to .live() events being attached to the document element. Unfortunately there are still a large number of developers using .live() in their code. If you're one of them, please stop. See "[Why .live() is a Bad Option](http://www.ultimatewebtips.com/why-jquery-live-is-a-bad-option-to- use/)" for more information.

So what should you use instead for dynamically generated content? You should delegate your handlers using the new .on() handler, of course! Assuming you are adding dynamic content to a DIV element with ID "container", instead of using:

// do not use! - .live(events, handler)

$("#container a").live("click", function (event) {
  event.preventDefault();

  console.log("item anchor clicked");
});

You should use the following:

// new way (jQuery 1.7+) - .on(events, selector, handler)

$("#container").on("click", "a", function (event) {
  event.preventDefault();

  console.log("item anchor clicked");
});

This will attach your event to any anchors within the div#container element, reducing the scope of having to check the whole document element tree and increasing efficiency.

Please note - the narrower your selector matches are, the more efficient your code will be. Although this example uses an anchor, try to avoid attaching a handler to every anchor. It is better to give a class or id where possible.

Changing from .delegate() to .on()

If you were using .delegate(), your code will need minor re-organisation to work as .on(). With .on(), the parameters selector and eventType have switched positions.

// old way - .delegate(selector, events, handler);
$("#container").delegate("a", "click", function (event) {
  event.preventDefault();
  console.log("item anchor clicked");
});

// new way (jQuery 1.7+) - on(events, selector, handler);
$("#container").on("click", "a", function (event) {
  event.preventDefault();
  console.log("item anchor clicked");
});

This is the only change for converting from .delegate().

off()

Official documentation: http://api.jquery.com/off/

.off() is .on()'s evil twin undoing some (or all) of the good deeds .on() has done. It's syntax looks like this:

$(elements).off( [ events ] [, selector] [, handler] );

With .off() all parameters are optional - using the parameters will allow you to be more specific in what event handling you wish to turn off. Specifying $(elements).off() will remove all event handlers from the element.

Moving from .unbind() to .off()

Simply replacing .unbind() with .off() will - in most cases - update your code.

// old way - .bind(events);
$("#container a").unbind("click");

// new way (jQuery 1.7+) - off(events);
$("#container a").off("click");

If you wanted to remove a particular handler and you have created a separate handler function you can use:

$("#container a").off("click", handleClick);

Using this method, it's possible to remove some of the event handler's functionality without removing all of it.

Changing from .die() to .off()

As you are no longer using .live() anymore, you should also no longer use .die().

// do not use! - .die(events)
$("#container a").die("click");

// new way (jQuery 1.7+) - .on(events, selector, handler)
$("#container").off("click", "a");

As with live(), die() has been deprecated. That's right, it's time for .die() to die!!!

Changing from .undelegate() to .off()

As with .on(), the order of these parameters has changed for consistency.

// old way - .undelegate(selector, events);
$("#container a").undelegate("a", "click");

// new way (jQuery 1.7+) - off(events, selector);
$("#container a").off("click", "a");

one()

Official documentation: http://api.jquery.com/one/

It's entirely possible that you may want your event to fire only once. jQuery's one() event handler attachment will handle attach the event for the first click and unattach it for subsequent clicks without you needing to write any additional code. Although one() has been included in jQuery for some time, I've rarely seen it used. In version 1.7 it has been updated to allow for delegation.

$(elements).one(events [, selector] [, data], handler);

The parameters are the same as for .on().

Now you've read an introduction to .on() and .off(), it's time to start using them in the real world. I hope this article has provided a good starter and encouraged you to investigate these new additions. If you need further information I recommend reading the official documentation, but I'm happy to answer any questions below.

Good luck!

There are multiple ways to do the same thing, and there's not necessarily a wrong or a right answer for every situation.

Take namespacing for example. As my previous post showed, there are multiple ways to declare methods within your namespace and none of them are incorrect. We all have opinions on how code should be structured and we all have our own ideas of what constitutes acceptable coding rules.

Unfortunately sometimes I encounter a problem that irritates me, and it happens much more often than I would like. It can be summarised in the following sentence:

If you are working on someone else's code, respect their coding standard guidelines.

It is so common to see code which has had contributions from multiple developers use multiple coding styles. It makes untidy code look even messier and it reduces maintainability.

Sure, you may prefer to lay your code out in different way, but unless there is a good reason for changing it (and 99% of the time, there isn't) stick with what conventions are already there. Some particular examples:

• CSS classnames that change between conventions. For example, styles that are all in lowercase with hypens, except for one area where underscores and/or camelCase is used.
• Creating a new namespace for code that belongs in the existing JavaScript namespace.
• Adding images, CSS or JavaScript to a completely different folder to where the rest are stored - or in to the root.
• CSS styles blindly added to the end of a stylesheet, breaking the perceived structure of the code - or styles added in to the reset styles area.
• Indenting of CSS styles or brackets.
• A extra CSS or JavaScript file added for reasons logic cannot understand.
• And my personal favourite - finding a single extra function that should belong in a namespace sitting outside in the global scope.

For me, there is nothing worse than seeing a project where everyone on the team is using a particular standard, and someone else isn't. As far as I'm concerned, this person has poor attention to detail, this person is a code vandal. I like tidy, maintainable code. I shouldn't be able to view source on your code and be able to tell it was written by multiple people.

So next time you work on an existing project, take the time to read through the code layout that already exists and ask yourself "how can I integrate the code I write seamlessly in to this project?".

Be considerate not Taz.

If you're good JavaScript developer you should be placing your code in a namespace. A namespace stops collisions with other JavaScript files, reduces the use of the global scope and generally makes things tidier. Having variables in the global scope is considered bad practice as the variable could be overwritten or modified by any other JavaScript code anywhere. The most common way of placing your code in a namespace would be in an object literal like this:

var example = {
  publicVariable: "publicValue",
  publicMethod: function () {},
};

Here we have a variable called example (which becomes our namespace) and we are declaring all our variables and methods within this. If we wanted to know the value of publicVariable we would call example.publicVariable; if we wanted to execute publicMethod we would call example.publicMethod()

If you wanted to separate your private and public methods and create a closure (a mini environment which has access to the namespaces' local variables even when the function is returned), you'd probably do this:

var example = (function () {
  var privateVariable = "privateVariable";

  function privateMethod() {
    return 1;
  }

  return {
    publicVariable: "publicValue",
    publicMethod: function () {
      //return privateMethod();
    },
  };
})();

Here we have changed our namespace in to a anonymous self executing function. We have created private variables and functions which are only accessible within this namespace, and public variables and functions which are returned by the self executing function making them accessible by our entire codebase. We can call example.publicMethod(), but we cannot call privateMethod() outside of the namespace. If we were to uncomment the line of code within publicMethod(), we would be able to execute privateMethod from within this namespace.

The following code is also self executing but sets out our namespace with a much tidier, modular feel. It's my new favourite way of organising my code and has quickly become my most used pattern. Obviously, you should always use the best pattern for the job - there are some good books to read about JavaScript patterns (such as 'Pro JavaScript Design Patterns' by Dustin Diaz and Ross Harmes).

(function (example, $, undefined) {
  var privateVariable = "privateValue";

  example.publicVariable = "publicValue";

  function privateMethod() {}

  example.publicMethod = function () {};
})((window.example = window.example || {}), jQuery);

Focussing first on our top and bottom lines, you can see our arguments in the function call, and the values for these arguments at the bottom when the function is executed. The first difference to be noted with this approach is that we now pass the namespace in to the function as a parameter. We check whether it already exists in the global namespace (window). If it does we pass the existing namespace so we can append to it. If it does not, we pass an empty object literal.

The second argument passes in our jQuery object, although it could pass in any favourite JavaScript library. As the code we are executing is in its own local scope, we can now use the $ variable safe in the knowledge that no-one else has declared $ for use as anything else. We also include an argument of undefined and pass in no correlating value which [removes the threat of someone else redefining undefined](http://pt.withy.org/ptalk/archives/2005/06/ dont_assume_undefined_is_undefined.html).

Within the function itself you still get you get all the benefits of private and public variables and functions but you don't need to place all your public functions and variables in to a return object literal. This means your private functions can refer to your public ones without needing to specify the entire namespace (just example.publicMethod()), and you do not need to remember to use object literal notation - which makes for tidier code and less chance of missing a comma or two.

Finally, it's easy to expand. You can expand your module with more functions and variables just by including window.example = window.example || {}

Let me know what you think below, and be sure to [read the original article by Elijah!](http://enterprisejquery.com/2010/10/how-good-c-habits-can-encourage- bad-javascript-habits-part-1/)

Depending on whether I've written a few or many blog posts at this point, this may be an achievement that you've reached this post, or it may have been a simple slide of the finger. Regardless - congratulations, here is your prize.

So as a lame secondary reward, I thought I'd give you some back story as to how I became a web developer.

As a kid I was obsessed with making lists. Lists of anything and everything. Our house didn't get our first PC until I was 15 (1997) and at that point people in my neighbourhood weren't on the Internet.

After attending a introduction to further education at Brighton University, I discovered that the CD ROM which contained all our reading materials also included this program called Netscape which could be used to display all the reading material. I liked the idea of being able to produce documents with more freewill than Microsoft Word and as the reading material code was open source (thank you web!), I could peak in and figure out how to build these HTML pages myself. And therefore I learnt HTML in my spare time by creating both a simple college site for my friends and a Red Dwarf fan site (space background, the usual). Not that I had the Internet, so it could never go live.

It wasn't until a year or two later where I actually got the Internet and was able to post my first web page online. Some months later I was online and started my own website using the trusty HTML table layout I’d learnt all by myself to distribute some crappy games I’d made.

Then in 2000 I met Theo Chakkapark.

Without Theo, who knows where I’d be. I was frustrated and uninspired by having to learn Java at university thanks to C++ being removed from the syllabus after I enrolled. And the university were trying to suggest Java applets were the future of the web which felt wrong against everything I had taught myself.

“Why not try using Server Side Includes?” asked Theo. “They’ll let you include common content on every page without having to repeat it in your code.”

I was confused. “But I can use frames, and they are better! Look, I can scroll the sidebar independently of the main site!”

Thank goodness Theo stuck with me. Not only did he convince me Server Side Includes were better than frames, but he encouraged me to switch to ASP giving me a simple blogging system which I could learn from. I did learn from it, and suddenly got very ambitious. So Theo gave me an opportunity to run my site on his network, where it eventually became an incredibly popular community with over 10,000 registered users. His introduction to a basic feature of classic ASP led on to me producing a indie games community site, with dynamic updates, commenting, membership, forums and skins. Unfortunately, the site got so popular I was eventually asked to move to my own server as I was eating bandwidth – but my hunger for learning thereafter never stopped.

I went on to build an e-commerce site for my dissertation; then started work learnt ASP.NET; and then CSS and so forth. Theo helped me get a step on the ladder by taking the time to teach me how to improve on something I was interested in.

Now we are reaching a time where HTML5 and CSS 3 are coming of age. I find myself becoming Theo and teaching other web developers the benefits of learning proper JavaScript and the latest techniques in modern technologies; and this is what this blog is for. To talk tech, and to help others.

Thanks Theo, wherever you are. I don’t think he realises quite what an impact he made...