
I would classify myself as a vibe coding enthusiast, starting with Copilot and
V0, then Devin, Cursor, and now Claude Code. I've also been writing code since I
was 13 years old.

I guess I'm an AI-first developer now. I'm not really sure when it happend but
the majority of my code comes from a coding agent, but that doesn't mean I
copy-paste an issue description somewhere and leave the agent to its own
devices. Far from it, actually.

I still own the problem-solving process completely. I'm the one figuring out
what needs to be built and why. I'm thinking through the tricky bits, deciding
how data should flow through the system, and making sure all the pieces will
play nicely together. Then Claude handles the implementation. It's like being an
architect who sketches the blueprint and lets skilled craftspeople handle the
construction. You're still deeply involved in the creative process, just at a
different level of abstraction.

Does it make you faster? I don't think so. Maybe a little bit? But Chris! I've
been told that we'll be able to 100x our engineering teams!?!

I think most of us are pretty skeptical when we hear those kinds of numbers, but
I've also worked with enough slow processes to know that you can make
improvements of several orders of magnitude. In my experience, these changes are
often organizational and workflow-related, not technical. There might be
technical changes that enable the transformation, but a new tool is probably not
going to make you that much faster on its own.

One of my favorite examples is when the
[CEO of Gumroad talks about how he can now build things 40 times faster](https://www.youtube.com/watch?v=KVZ3vMx_aJ4).
He explains that if he wanted something "relatively trivial" fixed in one of
their products, he would need to write a spec, send it over to a designer, who
would send it to an engineer, and it would take two weeks of back and forth
before it was shipped. Now he can do it in hours. I haven't double-checked the
math, but that is a great improvement! But here's the thing: if you can't ship a
trivial change the same day, you have either a product problem or an engineering
problem, and probably both. I would bet it wasn't the AI that made them faster,
but that changing tools made them look at how they work and improve it. The AI
was the spark, not the cure.

This brings me to an interesting observation: AI tools and agents have become a
driver of good engineering practices. Think about it. If you can create a quick
code change, you'll want to deploy it quickly as well. Are you telling me we
have to wait until next week for a deploy? Why can't we do it now? The friction
becomes more apparent when the code creation is so smooth.

As there's more AI-generated code, there's also more need for tests, and fewer
excuses not to write them. When your AI assistant can write comprehensive test
suites in minutes, suddenly that "we'll add tests later" excuse doesn't fly
anymore. All of a sudden, I'm talking to people about writing documentation,
because they want the AI to understand the codebase better. It's funny how
giving our tools better context has made us better at documenting our own work.
Our CEO has been spending time making our CI pipeline faster, so that Devin will
run faster. The tools are pushing us to fix the problems we've been ignoring for
years.

<img alt="Cleaning up your project" loading="lazy" src="/images/cleaning-up.webp" />

I wouldn't expect AI tools to make your engineers much faster individually, but
We can use the introduction of these tools as a catalyst for change in how we
work, invest in our processes and our tooling to build better software and ship
it more often. The real speed improvements come from removing the organizational
cruft that's been slowing us down all along.

So we're not looking at raw programming speed, but I think there's something to
say about consistency. If you have a slow day, Claude still keeps going. We all
have those days where our brain feels like molasses, where even simple tasks
feel insurmountable. Your AI assistant doesn't have those days. It also helps
with your cognitive load and avoiding energy-draining tasks.

The other day, I changed how we set up one of our orchestrators and created a
`createOrchestrator` function that would make sure you always get the right kind
of orchestrator, depending on your environment, your feature flags, etc. Then I
had to update 40 to 50 tests and change how the orchestrators were mocked.
That's the kind of task that's just miserable, will probably take you the rest
of the afternoon, and you won't get anything else done that day. It's the kind
of work that makes you question your career choices. Now that you can offload
those tasks to your agent, you can spend your energy on more important work. You
can focus on the interesting problems while your assistant handles the tedious
refactoring.

As you become a more senior engineer, you are not just writing code anymore. You
spend more of your time designing solutions, describing work to be done, and
planning future projects. Transferring what's in your head to a piece of paper
or to your colleagues can be challenging and sometimes frustrating. You know
exactly what needs to be built, but articulating it in a way that others can
understand and implement is a skill that takes years to develop.

When you work with agents, you get so much more practice doing this. You get to
work your explainer muscle so much more than you normally get to do, and with
much smaller stakes. If your explanation to Claude isn't clear, you'll know
immediately when the output doesn't match your vision. Instead of writing a
one-sentence prompt, practice shaping the problem space, describe what routes
you want there to be, or which flows you expect. Talk about how you want your
components to be structured or what background jobs will be needed, but avoid
the implementation details. You can leave that up to the agent, just like you
would for another developer. You can always improve it later.

This practice translates directly to working with human developers. The skills
you develop explaining technical concepts to an AI make you better at technical
communication in general. You learn to anticipate misunderstandings, provide
necessary context, and structure your thoughts more clearly.

<img alt="Training your feedback muscle" loading="lazy" src="/images/running.webp" />

That brings us to the next muscle we get to train: our feedback muscle. Giving
good, actionable feedback is hard, and with your agent, you'll get an almost
instant response, making feedback rounds quick and fun. I've noticed that I've
raised my bar, and things that I would leave unsaid, I now bring up because with
AI, addressing minor things becomes very low cost. You can say "this works, but
could we make the variable names more descriptive?" or "let's extract this into
a separate function for better readability" without worrying about hurting
someone's feelings or seeming nitpicky.

This habit of giving precise, constructive feedback carries over to code reviews
with your human colleagues. You become more comfortable pointing out
improvements, and you learn to frame your feedback in ways that are helpful
rather than critical.

Personally, I was only using Copilot's code completions for a long time. Even
though I think what Cursor and Devin enable is impressive, I don't think they
are very good products. They feel more like tech demos than tools I want to use
every day. Instead, it's been
[Claude Code](https://docs.anthropic.com/en/docs/claude-code/overview) and
[OpenCode](https://github.com/sst/opencode) that have been a real joy to use,
and I'm not even a terminal kind of guy. They are really polished and work great
as everyday coding assistants. The difference is in the details - how they
handle context, how they recover from mistakes, how they integrate into your
existing workflow. If you haven't given them a try yet, you definitely should.

~ Good vibes


Vibe Coding Makes You a Better Engineer


[Chrome extensions](https://developer.chrome.com/docs/extensions/get-started)
are a cool way of automating things you do in the browser. Recently, Chrome
changed its guidelines and broke a bunch of extensions, so I had to recreate
some of the ones I use often. I haven't created Chrome extensions since 2020, so
it's been a while, and some of our preferred tools have changed. Now we have
awesome tools like Vite and shadcn/ui, and we can use them to supercharge our development.

I wanted to use my usual stack of React, Tailwind, and shadcn/ui. Even if you
don't need most of it for all extensions, it's better to have it and not need it
than to need it and not have it. Here are the steps you need to create a Chrome
extension using React, Tailwind, and Vite.

Nowadays, I usually use Bun to run my TypeScript code. If you want to use Node
with yarn or npm, using Node 23 will make your life a lot easier as it comes
with built-in TypeScript support, and you don't need to deal with as many ESM
issues.

> 💡 **Vibe Coding Tip:** If you're looking to speed up your Chrome extension
> development, Claude Code is super helpful once you have your project structure
> set up the way you like it. I've found it especially good at helping write
> components, suggesting fixes for manifest issues, and explaining Chrome's
> APIs. Just describe what you want your extension to do, and Claude can help
> you implement it step by step!

## Step 1: Create a Vite Project

First, let's initialize a new Vite project with React and TypeScript support:

```bash
npx create vite@latest --template react-ts my-chrome-extension
cd my-chrome-extension

```

This creates a new project with React and TypeScript all ready to go. Super
convenient, right? The template gives you a basic setup that we'll tweak for our
Chrome extension.

## Step 2: Create the Manifest File

Every Chrome extension needs a manifest file - it's like the ID card for your
extension. Create a file named `manifest.json` in the root of your project with
the following content:

```json
{
  "name": "Vibe Extension",
  "description": "Good vibes in Chrome.",
  "version": "1.0",
  "manifest_version": 3,
  "action": {
    "default_popup": "dist/index.html"
  }
}
```

This is a super minimal manifest that creates a pop-up extension. The
`action` field tells Chrome to load our popup from the `dist/index.html` file
that Vite will generate when we build. You can add more stuff later, like
permissions and background scripts, but this is all we need to get started.

## Step 3: Configure Vite for Extension Development

Here's the tricky part - Vite normally builds files with absolute paths, but
Chrome extensions need relative paths to work properly. Let's fix the Vite
config to make it extension-friendly.

Create or update the `vite.config.ts` file in your project root:

```typescript
import react from '@vitejs/plugin-react'
import { resolve } from 'path'
import { defineConfig } from 'vite'

export default defineConfig({
  base: './',
  build: {
    assetsInlineLimit: 0,
    outDir: 'dist',
    rollupOptions: {
      output: {
        entryFileNames: '[name].js',
        chunkFileNames: '[name].js',
        assetFileNames: '[name].[ext]'
      },
      input: {
        main: resolve(__dirname, 'index.html')
      }
    }
  },
  plugins: [react()]
})
```

This configuration does a few key things:

- Changes the base path to `./` so assets load from relative paths (super
  important!)
- Sets the build output folder to `dist` to match our manifest
- Makes the file names prettier and easier to debug
- Tells Vite which file to start with (`index.html`)

## Step 4: Add Tailwind CSS

Now let's add Tailwind for styling:

```bash
bun add -D  tailwindcss @tailwindcss/vite
```

Update your `src/index.css` file to import Tailwind:

```css
@import 'tailwindcss';
```

Now let's update our Vite config to include Tailwind.

```typescript
import tailwindcss from '@tailwindcss/vite'
import react from '@vitejs/plugin-react'
import { resolve } from 'path'
import { defineConfig } from 'vite'

export default defineConfig({
  base: './',
  build: {
    assetsInlineLimit: 0,
    outDir: 'dist',
    rollupOptions: {
      output: {
        entryFileNames: '[name].js',
        chunkFileNames: '[name].js',
        assetFileNames: '[name].[ext]'
      },
      input: {
        main: resolve(__dirname, 'index.html')
      }
    }
  },
  plugins: [react(), tailwindcss()]
})
```

## Step 5: Create a Simple React Component

Let's make our extension actually do something! Update the `src/App.tsx` file
with some Tailwind classes:

```tsx
import { useState } from 'react'

function App() {
  const [message, setMessage] = useState('Hello from Chrome Extension!')

  return (
    <div className="min-h-screen bg-gradient-to-r from-purple-400 to-pink-500 flex items-center justify-center">
      <div className="bg-white p-8 rounded-lg shadow-lg max-w-md w-full">
        <h1 className="text-2xl font-bold text-gray-800 mb-4">
          Vibe Extension
        </h1>
        <p className="text-gray-600 mb-6">{message}</p>
        <button
          className="w-full bg-purple-500 hover:bg-purple-600 text-white font-semibold py-2 px-4 rounded"
          onClick={() => setMessage('Spreading good vibes!')}
        >
          Activate Good Vibes
        </button>
      </div>
    </div>
  )
}

export default App
```

This creates a simple popup with a gradient background, a card, and a button
that changes the message when you click it. You can customize this part with
whatever UI components you need for your extension.

## Step 6: Build Your Extension

Now, let's build the extension:

```bash
bun run build
```

This command will generate the distribution files in the `dist` directory:

```
dist/
  index.html
  main.css
  main.js
```

## Step 7: Load Your Extension in Chrome

Now for the fun part - let's see it in action!

1. Open Chrome and go to `chrome://extensions/`
2. Turn on "Developer mode" with the toggle in the top-right corner
3. Click "Load unpacked" and pick your project folder (the one with the
   `manifest.json` file)

Your extension should show up in the list. Click the extension icon in your
toolbar and you'll see your React app in a popup!

Remember to run `bun run build` whenever you make changes to your code. After
building, go back to the Extensions page and click the refresh icon next to the
**on**/**off** toggle to reload your extension with the latest changes.

## Troubleshooting Common Issues

You can open the developer tools for the extension to see if there are any
errors. You can do this by right-clicking on your extension popup and selecting
"Inspect".

### My Extension Isn't Showing Up!

If you don't see your extension after loading it:

- Double-check your `manifest.json` file - a missing comma or bracket can break
  everything
- Make sure the path to your `index.html` in the manifest points to where your
  build output actually is

### My CSS and JS Aren't Loading!

If your extension loads but looks broken:

- Make sure you have that `base: './'` setting in your Vite config - this is the
  #1 issue
- Check the file names in your build output match what you expect

---

_Found this useful? Drop a comment and let me know what kind of extension you're
building!_


Building a Chrome Extension with Vite, React, and Tailwind CSS in 2025


Today, I wanted to talk about a topic that's been buzzing around Twitter and dev
circles lately. You've probably heard people say, **"Now that we're server-side
rendering JavaScript, it's just PHP all over again!"** 🤔 Well, I want to
explain why I don't think that's quite the case – and why it's actually, it's
pretty darn exciting!

Remember when Internet Explorer was still a thing? (I know, I'm aging myself
here). We were all writing PHP to our heart's content, and life seemed simpler.
But things were different: we weren't building the complex, ambitious apps we
are today. We were solving smaller problems, and that's what people often miss
when they get nostalgic.

Back then, we'd use server-side languages like PHP, Java, or – if you were
really living on the edge – Perl. We'd follow the
[MVC model](https://guides.rubyonrails.org/getting_started.html#mvc-and-you),
popularized by frameworks like Rails and Code Igniter. Our controllers would
fetch data from the database, pass it to a view, and voila, you had rendered a
page. When you visited a URL, you'd get a bunch of HTML, the browser would
render it, and everything was hunky-dory.

But what about interactivity? Well, that's where JavaScript came into play. We'd
use it to enhance the existing elements rendered on the server. Remember
"unobtrusive JavaScript"? 😂 It was all about making the UI work with native
browser primitives and then sprinkling some JS magic on top. Looking back, I
think it might've been an excuse to avoid writing too much JavaScript – and
honestly, who could blame us?

My experience with early JS was a bit of a mixed bag. jQuery made it easy to add
functionality, but the language, much like PHP, wasn't pleasant to work with.
Before ES6, it was pretty terrible to work with. Raise your hand if you remember
`var self2 = this`. And don't even get me started on browser compatibility! 🙈
We tried our best to write as little JavaScript as possible, using it in places
where it was absolutely necessary.

But here's the thing. We wanted to build more stuff. More impressive apps. We
need better functions for our users, and as our apps got more and more
ambitious, we couldn't escape JavaScript. It's the language of the web, after
all! As we built larger and more complex applications in the browser, we started
running into some serious headaches.

For starters, creating your UI on the server and then editing it at runtime with
JavaScript was like trying to pat your head and rub your belly simultaneously –
possible, but not exactly graceful. 😅 Imagine having a blog post like this one
with a commenting system. You would loop over all the comments in your template
and create the HTML structure on the server. But what happens when the user
posts a new comment, and you need to create a DOM element in the browser? You'd
either have to recreate the comment structure with the same tags and classes in
JavaScript (hello, maintenance nightmare!), or you would create a hidden
template element, clone that element, and then populate the right divs with the
correct data and hopefully, no one had changed the class names in the template.
It was... not ideal, to say the least.

We also realized that using imperative code for building UIs was as fun as
trying to herd cats. We wanted our UIs to be declarative and based on state, and
we wanted reusable components. That way, we could always render the UI correctly
without worrying about things getting out of sync.

So, we moved everything to the client. Single-page applications became all the
rage, and we had rich interactivity at our fingertips. It was amazing... until
it wasn't...

We could now build amazing user experiences, but that came with a new set of
challenges. First off, we had to reinvent navigation. No more simple URL hits
and HTML returns – now we needed routing frameworks to handle page loads and
transitions. Sure, we gained some superpowers like keeping state between pages,
but with great power comes great responsibility. I've lost count of how many
"links" I've seen in SPAs that are just buttons with click handlers. 🤦‍♂️

Now, we are loading our data from our API so we can show and modify data with
ease, but we have to figure out how to deal with loading states and waterfalls.

Then came the performance. When your entire app lives on the client, it's now up
to your device to create the whole UI. It's not exactly speedy, and having the
server render an empty div and a script tag for each page is not exactly great
for SEO.

However, perhaps the biggest drawback was how it solidified the divide between
front-end and back-end developers. Back in the day, we were all just "web
developers." Sure, you might have preferred centering divs to writing database
queries, but working across the stack was common. This division created
communication barriers and, I believe, led to worse products overall. After all,
how can you create a unified experience when your teams are not?

![Sunrise](/images/sunrise.webp)

Now, here's where it gets exciting! We're not going back to PHP – we're moving
forward with full-stack JavaScript frameworks like
[Next.js](https://nextjs.org/), [Remix](https://remix.run/), and
[SvelteKit](https://kit.svelte.dev/). 🚀 These frameworks give us a unified
stack with JavaScript all the way, baby! We can handle routing and data-loading
on the server. We can build our UIs using state-of-the-art, declarative
components and create amazing user experiences using the best of both worlds.

I know what you're thinking. Isn't React Server Components with SQL queries just
like the old PHP code we all hated? What happened to the separation of concerns?
Well, not quite! Sure, at first glance, it might look like that crazy PHP code,
where we would mix SQL, HTML, and CSS, stick it in index.php, and call it a day.
But here's the difference: we've developed solid principles for building UIs,
and now we have a unified language and toolkit to create great user experiences,
utilizing both what the server is good at and what the browser excels at.

We're not going backward – we're taking all the lessons we've learned and
creating something even better. It's like we've taken the best parts of our PHP
days and supercharged them with everything we love about modern JavaScript. We
can now build really ambitious applications and frameworks like Next.js and
Remix allows us to utilize the server for more than just serializing JSON.

But here's where it gets really exciting: these full-stack JavaScript frameworks
are helping us close the gap between frontend and backend developers. 🌉
Remember that artificial divide we created? Well, it's starting to crumble, and
that's a good thing! With a unified language and toolset, it's becoming easier
for a single developer to build an end-to-end feature. No more awkward handoffs
between teams or lost-in-translation moments. You can now handle everything from
database queries to UI interactions in one seamless flow. It's like being a web
development superhero with powers on both sides of the stack! I don't think it
will make development more efficient but also lead to more cohesive products.
After all, when you understand both the server and client side, you can make
smarter decisions about where to put logic and how to optimize performance. It's
bringing us back to the "full-stack developer" ideal but with way cooler tools
and without the spaghetti code nightmares of the past. So, if you've been
feeling pigeonholed as a "frontend" or "backend" dev, now's your chance to break
free and embrace the full spectrum of web development!

It's a fantastic time to be in our field! If you haven't dived into modern
JavaScript frameworks yet, what are you waiting for? Today's the day! 🚀 We've
come a long way from nesting PHP in HTML, and while it might look similar on the
surface, we're building on years of UI development principles and best
practices.

I'd love to hear your thoughts on this! Have you made the switch to full-stack
JavaScript? Are you still holding onto PHP for dear life? Please drop a comment
below and let's chat!


React on the server is not PHP


Normally, when you work in a React app, you don't have to think too much about
the DOM and your place in it. You just create your elements, and React will make
sure that they end up in the right place in the tree.

This is usually an awesome part of React, but sometimes, you need to break out
of your component and render a component somewhere else. You might want to
render a modal and its overlay at the top level of the page, or you might want
to render a tooltip outside of its parent to avoid clipping. Here is where
Portals come in handy. A React Portal is a function that lets you take your JSX
and render it as a child of another element anywhere in the DOM.

The `react-dom` package contains a
[createPortal](https://react.dev/reference/react-dom/createPortal) function that
we can use:

```tsx
createPortal(children, domNode, key?)

```

Let's say that we have a `<Toast />` component, and we want to render it as a
child of the `<body>` tag, regardless of where in the component stack it's
rendered. We can wrap our JSX inside of the `createPortal` function and pass
`window.document.body` as the second argument:

```tsx
import { ReactPortal } from 'react'
import { createPortal } from 'react-dom'

interface ToastProps {
  isVisible: boolean
  message: string
}

export const Toast = ({
  isVisible,
  message
}: ToastProps): ReactPortal | null => {
  if (!isVisible) {
    return null
  }

  return createPortal(
    <div className="toast">{message}</div>,
    window.document.body
  )
}
```

> Notice that the `ReactPortal` type comes from the `react` package while the
> `createPortal` function is provided by `react-dom`.

Even though we render the `<Toast />` inside the app `<div>` when you inspect
the page, you will see that the toast element is added as a child to the body.

```tsx
import { Toast } from './Toast'

import './styles.css'

export default function App() {
  return (
    <div className="App">
      <h1>Hello CodeSandbox</h1>
      <h2>Start editing to see some magic happen!</h2>
      <Toast
        isVisible={true}
        message="This is a toast."
      />
    </div>
  )
}
```

We can add even more control to where the `<Toast />` is rendered by adding a
Ref parameter to its properties.

```tsx
import { ReactPortal, RefObject } from 'react'
import { createPortal } from 'react-dom'

interface ToastProps {
  containerRef?: RefObject<HTMLElement>
  isVisible: boolean
  message: string
}

export const Toast = ({
  containerRef,
  isVisible,
  message
}: ToastProps): ReactPortal | null => {
  if (!isVisible) {
    return null
  }

  const container = containerRef?.current ?? window.document.body

  return createPortal(<div className="toast">{message}</div>, container)
}
```

Now that our `<Toast />` component accepts a ref, we can create a container and
a respective ref and pass it to the `<Toast />` component.

> Remember that you have to pass `null` as a parameter to `createRef()` to get
> the correct type.

```tsx
import { useRef } from 'react'
import { Toast } from './Toast'

import './styles.css'

export default function App() {
  const toastContainerRef = useRef<HTMLDivElement>(null)

  return (
    <div className="App">
      <h1>Hello CodeSandbox</h1>
      <h2>Start editing to see some magic happen!</h2>
      <div ref={toastContainerRef} />
      <Toast
        containerRef={toastContainerRef}
        isVisible={true}
        message="This is a toast."
      />
    </div>
  )
}
```

Even though our container `<div>` and our `<Toast />` components are rendered
side by side in the React world when you look to add the DOM, the toast element
will be rendered inside the container.

<img alt="A cube coming out of a portal" height="auto" loading="lazy" src="/images/box-in-portal.webp" width="100%" />


Using React Portals with TypeScript


Today I ran into the problem of trying three objects, evenly spaced on the screen of a mobile device. But that brought more trouble than I initially thought. It's a pretty common scenario. In my case, it was for a podcast view and trying to fit a title, a poster image, and the controls above the fold. It could also be a landing page where you want to fit an interesting title, a blurp, and a call to action button on the first screen that the users see.

![Example](/images/vertically-center-content-with-css/example.png)

We know that we want the content centered on the page and that we need some space in between. It sounds like a job for Flex!

```html
<div class="screen">
  <div class="centered-content">
     <div class="centered-content__item">
       <h1>
         Make up to $35 Driving Your Car
       </h1>
     </div>
      <div class="centered-content__item">
       <p>
         How many ours do you want to drive per week?
       </p>
     </div>
      <div class="centered-content__item">
       <button>
         Become a Driver
       </button>
     </div>
  </div>
</div>

```

```css
.screen {
  height: 100vh;
  width: 100%;
}

.centered-content {
  align-items: center;
  display: flex;
  flex-direction: column;
  height: 100%;
  justify-content: center;
  text-align: center;
  width: 100%;
}

.centered-content__item {
  margin-bottom: 128px;
}

```

So let's break this down:

- First, we create a container that will cover the whole screen.
- Inside the container, we use Flex to center the content.
- We add a margin to the bottom of each item so that they have some room to breathe.

Pretty good so far. 🎉

But when we try it on a smaller screen, the content won't fit. Because of the fixed margin, the content will take up the same amount of space on any screen and that becomes a problem here.

<div class="flex flex-wrap justify-center">
  <img alt="Margin on iPhone XL" class="block shadow-lg" src="/images/vertically-center-content-with-css/i-phone-xl-margin.png" />
  <img alt="Margin on iPhone 5" class="block shadow-lg" src="/images/vertically-center-content-with-css/i-phone-5-margin.png" />
</div>

One approach to this would be to use Media Queries. That way, we can conditionally format the content depending on the screen height. I would like to avoid that. Even though Media Queries gives you a lot of control, it also adds extra complexity to our stylesheets.

So thinking a bit more about the spacing, we want it dynamically adjust depending on the space available. We can use `justify-content: space-between` which spreads the items out evenly.

```css
.centered-content {
  align-items: center;
  display: flex;
  flex-direction: column;
  height: 100%;
  justify-content: space-between;
  text-align: center;
  width: 100%;
}

```

This works a lot better on our small device. But now there is way too much space between the items on a bigger screen.

<div class="flex flex-wrap justify-center">
  <img alt="Space Between on iPhone XL" class="block shadow-lg" src="/images/vertically-center-content-with-css/i-phone-xl-justify.png" />
  <img alt="Space Between on iPhone 5" class="block shadow-lg" src="/images/vertically-center-content-with-css/i-phone-5-justify.png" />
</div>

In situations like this, when we have conflicting behavior, it's because we want to do too many things. We need to cut boards and punch nails and we are trying to get our hammer to do both. The good thing about programming is that we can create new tools!  We can add a new class that spaces the content out.

```css
.centered-content {
  align-items: center;
  display: flex;
  flex-direction: column;
  height: 100%;
  justify-content: center;
  text-align: center;
}

.centered-content__evenly-spaced {
  display: flex;
  flex-direction: column;
  justify-content: space-between;
  height: 100%;
  max-height: 620px;
}

```

This way, we have a whole new class that's only responsible for handling the spacing of the items. The interesting addition here is that it will fill the whole screen on smaller screens.

But as the screen grows in height, the `max-height` property will limit how big it can get to avoid spacing things out too much.

<div class="flex flex-wrap justify-center">
  <img alt="Max Height on iPhone XL" class="block shadow-lg" src="/images/vertically-center-content-with-css/i-phone-xl-max-height.png" />
  <img alt="Max Height on iPhone 5" class="block shadow-lg" src="/images/vertically-center-content-with-css/i-phone-5-max-height.png" />
</div>

```html
<div class="screen">
  <div class="centered-content">
    <div class="centered-content__evenly-spaced">

     <div>
       <h1>
         Make up to $35 Driving Your Car
       </h1>
     </div>

      <div>
       <p>
         How many ours do you want to drive per week?
       </p>
     </div>

      <div>
       <button>
         Become a Driver
       </button>
     </div>

    </div>
  </div>
</div>

```

```css
.screen {
  height: 100vh;
  width: 100%;
}

.centered-content {
  align-items: center;
  display: flex;
  flex-direction: column;
  height: 100%;
  justify-content: center;
  text-align: center;
}

.centered-content__evenly-spaced {
  display: flex;
  flex-direction: column;
  justify-content: space-between;
  height: 100%;
  max-height: 620px;
}

```

<div class="flex flex-wrap justify-center">
  <img alt="Final Result on iPhone XL" class="block shadow-lg" src="/images/vertically-center-content-with-css/i-phone-xl-final.png" />
  <img alt="Final Result on iPhone 5" class="block shadow-lg" src="/images/vertically-center-content-with-css/i-phone-5-final.png" />
</div>

There is a lot of awesome tools we can use to create beautiful layouts but it still has a lot of challenges, especially in a world of a multitude of different screen sizes and devices.

Focusing on the different behaviors we want to accomplish is a good way to break things down. When things are getting too complex, try to keep each part simple and with their own responsibility.


Vertically Center Content with CSS on Mobile Devices


As our app consists of a couple of different bundles and a bunch of chunks, we
noticed that our Cypress test suite was a bit flaky. Dynamically loading
different Javascript and CSS files caused our test to fail due to timing issues.

Looking into a bit more we found that when we are calling `cy.visit()` to
navigate to a page, we were ending up with tests that were randomly failing due
to not all Javascript being loaded yet.

If you look at the documentation for `cy.visit` it says

> cy.visit() yields the window object after the page finishes loading.

While this is true, if you dig a bit deeper you'll realize that it yields on the
window's on-load event. This will probably work well in most cases but as we are
throttling our Javascript load we encounter some problems where not all the code
that we need is downloaded when the on-load event is called.

Cypress has a `route` command that can be used to wait for and/or mock requests,
but it only triggers on XHR request so it will do us no good as we are loading
resources using link and script tags.

If you are curious about which request works with the `route` command you can
use the `whitelist` property of `cy.server` to list them.

```js
cy.server({
  whitelist: request => {
     console.log(request);

     return false;
  };
});

cy.visit('/');
```

The Cypress team are working on a new network stubbing layer that will give us
more control and granularity and that would probably make this task a lot easier
but it still seems to be quite far away from being released.

If you are interested you can find out more in
[Issue 687](https://github.com/cypress-io/cypress/issues/687).

It looks like we will have to build our own command, that will wait for
resources to load. At first, it might be a bit unclear on how to track which
resources are loaded via Javascript, at least it was for me. The idea of using a
Service Worker to track the completion of requests and signal the app via
`postMessage` was floated but seemed a bit too complicated.

We are in luck though, as the new Performance API has functions for measuring
the loading time of different resources, and for us to be able to measure the
time, the resource has to be loaded, right?

Using the `performance.getEntriesByType` function, we will end up with a list of
already loaded resources, such as Javascript and CSS files.

If we continuously query the Performance API we'll know when a resource has been
added to the list and we can continue on with our test case.

With a quick look at the Cypress documentation, we were are able to come up with
a [custom command](https://docs.cypress.io/api/cypress-api/custom-commands.html)
that waits for a resource to load.

```js
function waitForResourceToLoad(fileName, type) {
  const resourceCheckInterval = 40

  return new Cypress.Promise((resolve) => {
    const checkIfResourceHasBeenLoaded = () => {
      const resource = cy
        .state('window')
        .performance.getEntriesByType('resource')
        .filter((entry) => !type || entry.initiatorType === type)
        .find((entry) => entry.name.includes(fileName))

      if (resource) {
        resolve()

        return
      }

      setTimeout(checkIfResourceHasBeenLoaded, resourceCheckInterval)
    }

    checkIfResourceHasBeenLoaded()
  })
}

Cypress.Commands.add('waitForResource', waitForResource)
```

We do a couple of things here that might be worth noting. First, we access the
window object by using `cy.state`. This is due to the nature of the Cypress test
runner. Using the global window object we will be operating on the test runners
window, which won't have the data we need. By accessing it via `cy.state` we are
able to get the applications window object, which lives within an iframe.

As well as a `fileName` of the resource we are waiting for, we also pass a
`type` argument to the function. This is because when you are using Webpack's
dynamic imports to load Javascript, it will use a link tag to preload the
content and this will cause our Promise resolve once the script is preloaded and
not when it's loaded.

Therefore, when we wait for dynamic imports we have to make sure we wait for the
resource initiated by the script tag.

```js
cy.waitForResourceToLoad('dynamicly-loaded-bundle.js', 'script')
```

We can also use this command to wait for CSS files whose loading is deferred, to
make sure that all our styles are applied before continuing.

```js
cy.visit('/')
cy.scrollTo(0, 500)

cy.waitForResourceToLoad('below-the-fold.css')
```

With this new command, we were able to replace a lot of arbitrary `cy.wait`
commands from our tests, while making it more reliable.

I would love to know if you found this helpful and what kind of scenarios with
dynamic resource loading you encountered writing Cypress tests for your
application. Please leave a comment below. 😄


Waiting for network resources in Cypress


How do you build a countdown timer for your app that allows you to pause it and
start it again, and design it in such a way it's easy to extend with different
events in the future?

<p data-height="265" data-theme-id="light" data-slug-hash="qQqbOa" data-default-tab="result" data-user="Artmann" data-pen-title=" Countdown Timer" class="codepen">See the Pen <a href="https://codepen.io/Artmann/pen/qQqbOa/"> Countdown Timer</a> by Christoffer Artmann (<a href="https://codepen.io/Artmann">@Artmann</a>) on <a href="https://codepen.io">CodePen</a>.</p>
<script async src="https://static.codepen.io/assets/embed/ei.js"></script>

The simplest approach I can imagine is to save the time the user clicked the
start button, then use `setInterval` to continuously update the label.

```js
const duration = 10
let startTime

const label = document.querySelector('.time')

document.querySelector('button').addEventListener('click', () => {
  startTime = Date.now()

  setInterval(() => {
    const t = Math.ceil(duration - (Date.now() - startTime) / 1000)
    label.innerHTML = Math.max(0, t)
  }, 200)
})
```

This solution works well but if we want to expand on our timer like adding the
ability to pause the countdown, for example, we will quickly see that this
approach has a lot of limitations.

The other thing that bugs me about this approach is the use of `setInterval`. I
used an arbitrary interval of 200 milliseconds here, and this value will always
we a compromise.

To increase the accuracy of our timer, we want that value to be as low as
possible, setting it to zero would be awesome as it would be executed on the
next run of the event loop. But as we lower the value we also negatively impact
the performance of our page.

Fortunately for us, there is another function we can use and it's.
**window.requestAnimationFrame**. As the name implies it's primary use is to
give you a callback that you can use for animations. After calling
`requstAnimationFrame` with a callback, the next time the browser wants to do a
repaint it will run your callback before it continues to the repaint. This is
perfect when we want to do to animations that feels really smooth at a higher
framerate. The added bonus is that calls to `requestAnimationFrame` are paused
in most browsers when running in background tabs or hidden Iframes in order to
improve performance and battery life.

So now we have a better way to handle the timing, but we still need a more
stable approach to keep track of the elapsed time. What we can do is that every
time we run our function, we calculate the time since the last time we ran it.
This is usually called the **Delta time**. Then at every iteration, we aggregate
the delta time with all the previous delta times.

```js
const elapsed = 0
const lastTimestamp = 0

const tick = () => {
  const timestamp = Date.now()
  const deltaTime = timestamp - lastTimestamp
  lastTimestamp = timestamp

  elapsed += deltaTime / 1000

  window.requestAnimationFrame(tick)
}

tick()
```

Now it's super easy for us to control if the timer should run or not.

```js
if (isActive) {
  elapsed += deltaTime / 1000
}
```

We also have a good place to hook in when we want to update the DOM.

```js
const label = document.querySelector('.time');
const onTick = time => {
	label.innerHTML = Math.ceil(time);
}

...

if (isActive) {
	elapsed += deltaTime / 1000;
	const time = Math.max(duration - elapsed, 0);
	onTick(time);
}
```

Adding all the pieces together and encapsulating it in a class, it looks
something like this.

<p data-height="265" data-theme-id="light" data-slug-hash="qQqbOa" data-default-tab="js" data-user="Artmann" data-pen-title=" Countdown Timer" class="codepen">See the Pen <a href="https://codepen.io/Artmann/pen/qQqbOa/"> Countdown Timer</a> by Christoffer Artmann (<a href="https://codepen.io/Artmann">@Artmann</a>) on <a href="https://codepen.io">CodePen</a>.</p>
<script async src="https://static.codepen.io/assets/embed/ei.js"></script>

If you have any questions or found this helpful, please leave a comment below!
😃 👋


Building a Javascript Countdown Timer


We recently decided to use [Tailwind CSS](https://tailwindcss.com/) for our
Ember app at work and it really struck a chord with me. That's why I decided to
try it in Ruby on Rails.

As you are here you are probably already hyped to get started with Tailwind CSS
in your Rails app but if you still need convincing A wrote Adam Wathan about it,
[CSS Utility Classes and "Separation of Concerns](https://adamwathan.me/css-utility-classes-and-separation-of-concerns/).

If you want to create a new app you can pass the `--webpack` option as of Rails
5.1

```shell
rails new myapp --webpack
```

Otherwise just add the _webpacker_ gem.

```ruby
# Gemfile
gem 'webpacker', '~> 3.0'

bundle
bundle exec rails webpacker:install
```

Then install `autoprefixer` and `tailwindcss`

```shell
yarn add --dev autoprefixer tailwindcss
```

Webpacker lives in `app/javascript` as default. Lets create some new folders
there to keep things organized and create the default tailwind configuration
file.

```shell
mkdir -p app/javascript/src app/javascript/styles

node_modules/.bin/tailwind init app/javascript/src/tailwind.js
```

Then we add the tailwind config to `application.css`. You can find it at
<https://tailwindcss.com/docs/installation>

```css
# app/javascript/styles/application.css

@tailwind base;

@tailwind components;

@tailwind utilities;
```

Now we need to add our post css plugins to webpacker.

```yml
# .postcssrc.yml

plugins:
  postcss-import: {}
  postcss-cssnext: {}
  autoprefixer: {}
  tailwindcss: './app/javascript/src/tailwind.js'
```

And add our new folders to `resolved_paths` in `webpacker.yml`.

```yml
# config/webpacker.yml

resolved_paths: ['app/javascript/src', 'app/javascript/styles']
```

Import the css file in webpackers entrypoint.

```js
// app/javascript/packs/application.js

import 'application.css'
```

And then link to the new files

```erb
# app/views/layouts/application.html.erb

<%= javascript_pack_tag 'application' %>
<%= stylesheet_pack_tag 'application' %>
```

## Heroku

If you are running your app on Heroku you'll have to adjust some settings to
make it work with Webpacker and Tailwind.

First of, with later versions of Webpacker you'll have to add the Node buildpack
and then the ruby one.

```shell
heroku buildpacks:clear
heroku buildpacks:set heroku/nodejs
heroku buildpacks:add heroku/ruby
```

Then you'll have to update the config var `YARN_PRODUCTION` to `false`.

That's it, folks. You can now use Tailwind CSS classes in your markup.

You can find a reference app at
<https://github.com/artmann/rails-tailwind-example>


Adding Tailwind CSS to Your Rails App


When switching between languages I often find my self Googling on how to do
string concatenation and especially interpolation which no two languages seems
to agree on.

For future reference, Here's how you do it.

## C

In C, strings are really just plain `char` arrays. Therefore, you can't directly
concatenate them with other strings.

You can use the `strcat` function, which appends the string pointed to by `src`
to the end of the string pointed to by `dest`:

```c
char *strcat(char *dest, const char *src);
```

## C++

C++ has `std::string` which is used instead of `char` arrays.

```
string a = "Hello ";
string b = "World";
string c = a + b;
```

## C&#35;

C# lets you use the `+` operator to concatenate strings.

```cpp
string name = "Chris";
Console.WriteLine("Hello " + name);
```

It also allows for interpolation.

```
string firstName = "Sally";
string lastName = "Morgan";

Console.WriteLine($"Hello {firstName} {lastName}");
```

## Go

You can use the `+` operator to concatenate strings in Go.

```go
firtName := "James"
lastName := "Pierce"

fmt.Println(firstName + " " + lastName)
```

There's also `fmt.Sprintf` which lets you format strings.

```go
firtName := "Denise"
lastName := "Richards"

fullName = fmt.Sprintf("%s %s", firstName, lastName)
```

Strings are read-only in Go so a new object is generated every time you
concatenate two strings. If this becomes a problem you can use `bytes.buffer`.

```go
var buffer bytes.Buffer

buffer.WriteString("Hello")
buffer.WriteString(" ")
buffer.WriteString("World")

fmt.Println(buffer.String())
```

## Java

Java also uses the `+` operator to concatenate strings.

```java
String name = "Molly";

System.out.println("Hello " + name);
```

## Javascript

Javascript uses the `+` operator to concatenate strings.

```js
let firstName = 'Isabela'
let lastName = 'Wang'

console.log(firstName + ' ' + lastName)
```

You can also interpolate strings with backticks.

```js
let firstName = 'Megan'
let lastName = 'Fox'

console.log(`Hello ${firstName} ${lastName}`)
```

## PHP

PHP uses `.` to concatenate strings.

```php
$firstName = 'Lisa';
$lastName = 'Swan';

echo $firstname . ' ' . $lastName;
```

Only variables can be interpolated.

```php
$name = 'Michelle';

echo "Hello {$name}";
```

## Ruby

Ruby uses the `+` operator to concatenate strings.

```ruby
fist_name = 'Tyler'
last_name = 'Reed'

puts fist_name + ' ' + last_name
```

And it uses `#{}` for interpolation

```ruby
name = 'Sarah'

puts "Hello #{name}"
```

## Python

Python uses the `+` operator to concatenate strings.

```python
firstName = "Emma"
lastName = "Stone"

print(firstName + " " + lastName)
```

And from version 3.6 you can interpolate strings.

```python
name = "Sally"

print(f"Hello {name}")
```


String Concatenation Cheat Sheet


```js
// trucks/controller.js

import Ember from "ember";

export default Ember.Controller.extend({
  trucks: [
    { name: "truck 1", inUse: false },
    { name: "truck 2", inUse: true },
  ],

  actions: {
    changeTruck(truck, inUse) {
      Ember.set(truck, "inUse", inUse);
    },
  },
});
```

```
// ddau-checkbox/component.js

import Ember from 'ember';

export default Ember.Component.extend({
  tagName: 'input',
  attributeBindings: ['checked', 'type'],
  type: 'checkbox',
  change() {
    if (this.attrs['on-change']) {
      let checked = this.$().is(':checked');
      this.attrs['on-change'](checked);
    }
   }
});
```

```
// trucks/template.hbs
{{#each trucks as |truck|}}
  <table>
    <tbody>
      <tr>
        <td>{{truck.name}}</td>
        <td>
          {{ddau-checkbox checked=truck.inUse on-change=(action 'changeTruck' truck)}}
        </td>
      </tr>
    </tbody>
  </table>
{{/each}}
```


Curry actions from DDAU Checbox component


Allowing your users to upload images to your application is not an unusual feature but I had to pull some of my hair before I found an approach I liked when trying to do it with Ember.

At first we need a component for the file-input as there is no built-in view for this yet.

```js
App.InputFileComponent = Ember.Component.extend({
  attributeBindings: ['multiple', 'type'],
  tagName: 'input',
  type: 'file',
  multiple: true,
  files: null,
});
```

Then can use it in our template like this

```js
{{input-file files=files}}
```

And files is the property we are going to use to store our files.
Then we want something to happen when the user chooses which files to upload. We can do this by listening to the change event and populate our array with the files uploaded

```js
change: function(event) {
  var files = event.target.files;
  for (var i = 0; i < files.length; i++) {
    var file = files.item(i);
    this.get('files').pushObject(file);
  }
}
```

We can now render our files on the page.

```js
<ul>
{{#each file in files}}
  {{file.name}}
{{/each}}
</ul>

{{input-file files=files}}
```

But displaying just the filename is a bit boring, is it not? As luck would have it, thanks to components it won’t be too hard to show a preview of the image next to the name. If we remove the list item from our template and replace it with a component. We can do something like this.

```js
<ul>
{{#each file in files}}
  {{image-preview file=file}}
{{/each}}
</ul>
{{input-file files=files}}
```

By creating a image preview component we can use the FileReader class to read our image data and bind it to a img-tag

```js
App.ImagePreviewComponent = Ember.Component.extend({
  tagName: 'li',
  file: null,

   didInsertElement: function () {
     var self = this;
     var file = this.get('file');
     var reader = new FileReader();
     reader.onload = function(e) {
       var data = e.target.result;
       self.$("img.preview").attr("src", data);
     };
     reader.readAsDataURL(file);
   },
});
```


Image uploads with Ember.js


Apache vs Nginx. Passenger vs Unicorn vs Puma. I’ve personally been running
Apache with Passenger as I got a lot more of Apache experience then with Nginx
but when setting up the servers for a recent Rails project I was not really
happy about the number of requests I could serve.

The test site is running on Digital Ocean $10 servers which yield the following
specs

- 1GB Memory
- 1 CPU Core
- SSD Drives

I use one server for the database, one with Apache + Passenger and one with
Nginx + Puma. Then I used another server with some more power behind it to run
Apache Benchmark with a conccurency level between 10 and 500.

I bashed the servers with 200, 1000, 5000, 10000 requests to measure number of
request per seconds it could handle and the mean response time.

## Requests per second

![request per secod](http://i.imgur.com/Z6V8S1O.jpg)

## Mean response time

![Mean response time](http://i.imgur.com/Z6V8S1O.jpg)

So it seems when it comes to Passenger vs Puma it seems like Puma is the way to
go.


Benchmarking Rails Server Software


## Open source is great

The value of open source development has reached even greater spread and
hopefully this will lead to additional exchange of knowledge.

## Love your ecosystems

Having a community around your product and then most importantly, have a product
which allows your community to extend and modify it for their own personal
needs.

## Big data will get even bigger

Big data has been the thing to talk about for a while now and it’s still growing
and recent analysis shows that by 2020 the amount of storage needed will be
around 40 exabytes, that would equal about 85 million years of HD video. Seagate
presented that they needed to innovate and move away from their classical disk
manufacturing and the current way of building SANs. When they presented their
new Kinetic disks they showed that they really have started to innovate and are
building disks for object storage that can communicate over Ethernet.

## Detach your resources

We have been moving our storage out from our servers for quit a while now and
Intel presented that they want to do the same with the rest of our system
resources. Using fiber optics they want to move memory and CPU out of the
servers and into a rack level.

## Arm enters the data center

AMD was present to talk about their new investment into Arm processor wanting to
create CPUs for specific tasks like video rendering and data analytics.

## Microsoft impresses

With their new concept, Cloud OS which is based on Windows server and Azure pack
among others and lets you build and move between public and private clouds and
alot of other cool features.

## Learn to love your orchestration layer

While automated deployment and provisioning continue to grow and PaaS and SaaS
are getting more popular the demand for on-demand infrastructure will increase.

## Focus on the things you are good at and do them better

Identify the parts of your business that you do the best, focus on these and
partner up with top actors in your edge areas.
