Responsive

Applying functional programming design principals to server architecture design

, , , No Comments

It occurred to me this morning that there are actually quite a few parallels between functional programming and infrastructure design and management.

It all started by what I realized that I said while talking about environments: Production is meant to go from one stable, working, vetted version of code to another stable, working, vetted version of code. Any state between those two is invalid and should (preferably) never occur.

If you cycle on that again, you start to see that most deployment processes you know about violate this One Basic Rule(tm).

I posit that if you are deploying new code to currently running hosts that are handling traffic, you are doing it wrong.

Think about it like this: what is the one core feature of every highly scalable functional programming language? Every one has (or has developed patterns which essentially create) immutable values.

So when we scale this out of software and apply it to infrastructure, your code is the value of your server. If you are changing the value of your server while other processes are trying to access it, you're going to run into concurrency issues. Ask any developer about sharing data between threads, and they'll quickly tell you it's difficult. Why, then, do we improperly share data between releases of our software?

The simple answer is that you have two options for atomic deployments that follow the rules of immutability:

  1. Drop the servers you are deploying to out of the flow of traffic. This is the easiest, but still fails to honor the spirit of immutability because the value of the server is still changing, it's just changing while nobody is looking.
  2. Spin up new instances, and slowly work them into live traffic, confirming along the way that you are in fact getting the expected behavior out of the code.

Now, I know this is all hand-wavy because it glosses over the important aspect of data migration: I don't have an answer there, yet. I suspect the true answer to that part of the solution would be something to the effect of being able to seamlessly decouple your entire system from write traffic (using a request proxy which could 'pause' calls) for some period of time while data updates are done.

What if, to create a truly fault tolerant design, you simply create a nearly 100% asynchronous  API. All requests come in and go into a process queue, and are handled from there. This way you are never required to turn off traffic to do an atomic update of your software because you can simply tell it to stop processing while the update progresses.

Thoughts?

Why developers outside of Symfony should care about Symfony Live

, , , , , , , , No Comments

If you haven't checked them out already, go to Symfony's "Talks" section.

Now, this is great for all of us Symfony developers, but it's also a good thing for php developers in general.

If you're a Symfony developer already, you know what you're interested in there, so I'm going to focus on what non-symfony developers can get out of this treasure trove. Also, these videos are also available in French through the talks section.

Talks that apply to everyone

Designing HTTP Interfaces and RESTful Web Services -- David Zuelke gives an excellent presentation on what restful web interfaces mean, and was actually the driving inspiration behind my dedicating my Symfony Live hack day project to the Accept Header Service Provider for Silex, as well as this pull request for the Symfony core.

Talks for programmers

Behat by example (Behat best practices) -- Konstantin Kudryashov walks you through how to do approach BDD in a way that makes sense. I haven't watched it yet myself, but it is definitely on my list.

Symfony2 components to the rescue of your PHP projects -- Xavier Lacot goes over how you can use symfony components in your every-day php projects to make your life easier.

Using MongoDB responsibly -- Jeremy Mikola gives a talk about Mongo DB. Really, who's surprised? I haven't seen it, but it's on my list, and I'm sure, knowing Jeremy, that it is "web scale."

PHP developers, what can Postgresql do for you? -- Grégoire Hubert gives a talk about Postgresql, why you should use it, and what advantages it has in store for your next project.

ORMs don't kill your database, developers do! -- Guilherme Blanco shows you some ways to optimize your setup when dealing with an ORM. I've heard there is some controversy on some suggestions within, but I think that just makes it juicer.

Dependency Management with Composer -- If this is anything like his talk in San Francisco (and I'll just go ahead and blindly assume so!), Jordi Boggiano gives an excellent overview of what you can do with Composer and how to take advantage of it right away.

Talks for frontend developers

How we built the new responsive BBC News site -- Really. Need I say more?

twig.js: The Templating Engine for the Client-Side -- Johannes Schmitt gives a talk about the very interesting twig.js javascript templating library. I seriously need to look at this one as well.

Still need more?

Richard Miller gave a talk on what you get from a full stack framework. I haven't watch this, as I have already drank that particular kool-aid, but if you haven't made the leap yet, I'm sure he presents some compelling arguments. If, after it, you're still not sold on full stack frameworks, just wait until Dustin Whittle's Silex talk from San Francisco is up. It will blow. Your. Mind.

How to build truly responsive images

, , , , 2 Comments , , , , ,

UPDATE: it looks like Scott Jehl has already beaten me to the punch, so check out his github project!

So, I was almost asleep, and this idea popped into my head. I want to write it down for two reasons:

  1. So I don't forget it.
  2. To see if anyone else agrees, disagrees, or sees any flaws in the idea.
Basically, I think I have figured out how to make images ridiculously responsive
  1. in a syntax that is logical and 
  2. in a way that can be powered by javascript and 
  3. fails gracefully to non-javascript supporting clients
The code starts out as simple as:
<image data-alt="Some image" data-width="300px" data-height="300px"
  id="my_image" class="some_class">
 
  <source src="/images/high-dpi/image.jpg"
    media="screen and (-webkit-device-pixel-ratio: 2.0)" />
  <source src="/images/print-dpi/image.jpg" media="print" />
  <source src="/images/regular-dpi/image.jpg" />
  <img src="/images/regular-dpi/image.jpg" width="300"
    height="300" alt="Some image" />
</image>

With no javascript, nothing but the <img> tag is displayed, and everything is happy.

With javascript, we run a system which turns it into the following (this becomes easier if we can evaluate media queries in JS, but I'm not sure if we can do that, so I'm showing an alternate way):

<style>
  #my_image {
    background-image: url('/images/regular-dpi/image.jpg');
    background-repeat: no-repeat;
    background-size: 300px 300px;
  }
  @media print {
    #my_image { 
      background-image: url('/images/print-dpi/image.jpg');
    }
  }
  @media screen and (-webkit-device-pixel-ratio: 2.0) {
    #my_image {
      background-image: url('/images/high-dpi/image.jpg');
    }
  }
</style>
<image data-alt="Some image" data-width="300px" data-height="300px"
  id="my_image" style="width: 300px; height: 300px;">
</image>

And now for the fun part - we can use document.getElementById('my_image').style.backgroundImage to get the right image!

This means that the last and final step then turns into:

<image data-alt="Some image" data-width="300px" data-height="300px" id="my_image">
  <img style="width: 300px; height: 300px;" src="/images/high-dpi/image.jpg"
    alt="Some image" width="300" height="300" />
</image>

Which should make it happy with screen readers and other similar systems.

This approach has a few distinct advantages:

  1. It leverages existing tools for defining when to load a particular image (media queries)
  2. It provides a graceful fallback for no javascript support
  3. It (hopefully) will be relatively close to whatever is selected for moving forward in a browser integrated solution, as it fits with the patterns already established.

So that's it. That's my master plan. What do you think?