
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, buckle up,
because I'm about to explain why that's not 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 here's the twist: 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.
