Ben Edmunds

AI Skills Are the New Platform Interface

Thu, 02 Apr 2026 00:00:00 +0000

An evolving idea I’m working through is that developer portals like Backstage and Port are becoming obsolete. They solved a real problem. Engineers needed one place to find services, templates, and docs. But a portal is just a website. It’s passive. It shows you things and gives you forms. The developer still has to leave their editor, open a browser, find the right page, and click through a workflow. That’s a lot of ceremony for someone who just wants to check who owns a service.

AI skills skip all of that. A skill connected to your service catalog via MCP can answer “what depends on the payments API?” without anyone opening a tab. A skill that knows your Terraform modules can scaffold infrastructure, apply your org’s naming conventions and compliance guardrails, and hand back real code. For new services, we still use cookiecutter templates to keep things deterministic. But the skill knows which template to use and how to run it.

Your engineers already live in their CLI. Meet them there.

The Platform Hierarchy of Needs

Sun, 01 Mar 2026 00:00:00 +0000

Every platform team I’ve talked to wants to build a portal. A developer portal with a service catalog, self-service provisioning, and change management workflows. It’s the slick stuff. It’s also the last thing you should build.

Platforms evolve in layers. Each layer builds on the one below it. Skip a layer and you end up with a portal that provisions services into infrastructure nobody can observe, deployed through pipelines nobody trusts. You’re stacking bricks on sand.

I think about this as a platform hierarchy of needs. Just like Maslow’s hierarchy, you can’t meaningfully work on the higher levels until the lower ones are solid. Here’s what it looks like:

At the base you have the fundamentals. Your workloads run in the cloud. Secrets are managed, not hardcoded. Environments are isolated. You have basic APM so you can see when things are broken. Incident management exists as a process, not just someone pinging a Slack channel. Deployments are automated, even if they’re simple. This is the floor. Without this, nothing above it matters.

The next layer up is where things start getting real. Infrastructure as code so you’re not clicking around in consoles. Observability beyond just “is it up?” to actual structured logs, metrics, and traces. Teams own their own incidents instead of throwing everything over the wall to an SRE team. Zero-downtime deployments so shipping code doesn’t mean taking a hit.

Then you mature those foundations. IaC goes from “we have some Terraform” to full coverage with zero clickops. Monitoring becomes proactive instead of reactive. You move from automated deployments to true continuous delivery. And you start showing teams what their infrastructure costs. Not charging them yet, just making the numbers visible. Cost showback changes behavior all by itself.

Once that’s solid, you can start getting sophisticated. Auto-scaling that actually works. Service discovery so services find each other without hardcoded endpoints. Canary and blue-green deployments for safer rollouts. Cost chargeback so teams have real skin in the game on spending.

Higher still, you get traffic shaping, ephemeral environments for testing, and advanced deployment strategies. These are genuinely powerful capabilities. But they’re useless if your teams can’t even see what’s running in production or if your IaC only covers half your infrastructure.

Near the top, platform abstractions and shared libraries let you encode all those lower layers into reusable building blocks. A team spins up a new service and gets observability, deployment pipelines, auto-scaling, and cost tracking for free. This is where the platform really starts compounding.

And finally, at the peak: the portal and change management. Now you have something worth putting a UI in front of. The portal works because every layer beneath it is solid. Change management works because you have the observability, the deployment safety, and the cost visibility to actually understand the impact of changes.

The failure mode is always the same. A team reads a blog post about Backstage, gets excited, and starts building a developer portal when they still have services with no observability and deployments that require SSH access. It’s not that the portal is a bad idea. It’s that it’s a bad idea right now.

Each layer in this hierarchy enables the next one. You can’t do meaningful cost chargeback if you don’t have cost showback first. You can’t do canary deployments if you don’t have zero-downtime deployments figured out. You can’t build useful platform abstractions if the underlying capabilities are half-baked.

The good news is you don’t need to finish each layer perfectly before moving up. You need it solid enough. IaC covering 90% of your infrastructure? Good enough to start thinking about proactive monitoring. Observability in place for your critical services? Start experimenting with canary deployments. It’s not a strict gate, it’s a foundation that needs to bear weight.

Build the base. Stack the bricks. Resist the urge to jump to the top of the pyramid. The portal will be there when you’re ready for it.

Platform Engineering Isn't a Portal

Mon, 16 Feb 2026 00:00:00 +0000

Every company eventually builds an internal developer platform. The mistake most teams make is building the wrong one for their size.

At a 50-person company you don’t need a portal. You don’t need a service catalog. You need to stop making every team solve the same damn problems over and over again. Rate limiting, auth, deployment pipelines. These things should be solved once and pushed into the platform so product teams never think about them.

Early stage platform engineering is about opinionated abstractions. You pick the right defaults, bake them in, and let teams ship features instead of configuring load balancers. The whole point is that a developer starting a new service shouldn’t have to care how auth works or how deploys get rolled out. They just write code and it works. That’s the platform doing its job.

This only works if you’re willing to be opinionated. A platform that gives you twelve options for deployment is not a platform. It’s a burden. At this stage, fewer choices means faster teams. You’re trading flexibility for velocity, and that’s the right trade when you have more problems than people.

Then you grow. You hit a few hundred engineers, maybe more. Teams start bumping into the edges of those nice abstractions. Someone needs a custom deployment strategy for a ML pipeline. Another team needs fine-grained control over rate limiting because their traffic patterns are weird. The opinionated defaults that got you here start feeling like constraints.

This is where the platform evolves. You still keep the abstractions. They’re still the happy path and most teams should use them. But now you layer on tooling that lets teams pierce those abstractions when they have a real reason to. Developer portals like Backstage start making sense because you actually have enough services and teams to need a catalog. Code generation tooling helps enforce patterns across a bigger surface area. More automation fills the gaps that humans used to cover when the company was small.

The later stage platform is everything the early one was plus off-ramps. The defaults still exist. Most teams still use them. But the teams with unique needs can dig in, customize, and own their own complexity without blowing up everyone else’s experience.

The common failure mode is building the later stage platform too early. I’ve watched small companies spend months setting up Backstage when they have fifteen services and three teams. That’s not platform engineering. That’s premature optimization. Start with strong opinions. Solve the boring problems well. You’ll know when it’s time to add the portal and the off-ramps because teams will be actively fighting your abstractions. Until then, keep it simple and keep shipping.

Testing Microservices Without Cloning the World

Mon, 29 Sep 2025 00:00:00 +0000

Shared staging environments are a lie we all agree to believe. Developers need to deploy broken code to test it. Other developers need that same environment to not be broken. You can’t have both, and yet every company tries.

This is one of those problems that seems simple until you actually have microservices. With a monolith, you spin up a review app and you’re done. With dozens of services talking over HTTP, gRPC, and message queues, testing one service in isolation tells you almost nothing. Your feature touches three services and a background worker. A single-service review app is useless.

The obvious fix is cloning the whole environment. Just copy everything for each feature branch. Except that’s absurdly expensive and slow when “everything” means your entire infrastructure. Nobody’s doing that at scale.

Mocking is the other trap. It feels productive because your tests pass, but your mocks drift from reality over time. You end up with green CI and broken production. False confidence is worse than no confidence because at least with no confidence you test manually before shipping.

The Real Problem Is Partial Isolation

What you actually need is a way to route traffic to your changed services while everything else falls back to stable staging. You want isolation where it matters and shared infrastructure everywhere else.

At SeatGeek we built Ephie to solve exactly this. The core idea is DNS-based routing. Services in your ephie environment resolve DNS within their own namespace first. If the service exists there, traffic stays local. If it doesn’t, DNS falls back to stable staging. Simple concept, and it actually works.

But HTTP routing only gets you halfway. When services communicate through RabbitMQ, you can’t just redirect DNS. You need isolated message brokers too. And if you spin up workers against a shared database without thinking about it, those workers start competing with staging workers for the same jobs. So Ephie handles that by scaling worker replicas to zero when resources aren’t isolated, and optionally spinning up dedicated RabbitMQ clusters and Postgres databases per environment.

What Developers Actually See

Developers don’t care about DNS routing or namespace resolution. They care about “can I test my thing.” Ephie gives them an interactive CLI where they pick which services to test, choose a branch or MR for each, and optionally toggle on isolated databases or message brokers. The Postgres databases restore from weekly snapshots and spin up in under a minute. Slack notifications ping when your environment is ready. Datadog dashboards show you what’s happening inside it.

Average startup time is just over three minutes. At peak we had 75 monthly active users (engineers) running 70 concurrent environments. Teams that used to wait days for a test cycle on shared staging cut that time dramatically. The inventory team was one of the loudest advocates because their workflows touched so many services that shared staging was basically unusable for them.

The Part That Mattered Most

The strongest signal that Ephie worked wasn’t the usage numbers. It was that teams actively campaigned for continued investment in it. When engineers go out of their way to tell leadership “keep funding this tool,” that’s about as clear a signal as you’ll get in platform engineering.

Check out the full technical details on the SeatGeek blog: Ephie: Ephemeral Environments at SeatGeek. That post covers the Kubernetes architecture, DNS resolution chain, CloudNativePG setup, and all the implementation specifics.

Rearchitecting CI at SeatGeek

Tue, 21 Jan 2025 00:00:00 +0000

Our CI runners were slowly ruining everyone’s day. Shared, stateful hosts where one team’s build could poison the environment for the next team. Classic noisy neighbor problem, except at the infrastructure layer where it’s way harder to figure out what went wrong.

We had about 80 hosts on weekdays, 10 on weekends. Fixed scaling. Peak hours meant developers sat in queue. Off-peak meant machines sat idle burning money. We were paying for capacity we weren’t using and still didn’t have enough when it actually mattered.

Container builds made it worse. Tightly coupled to EC2 hosts with local Docker daemons. Settings persisted between builds, so one team’s config could quietly break the next team’s image build. Multi-arch images required emulation that absolutely destroyed build times. The whole thing was brittle and nobody trusted it.

600 Repos Can’t Flip a Switch

We had over 600 repositories on this infrastructure. You don’t just migrate that over a weekend.

We ran a four-phase rollout. Started with our own platform team repos so we ate our own dogfood first. Expanded to other platform-owned repos. Updated the shared CI jobs. Then automated the long tail with multi-gitter across hundreds of repos. Each phase surfaced problems we could fix before the blast radius got bigger. That phasing is the only reason we pulled this off without pissing everyone off.

Autoscaling CI Is Harder Than You Think

This is the part nobody warns you about. Autoscaling CI infrastructure sounds straightforward until you actually try it.

You need the right metric. We used saturation: the ratio of pending and running jobs to available slots. Most default metrics don’t capture the developer experience of staring at a queue. You need graceful shutdowns because Buildkit will just kill your build mid-way on SIGTERM if you let it. And you need capacity reservation so that scaling up doesn’t mean waiting five minutes for a node to come online. We over-provisioned with low-priority pods that pre-pulled common images, then got evicted when real work showed up.

None of these are individually hard. Together they’re a real engineering problem.

What We Built

Kubernetes with ephemeral pods. Every CI job gets its own isolated pod that’s destroyed when the job finishes. No state leaking between builds. No noisy neighbors. Clean slate every time.

For container builds, we deployed Buildkit as Kubernetes deployments connected via remote driver. Completely decoupled from the CI hosts. No more shared Docker daemons.

The Numbers

Average queue time dropped from 16 seconds to 2. The p98 went from over 3 minutes to under 4 seconds. Cost per job down 40%. Concurrent job capacity doubled. And zero state pollution between builds.

Go Read the Technical Posts

We wrote a three-part series on the SeatGeek blog with the full technical details:

Part 1: Rearchitecture covers the architecture decisions, the Kubernetes executor setup, and the migration strategy across all those repos.

Part 2: Building Containers with Buildkit covers how we replaced local Docker daemons with remote Buildkit deployments and all the fun edge cases that came with it.

Part 3: Optimizations covers autoscaling, caching, NVMe storage, and the performance work that got us to those final numbers.

If you’re running shared CI infrastructure and feeling the pain, start with Part 1. The problems will sound familiar.

Onboarding New Developers to a Legacy Codebase

Sun, 15 Apr 2018 00:00:00 +0000

I’ve ran into an issue recently that hopefully can help you. I’ve been freelancing for a non-profit that has several products that have been in development for years. One of these codebases in particular is pretty huge and verbose, with many different developers touching it over several years.

The biggest issue we’ve all faced with onboarding to this project has been converting what the business stakeholders are asking for, into scoped requirements and code that handles all of the edges and complexity presented by this large (mostly undocumented) codebase.

We’ve implemented a process, that I’ve used successfully in the past when I was onboarding freelancers for my projects, and it’s going pretty well. What I’m doing is first developing a rough, minimal, implementation of the feature that’s requested and then submitting that for review to technical and business stakeholders to review and then discuss. This is often an intermediate pull request as soon as enough code to cover the basics of the implementation is ready.

This gives us all an example to review together to be sure we’re on the same page. Then once we work out the correct scope, based on this example, I’ll develop the full feature.

Reach out if you’d like to discuss this more, I’d love to hear your thoughts.

Evaluating Contractors

Wed, 16 Aug 2017 00:00:00 +0000

A question was recently posed to a CTO mailing list I’m a part of as to evaluating contractors. The poster was looking at frontend web development contractors and trying to determine the best way to evaluate them. In case you find yourself in a similar situation, here is my (slightly edited) response:

OP,

I’ve done several types of evaluations. I’ve found that the two below seem to work best for me.

I greatly prefer using real world issues. I usually setup a small agreement (4-8 hour contract) with appropriate NDAs. It ensures the contractor receives value for their time and gives me a good feel for how their work will be. I’ll then have the contractor work a real issue/ticket we have open on the system they’ll be working with. Just make sure to include time for them to get setup with their local development environment along with appropriate instructions.
If that’s not possible, I’d recommend having them do a sample project thats similar to your core stack. Although exact frameworks and libraries wouldn’t be a concern for me. I’ll usually have someone create something simple, a guitar tab site is a fun favorite of mine, and dictate one or two tools. Then I’ll let them decide the rest. I find that seeing how someone architects a project with a lot of decisions left up to them tells you much more than having them follow an exact spec.

Hit me up on Twitter, I’d love to hear your thoughts.

CodeIgniter 4 Overview - It's really not dead!

Tue, 08 Aug 2017 00:00:00 +0000

I’ve been getting excited about and have started talking about CodeIgniter 4 a lot more recently. Several people have asked “that isn’t dead yet”, “why”, or similar questions so I’m going to give a high level overview of the what and why of CodeIgniter 4.

I’ll be speaking just of my personal opinions and will do my best not to misrepresent my fellow CodeIgniter Council members who have by far done the majority of the hard work with the development of version 4.

Let’s start with some context around CodeIgniter

The general ethos around CodeIgniter, both as a community and as a framework, has always been to “get shit done”. People are drawn to CodeIgniter for a variety of reasons. IMHO the main draws are it’s relatively short learning curve, stable API, lack of opinion about how you code, and the way the community celebrates shipping over perfection.

This served the community well for good a while but over time the apprehension towards breaking backwards compatibility and general neglect by previous maintainers caused it’s community to slowly dissipate. It was hard to get excited about starting a project with CodeIgniter when it hadn’t been updated to support any of the enhancements to PHP from the past decade and didn’t even play well with others.

Around the same time as CodeIgniter was fizzling, Laravel came on the scene (I’m personally a big fan of Laravel by the way). A lot of the CodeIgniter community moved to Laravel 4 once it was released. It had a very simple architecture and followed a similar design philosophy to what we were used to.

This resulted in CodeIgniter stagnating as far as most people were concerned.

Where we are now

A couple years ago CodeIgniter was acquired by The British Columbia Institute of Technology (BCIT) and fully open sourced. This gave the community the opportunity to take control of the development of the framework and started pushing it forward.

With a community driven team in place, version 3 was soon finished and released. Version 3 was an incremental release so development was quickly mapped out for a truly new version of CodeIgniter. This version would have the latest PHP features but still allow you to develop a simple app end to end. Version 4 was born.

Development on version 4 has been slow but very well considered. Release of a public stable version is getting increasingly close, likely to be later this year or early next year (not official).

Why

Now to the real point of this post and what you’re probably here for. Why.

In the current PHP ecosystem, where most frameworks resemble Java more than the PHP of a few years ago I think there’s a real niche in the market for a framework that is quick, simple, and easy to use but still gives you all the power of newer PHP features.

Laravel has moved to version 5, which leaves simple MVC behind for powerful, and complicated, command bus style architecture.

Symfony has continued to evolve and become a bastion of modern PHP and everything that entails. Both good and bad.

Kohana is dead. Yii, all but dead. Etc.

On the plus side. Micro-frameworks have become a ton more popular, Slim and Silex are great tools that I absolutely love. I use Slim almost every day.

The problem with micro-frameworks is that they force you to practically design your own framework from smaller pieces. This can be great for an experienced developer or team. This is absolutely horrible for a new developer or trying to onboard new developers to a large project or simply for getting a project off the ground. I can’t tell you how many times I’ve had an idea for a new app but by the time I picked out all the tools to use and setup the project architecture I was tired of the project and abandoned it.

That’s why I’m really excited about this next version of CodeIgniter. It gives you the simple MVC architecture you’re used to. Basic routing. Real classes without the wild loading things old CI used to do. PSR-4 autoloading. Tests. A full stack, end to end framework, that you can download and immediately see work in your browser. You can edit two files to serve up a static site. Three files to add a new model/view/controller that serve an app.

I have nothing against the other frameworks mentioned. I’m a big fan of them for the right projects and will continue using them. I’m also really excited for CodeIgniter 4. It gives a new developer a great place to start. It gives me a way to get a new app shipped without worrying about what the newest routing library is or how I would architecture at the scale of Facebook. It gives an experienced team an amazing starting place to create an app that’ll be used by tons of users and that they’ll enjoy working with. It’ll get out of your way and let you code.

You can check out the current process on Github at https://github.com/bcit-ci/CodeIgniter4. It’d be awesome if you could contribute.

Hit me up on Twitter, I’d love to hear your thoughts.

CodeIgniter Lives On

Tue, 04 Nov 2014 00:00:00 +0000

I’m sure most of you know that at one time I was heavily involved in the CodeIgniter framework but have not been in quite some time. CodeIgniter stagnated and other frameworks moved in to take it’s place. Namely Slim and Laravel. EllisLab, the company behind CodeIgniter, had lost interest in maintaining the project a long time before they finally annouced that they were looking for a new owner for the framework in July 2013. Luckily for us all, it was recently annouced that the British Columbia Institute of Technology has taken over as the new owner.

With this new owner comes new leadership and a new vision for the future of CodeIgniter. CI will continue to focus on being a simple, lightweight, yet relevant framework for modern PHP developers going forward. It will be community focused and driven by open source. I have joined on to advise on the future direction of the framework as a member of the CodeIgniter Counsel.

I personally still use CodeIgniter in many legacy applications day to day and am very excited that it will continue to be a valid option going forward. Together we can shape CI to be the framework we all wish it was.

I also want to clarify. This does not mean that I’ll stop using Slim, Laravel, Express, etc as needed. I’m a firm believer in using the best tool for the job and will definitely be using CodeIgniter when it’s the right fit. I can’t stress enough how important it is to take a step back when you’re planning a new project and choice the best framework/components/whatever for your needs. Now go make cool shit!

Fixing Homebrew PHP / Apache after Yosemite

Thu, 16 Oct 2014 00:00:00 +0000

Today I upgraded to Yosemite. Played with all the new cool shit. Then tried to get some work done, broken. Everything. Broken.

To explain a bit, Apache wasn’t loading so http://localhost wasn’t loading, let’s walk through the steps I took to fix this in case you’re seeing the same issue.

PHP

First we’ll need to reinstall PHP. Start by running brew update and brew doctor, fix what they recommend:

$ brew update
$ brew doctor

Now for the reinstall, use whatever PHP version and flags you originally installed with. For this example we’ll be doing PHP 5.3 with MySQL and Postgres

$ brew reinstall php53 --with-mysql --with-pgsql --with-apache

At the end of the install process brew will tell you a few commands to run and give you the path to the PHP module. So let’s set PHP 5.3 to load at startup and load it right damn now

$ ln -sfv /usr/local/opt/php53/*.plist ~/Library/LaunchAgents
$ launchctl load ~/Library/LaunchAgents/homebrew.mxcl.php53.plist

In the output we can see that the LoadModule line for the libphp5.so is

LoadModule php5_module    /usr/local/opt/php53/libexec/apache2/libphp5.so

Go ahead and make a note of that LoadModule line.

Apache

If you’re using OSX Apache your httpd.conf has been backed up and a new one is now in place, this will show you all of the files:

$ ls /private/etc/apache2

You should see a httpd.conf and a httpd.conf.pre-update or something similar. The pre-update is your old config, you can find your old paths and any special configs/settings here. I’m assuming you already know the basics of setting up an Apache server.

Now we’re going to update the new httpd.conf with our particular settings, most of which you can grab from the .pre-update file.

Open /private/etc/apache2/httpd.conf in your editor of choice. Update the ServerRoot, DocumentRoot, and any Directory definitions as needed (1), you should be able to copy these from your httpd.conf.pre-update file.

Comment out any existing “LoadModule …. libphp5.so” lines.

At the bottom of the file add the LoadModule line from earlier (2)

LoadModule php5_module /usr/local/lib/libphp5.so

Restart apache

$ sudo apachectl -k restart

Hopefully everything will be good to go now. Watch the output from the apache restart for errors that will help you track down any additional issues.

(1) - My previous SystemRoot didn’t work, I had to use

SystemRoot "/usr"

(2) - I also had to add

AddType application/x-httpd-php .php

Book Review - Integrating Frontend Components with Web Applications

Wed, 16 Jul 2014 00:00:00 +0000

I recently had the pleasure of receiving an early copy of Integrating Frontend Components with Web Applications by Maks Surguy.

What’s it cover

This book has excellent content explained in a thorough, yet really engaging manner. It covers a wide array of common frontend components including

Integrating Twitter Bootstrap
Tagging
Notifications and Alerts
Spinners
Auto-Completing Search
AJAX Login and Registration
AJAX file Uploads
Avatar Cropping
Date Pickers

Thoughts

I really enjoyed reading this book. I have been doing a large amount for frontend work for years now and I even learned several things from this book. I especially liked that Maks made no assumptions as to the existing knowledge of the reader. Junior all the way through Senior developers will find something for them in this material.

The diagrams and visuals throughout really distinguish this book IMHO. I would be surprised if there are any concepts covered that someone isn’t able to easily follow and understand. It’s hard to even express how clear and concise things are conveyed here, check out the sample chapter on Leanpub to see what I mean.

BTW - I’ve never seen Parsley before and it looks like a kick ass validation library. I’ll definitely be using this in future projects.

Criticisms

My only criticism is the reliance on Laravel and jQuery for many of the examples. I completely understand the constraints an author is under though, you have to keep the examples succinct while still getting the point across, so overall I think Maks found a great balance between generalities and specifics.

I totally recommend this book without any reservations. This is money well spent. You’ll learn a ton.

I’ll be personally recommending this to anyone that is starting to learn frontend development, or hell, even just someone that wants a guidebook on how to handle the most commonly asked for frontend components.

Want it?

You can purchase the book through Leanpub: Buy it here.

The price is discounted to $19.99 through July 23rd, after that it goes it goes up to $29.99 so grab it now to save a good bit.

Advanced CSRF Usage in PHP

Sun, 11 May 2014 00:00:00 +0000

This expands on my post, Securing against Cross Site Request Forgery (CSRF) exploits in PHP. In the previous post we discussed the basics of how to protect against CSRF exploits. I recommend reading that if you haven’t yet. Now let’s cover a more advanced use case.

Multiple CSRF Tokens

The previous solution only covered basic, one time use protection but what if you need to allow users to use multiple tabs or protect AJAX calls in addition to regular ol’ forms. You don’t want a user’s form token to expire simply because an AJAX call fired off in the background.

The solution is to support multiple CSRF tokens at once.

Here was our old code to generate a token

1
2
3
4
5
6
7
8
9
10
11
12
	//assuming the rest of the form class here

	static function generateCsrf() {

	  $token = mcrypt_create_iv(16, MCRYPT_DEV_URANDOM);

	  Session::flash('csrfToken', $token);


	  return $token;
	}

and here is our new function

1
2
3
4
5
6
7
8
9
10
11
//assuming the rest of the form class here

	static function generateCsrf() {

	  $token = mcrypt_create_iv(16, MCRYPT_DEV_URANDOM);

	  $_SESSION['csrfTokens'][$token] = time();

	  return $token;
	}

What this does is instead of storing the token as the value we are storing an array of tokens and then their corresponding creation timestamps. The previous example used the Laravel Session class but in this example I’m using standard PHP session handling since I don’t want this to be confusing.

Now the validation of the CSRF tokens looks like this

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
Route::post('/signup', function(){

	  //this would probably be abstracted away into
	  //a route filter or your form validation

	  //here we are setting our expiration timestamp
	  //to 1 day ago
	  $expiration = time() - 86400; //86400 is the number of seconds in 24 hours

	  if (
	  	  isset($_SESSION['csrfTokens'][$_POST['token']]) &&
	  	  $_SESSION['csrfTokens'][$_POST['token']] >=  $expiration
	  ) {

		//process the form

	  }


	  //like earlier, you should add a
	  //legit error message here
	  die('Invalid Form Data');

	});

This new function not only checks that the token exists but also checks that it hasn’t expired.

Garbage Collection

You really should use a Session class to wrap these calls to the $_SESSION data and then write a garage collection routine to clear expired tokens. Here is an example

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
class Session
{
		function validateCSRFToken($token) {

			$this->garbageCollectCsrfTokens();

			//if it is a validate token clear it
			//and then return true
			if (isset($_SESSION['csrfTokens'][$_POST['token']]) === TRUE) {
				unset($_SESSION['csrfTokens'][$_POST['token']]);
				return TRUE;
			}

			return FALSE;

		}

		function garbageCollectCsrfTokens() {

			//here we are setting our expiration timestamp
			//to 1 day ago
			//this has been hardcoded here for simplicity
			$expiration = time() - 86400; //86400 is the # of seconds in 24 hours

			foreach ($_SESSION['csrfTokens'] as $k => $time) {

				if ($time < $expiration) {
					//unset since it's expired
					unset($_SESSION['csrfTokens'][$k]);
				}

			}

		}
	}

Everytime the token is evaluated a garabage collection routine will be ran against all the tokens. The route logic to check the tokens has now been simplified to this

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Route::post('/signup', function(Session $session){

	  //this would probably be abstracted away into
	  //a route filter or your form validation

	  if ($session->validateCSRFToken($_POST['token']) === TRUE) {

		//process the form

	  }


	  //like earlier, you should add a
	  //legit error message here
	  die('Invalid Form Data');

	});

You will now be able to use multiple CSRF tokens at once in the same user session. Plus have the added protection of expiring tokens.

Want to Learn More about PHP Security?

This builds upon topics discussed in my book, Building Secure PHP Apps. If you want to learn a ton more, some might even call it a metric fuck-ton, about writing secure PHP code then stop what you're doing and
Buy the Book

Securing against Cross Site Request Forgery (CSRF) exploits in PHP

Tue, 29 Apr 2014 00:00:00 +0000

Cross Site Request Forgery (CSRF) is basically the opposite of an XSS exploit. Where XSS takes advantage of the user by means of a trusted web site, CSRF takes advantage of the web site by means of a trusted user.

An example of this is an attacker sending out fake emails with a link to delete a blog post, an email, whatever. The target user then clicks this and is taken to a delete page. Since the user is an administrator of this site, and they have a valid session, your web application goes ahead and deletes the record as requested. The user had no idea that’s what the link was taking them to and now their account has been deleted without their consent. Not cool.

This doesn’t have to be a text link either, it is often attached to an image or a button. This might sound like a small risk since most critical web site functions are behind forms that require POSTed data but this can just as easily be expanded upon to use a button or JavaScript to submit hidden forms.

How to protect against it

The first step is to ensure that no data altering actions are preformed by GET requests. Anything that performs an action on data requires a PUT, POST or DELETE request. A basic example of this is any insert, update or delete preformed on your database should be behind a POST form request. If the user clicks a delete button they should then be taken to a form where they submit this to verify the action. If data altering actions need to be preformed over GET, maybe for a RESTful API, then simply require a unique token in the query string, exactly how we will discuss it being in the hidden form data in the following examples.

Now that you are submitting forms for your data manipulations we will need to add CSRF tokens to our forms. Our CSRF token will be a standard Nonce (Number used Once). To do this we will generate a random token, store it in the user’s session, then add it as a hidden field to our form. Once this form is POSTed we can check the POSTed CSRF token against the one in the session.

First we’ll create a function to generate the token. This will usually be placed in a universally callable place, maybe as a route filter, voter, or a helper library.

1
2
3
4
5
6
7
8
9
10
11
12
	//assuming the rest of the form class here

	static function generateCsrf() {

	  $token = mcrypt_create_iv(16, MCRYPT_DEV_URANDOM);

	  Session::flash('csrfToken', $token);


	  return $token;
	}

Note that we are using session flashdata here. This is supported concept in most session wrapping classes. Flashdata will be stored to the session but can only be accessed on one request and then it is destroyed. This keeps our token from being validate for more than this one request.

Next we’ll call this from our route and pass the token to the view that is generating the form

1
2
3
4
5
6
7
8
9
	Route::get('/signup', function(){

	  $data['token'] = Form::generateCsrf();


	  return View::render('signup.form', $data);

	});

And now for our view, “signup/form.php”

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
	<form method="POST" action="/signup">

	  <label>
		First Name:
		<input type="text" name="first_name" />
	  </label>

	  <label>
		Last Name:
		<input type="text" name="last_name" />
	  </label>

	  <label>
		Email:
		<input type="text" name="email" />
	  </label>


	  <input type="hidden" name="token" value="<?=$token?>" />

	  <input type="submit" name="submit" value="Signup" />

	</form>

When this form is POSTed we can now verify that the token is valid

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
	Route::post('/signup', function(){

	  //this would probably be abstracted away into
	  //a route filter or your form validation
	  if ($_POST['token'] === Session::get('csrfToken')) {

		//process the form

	  }


	  //like earlier, you should add a
	  //legit error message here
	  die('Invalid Form Data');

	});

Now that this token checking is in place even if an attacker tricks a user into submitting a fake form they won’t have a matching CSRF token in their session data for your website so the request will fail.

Want to Learn More about PHP Security?

This is an excerpt from my book, Securing PHP Apps. If you want to learn a ton more, some might even call it a metric fuck-ton, about writing secure PHP code then stop what you're doing and
Buy the Book

Building Secure PHP Apps - Early Release

Thu, 06 Feb 2014 00:00:00 +0000

Hey, sorry for taking like six months since my last blog post. I missed you, promise. BTW, have I mentioned how awesome you are?

I’m breaking my silence / severe writing laziness to annouce that I’m opening my ebook, Building Secure PHP Apps, for early access. It’s for sale on Leanpub right now. Currently at about 40% complete and writing around one chapter every one to two weeks so it will be done soon.

If you’ve ever wished you knew more about security, HTTPS, password encryption, etc then this should be a good guide for you. Also if you’ve ever used my Ion Auth library for CodeIgniter I suggest you check this out so you can implement good security practices in future PHP apps.

Over the years I’ve learned a lot about security and am really passionate about it. I want to help people keep their site and their users safe without having to learn it the hard way.

Anyway, if you’re interested you can learn more and buy it here:

Securing PHP Apps

My New Motto

Wed, 19 Jun 2013 00:00:00 +0000

The product is the current product, the culture is the next hundred products.

Phil Libin

Life Hack - Pomodoro

Thu, 01 Nov 2012 00:00:00 +0000

I’m always up for a good life hack to improve my productivity so I wanted to share the most recent one I’ve discovered.

The Pomodora technique is a method for time managment and focus. Most of you have probably heard of it. The gist of it is that you work hard and focus for 25 minutes and then reward yourself with a 5 minute break.

At first this might seem like a lot of wasted time with all these breaks but it really is amazing how much these breaks help you concentrate for that 25 minutes of work. Also, the 5 minute break doesn’t neccesarily have to be wasting time; I try to force myself to only check and respond to emails during the break time, this allows me to focus on coding for 25 minutes, take 5 minutes to handle email and give my brain a break, then jump back into code.

One tool that has been incredibly valuable to enforce this is Pomodoro by Steve Klabnik. It’s a simple Ruby script that will redirect time sucking websites except for the 5 minute break periods. I really recommend you try this out to get the full effect of Pomodoro.

Fix PHPUnit using Zend Server CE on OSX

Sun, 19 Aug 2012 00:00:00 +0000

Just a simple explanation for anyone else running into this issue getting PHPUnit working with Zend Server CE on OSX Mountain Lion.

The error:

PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/local/zend/lib/php_extensions/mcrypt.so' - dlopen(/usr/local/zend/lib/php_extensions/mcrypt.so, 9): Library not loaded: /usr/lib/libltdl.3.dylib
Referenced from: /usr/local/zend/lib/php_extensions/mcrypt.so
Reason: image not found in Unknown on line 0

The fix:

ln -s /usr/local/zend/lib/libltdl.3.dylib /usr/lib/libltdl.3.dylib

Enjoy!

Appcelerator JS SDK for Node.js

Wed, 25 Jul 2012 00:00:00 +0000

Announcing the release of the Appcelerator ACS JS SDK module for Node.js. Made by yours truly as the first open source release by DblTap Labs.

Check out the source on GitHub or use it in a project by installing it with npm:

$ npm install appcelerator

Ion Auth now supports MongoDB

Mon, 04 Jun 2012 00:00:00 +0000

Thanks to the awesome work done by sepehr, Ion Auth now supports MongoDB. Go check it out on Github and let me know any feedback you have.

Boxcar.io API library for CodeIgniter and bundle for Laravel

Tue, 29 May 2012 00:00:00 +0000

Announcing the release of the Boxcar.io Provider API PHP SDK for CodeIgniter and Laravel. This is a simple port of the standard PHP SDK. Check them out here:

CodeIgniter Library

Laravel Bundle

Last.FM for PyroCMS Released by AppStucco

Wed, 16 May 2012 00:00:00 +0000

Annoucing the release of the Last.FM module and widget for PyroCMS by AppStucco.

Go read about it on the AppStucco blog, watch the screencast.

Composer bundle for Laravel

Tue, 08 May 2012 00:00:00 +0000

Announcing the release of my Composer bundle for Laravel. This bundle will autoload composer packages in your Laravel application.

Composer packages are a unified way to distribute PHP packages that work with any framework that supports PSR-0 namespacing. You shouldn’t have to rewrite all of your favorite PHP libraries for each framework you use, that’s where Composer packages come to the rescue. Find the latest packages at Packagist.

You can get the bundle here: Laravel Composer Bundle

A Magical CodeIgniter Super Object

Mon, 07 May 2012 00:00:00 +0000

Recently Militis reminded me of a “trick” to automatically load items from the CodeIgniter super-object. Of course, you should determine for yourself if this functionality is needed and is worth the performance loss. We’re now using this in Ion Auth if you want to see it in action.

Just add the following method to your library class

public function __get($var)
{
	return get_instance()->$var;
}

And then you can access and CI items through the $this object like so

$this->load->library('email');

AppStucco Launch

Tue, 01 May 2012 00:00:00 +0000

Last night and today have been extremely exciting as Dan Lopez and I have offically launched AppStucco!

We are hitting the ground running with an open source LDAP module for PyroCMS and you can expect to see a few more PyroCMS modules popping up in the next few weeks.

Check us out at AppStucco.com or read more about the launch on CMS Critic.

Appcelerator PHP SDK for CodeIgniter, Laravel, and vanilla PHP

Mon, 30 Apr 2012 00:00:00 +0000

Announcing the release of the Appcelerator ACS PHP SDK for CodeIgniter, Laravel, and plain ol’ PHP. Made in collaboration with Shealan Foreshaw and sponsored by Swipe & Tap. Check it out here:

CodeIgniter Library

Laravel Bundle

PHP SDK

Writing a Nagios plugin with Javascript using Node.js

Thu, 26 Apr 2012 00:00:00 +0000

This is pretty much an exact copy of my Writing a Nagios plugin with PHP post modified for Javascript. So, here is a quick example of writing a Javascript plugin for Nagios using Node.js.

Create your JS file named “check_js_test.js” with the following contents

process.stdout.write('This check passed');
process.exit(0);

This will output the “This check passed” string to Nagio with a status code of zero. Of course you will want to customize this to determine your OK and Error states. The available status codes are

= OK	or UP
= WARNING UP or DOWN/UNREACHABLE
= CRITICAL or DOWN/UNREACHABLE
= UNKNOWN or DOWN/UNREACHABLE

Now edit your commands.cfg and add a new command for the PHP plugin we will create

define command{
    command_name    check-js-test
    command_line    node /your/path/check_js_test.js
}

Add a service to execute this command in your host config

define service{
    use                             local-service ; Name of service template to use
    host_name                       localhost
    service_description             PHP_ERROR
    check_command                   check-js-test
    check_interval                  5 ; check every 5 minutes (if you havent changed your time units)
    register                        1
    active_checks_enabled           1
    retry_interval                  1 ; retry every minute when in an error state
    max_check_attempts              4 ; test 4 times before deciding the hard state
    contact_groups                  admins ; contact the admin with errors
}

Restart Nagios and monitor your shit.

Writing a Nagios plugin with PHP

Wed, 25 Apr 2012 00:00:00 +0000

For those of you who don’t know, Nagios is a simple and powerful monitioring tool. Nagios can call external commands at set intervals to check for errors and then escalate or alert on the errors. Here is a quick example of writing a PHP plugin for Nagios.

Create your PHP file named “check_php_test.php” with the following contents

\<?php
	fwrite(STDOUT, 'This check passed');
	exit(0);

= OK	or UP
= WARNING UP or DOWN/UNREACHABLE
= CRITICAL or DOWN/UNREACHABLE
= UNKNOWN or DOWN/UNREACHABLE

Now edit your commands.cfg and add a new command for the PHP plugin we will create

define command{
    command_name    check-php-test
    command_line    php /your/path/check_php_test.php
}

Add a service to execute this command in your host config

define service{
    use                             local-service ; Name of service template to use
    host_name                       localhost
    service_description             PHP_ERROR
    check_command                   check-php-test
    check_interval                  5 ; check every 5 minutes (if you havent changed your time units)
    register                        1
    active_checks_enabled           1
    retry_interval                  1 ; retry every minute when in an error state
    max_check_attempts              4 ; test 4 times before deciding the hard state
    contact_groups                  admins ; contact the admin with errors
}

Restart Nagios and monitor your shit.

Simple Node.js Express MVR Template

Thu, 19 Apr 2012 00:00:00 +0000

In this post we’ll walk through how to setup a simple MVR Node.js project using Express, Mongoose (MongoDB), Jade (templating) and everyauth (authentication). First off, what the fuck is MVR, think MVC but with routes instead controllers.

What we’re going to be using

Express for our framework
Mongoose for MongoDB
Jade for templating
everyauth for authentication
Twitter Bootstrap for styling

Setup

You’re going to need Node.JS, NPM, and MongoDB installed. If you haven’t done that yet see Building and Installing Node.js and MongoDB Quickstart.

Open up the command line to create the project

$ npm install -g express-generator
$ express examplemvr
$ cd examplemvr
$ rm -rf ./routes
$ rm public/stylesheets/style.css
$ mkdir models
$ npm install

Now open the mongo console and insert some test data

$ mongo nodemvr
$ db.examples.insert({name:'Test Doc'});

Dependencies

Open the examplemvr project in your favorite text editor and edit package.json to match the following

package.json
--------------

{
    "name": "application-name"
  , "version": "0.0.1"
  , "private": true
  , "dependencies": {
      "express": "2.5.8"
    , "jade": ">= 0.0.1"
    , "mongodb": ">= 0.9.6-7"
    , "mongoose": ">= 2.5.10"
    , "everyauth": ">=0.2.32"
  },
  "engines": {
    "node": ">= 0.6.14",
    "npm":  "1.0.x"
  }
}

This tells NPM what modules we need and the versions we require. Now open up the command line again to update your modules with NPM

$ npm install

This will tell NPM to read the package.json and install any dependencies that are needed.

Application Core

Now open app.js and edit it to match the following

/app.js
--------------

var express = require('express');
var app = module.exports = express.createServer();
app.everyauth = require('everyauth');
app.everyauth.helpExpress(app);
app.mongoose = require('mongoose');

var config = require('./config.js')(app, express);

var models = {};
models.examples = require('./models/example')(app.mongoose).model;

require('./routes')(app, models);

app.listen(process.env.PORT || 3000);

# Review

Let’s review this a few lines at a time.

Require express and assign the server to the “app” object.

var express = require('express');
var app = module.exports = express.createServer();

Require everyauth and load the helpers

app.everyauth = require('everyauth');
app.everyauth.helpExpress(app);

Require mongoose

app.mongoose = require('mongoose');

Require the config file and pass it some variables to use, we’ll go through this later

var config = require('./config.js')(app, express);

Create the object to hold our models and then require them (is this example we only have 1 model)

var models = {};
models.examples = require('./models/example')(app.mongoose).model;

Require the routes

require('./routes')(app, models);

Set the server to listen on a port (process.env.PORT is for production deployment, ie heroku)

app.listen(process.env.PORT || 3000);

Setup the config

Create a new file under the root of the project named “config.js” and edit it to match the following

/config.js
--------------

module.exports = function(app, express, mongoose){

  var config = this;

  app.requireAuth = true;

  //configure everyauth
  app.everyauth.twitter
     .consumerKey('yourKey')
     .consumerSecret('yourSecret')
     .findOrCreateUser( function (session, accessToken, accessTokenSecret, user) {
       return 1;
  }).redirectPath('/');

  //generic config
  app.configure(function(){
    app.set('views', __dirname + '/views');
    app.set('view engine', 'jade');
    app.use(express.bodyParser());
    app.use(express.cookieParser());
    app.use(express.session({ secret: 'topsecret' }));
    app.use(app.everyauth.middleware());
    app.use(express.methodOverride());
    app.use(app.router);
    app.use(express.static(__dirname + '/public'));
  });

  //env specific config
  app.configure('development', function(){
    app.use(express.errorHandler({ dumpExceptions: true, showStack: true }));

    app.mongoose.connect('mongodb://localhost/nodemvr');
  });

  app.configure('production', function(){
    app.use(express.errorHandler());

    app.mongoose.connect('mongodb://flame.mongohq.com:27087/nodemvr');
  });

  return config;

};

I’ll let you spend some time to figure out what each little bit of this does but the gist of it is that it sets up your twitter information for authentication and then various config settings which should be pretty self explanitory.

NOTE - you will need to setup an application on dev.twitter.com to obtain a key and secret if you want to use authentication. If not, just set app.requireAuth = false.

Models

Now let’s create out example model. We’re going to be using Mongoose for MongoDB.

/models/example.js
--------------

module.exports = function(mongoose) {
  var collection = 'examples';
  var Schema = mongoose.Schema;
  var ObjectId = Schema.ObjectId;

  var schema = new Schema({
    author: ObjectId,
    name: String,
    date: Date
  });

  this.model = mongoose.model(collection, schema);

  return this;
};

Set your collection and build out you’re schema.

Views

Edit the index.jade and layout.jade to match the following

/views/layout.jade
--------------

!!!
html
    head
        title= title
        link(rel='stylesheet', href='/stylesheets/bootstrap.min.css')

    body
        div.topbar.navbar.navbar-fixed-top
            div.fill
                div.container
                    a(href='/').brand #{title}


    div.container!= body
        footer
            p
                | Node.js MVC template by
                a(href='http://benedmunds.com')(target='_blank') Ben Edmunds


/views/index.jade
--------------

div.hero-unit
    h1 Heading

div.content
    div.row
        div.span12
            h2 Sub-Heading
            ul.unstyled.indent
                each example in examples
                    li
                        a(href="example/#{example._id}")  #{example.name}

We’ll be using twitter’s bootstrap for our styling so go grab the img, and js from Github and we’ll use a customized version of the spacelab theme for bootstrap which you can get from Gist. Place them under their respective folder in the public directory. Your new directory structure should look like the following

public/
    - images/
        glyphicons-halflings-white.png
        glyphicons-halflings.png
    - javascripts/
    	bootstrap.min.js
    - stylesheets/
    	bootstrap.min.css

Routes

Now for the final step we’re going to create the routes to glue this all together, in the root of your project create a file named “routes.js” and insert the following

/routes.js
--------------

module.exports = function(app, models){

  app.get('/', function(req, res){

    if (app.requireAuth === true && req.loggedIn === false)
      res.redirect('/auth/twitter');

    //get all the rides
    models.examples.find({}, function(err, docs){

      //render the index page
      res.render('index.jade', {
          locals: {
            title: 'Example',
            search_placeholder: 'Search',
            examples: docs
          }
      });

    });
  });

};

# Review

We’ll walk through this one in more detail.

Create a route to respond to /

module.exports = function(app, models){

  app.get('/', function(req, res){

If requireAuth is true in our config then require authentication

 if (app.requireAuth === true && req.loggedIn === false)
      res.redirect('/auth/twitter');

Get the example data from the model

models.examples.find({}, function(err, docs){

Render the index.jade template with our data

res.render('index.jade', {
  locals: {
    title: 'Example',
    search_placeholder: 'Search',
    examples: docs
  }
});

Done!

Open the command line and start your app

$ node app.js

Get the code

You can get the code for this project on Github. I’m fairly new to node and this is a work in progress so if you see anywhere this can be improved feel free to send a pull request.

Translations

This page has been translated into Spanish language by Maria Ramos from Webhostinghub.com/support/edu.

Have fun!

Want to Learn More about Node?

I'm writing a book on Node JS, Building Secure Node Apps. If you want to learn a ton more, some might even call it a metric fuck-ton, about writing secure Node JS code then stop what you're doing and
Buy the Book

Tumblr bundle for Laravel

Wed, 18 Apr 2012 00:00:00 +0000

Announcing the release of my Tumblr bundle for Laravel. Check it out on Github.

Logging Client Side Javascript Errors

Tue, 17 Apr 2012 00:00:00 +0000

This seems to be something a lot of people don’t know how to do so here’s a quick intro. You might have a great error logging setup on the backend of your site but most people have no idea what’s going on with the frontend. As an example, wouldn’t it be great to be able to see what browser version that one user who always gets JS errors was actually using, or even track the user’s id so you can reference their profile data to get in contact with them.

That’s where logging client side javascript errors comes in handy. You’ll need to add logging code on the frontend and a simple API on the backend. And as a disclaimer, this code is not 100% vetted, it’s just a quick example to get you started.

Frontend

Example logging of javascript errors using jQuery

try {
  window.onerror = function(err, url, line) {
    //api url
    var apiUrl = 'your/api/url';

    //suppress browser error messages
    var suppressErrors = true;

    $.ajax({
      url: apiUrl,
      type: 'POST',
      data: {
        errorMsg: err,
        errorLine: line,
        queryString: document.location.search,
        url: document.location.pathname,
        referrer: document.referrer,
        userAgent: navigator.userAgent
      }
    });

    return suppressErrors;
  };
} catch(e) { }

Backend

Example route to log the error in Laravel

Route::post('your/api/url', function()
{
	Log::error('Javascript error:' . json_encode(Input::get()));
});

Log File

This gives you the following information in your log file

2012-04-17 23:40:44 ERROR - Javascript error:{"errorMsg":"Uncaught ReferenceError: notDefined is not defined","errorLine":"119","queryString":"","url":"\/Personal\/laravel\/public\/","referrer":"http:\/\/localhost\/Personal\/laravel\/"}

Connecting to MongoHQ with Node.js MongoDB Native

Thu, 12 Apr 2012 00:00:00 +0000

I’m using MongoHQ for a Node.js app I’m deploying on Heroku and couldn’t find it plainly documented anywhere how to connect to MongoHQ using node-mongodb-native, so enjoy:

/**
 * NOTE: whitespace added for readability
 *
 * EXAMPLE OPTIONS:
 * var options = {
 *     host: 'flame.mongohq.com',
 *     port: 27087,
 *     db: 'your_db',
 *     username: 'your_username',
 *     password: 'your_password'
 * };
 *
 **/
DataProvider = function(options) {

    //store this for later use
    var _parent = this;

    //connect to the db
    this.db = new Db(
        options.db,
        new Server(
            options.host,
    	    options.port,
    	    {auto_reconnect: true},
    	    {}
        )
    );

    //open the db connection and then authenticate
    this.db.open(function(err) {
        _parent.db.authenticate(
        	options.username,
        	options.password,
        	function(err) {
                if (err) {
                   console.log(err);
                }
            }
        );
    });

});

Leading a Dev Team - Focus

Wed, 11 Apr 2012 00:00:00 +0000

The Zone

One of the hardest things for developers is to stay focused and in the “zone”. There is, of course, debate since this can’t be scientifically proven but most people agree that it only takes a second to be snapped out of the zone but can take 15-30 minutes to get back in depending on the complexity of the task.

Human RAM

When developing there are hundreds of tiny details that you have to keep in short term memory for quick access; all of the variables and classes related to what your working on, how those classes interact with other objects, functions, the language API itself, etc. so keeping all of this at the forefront of your mind and not losing it is a very delicate task. It is your job to make it as easy as possible for your developers to maintain the concentration they need.

Implementation

I highly recommend remote working since this allows the developer to work in whatever environment is most productive for him/her. Also, keep the emails, phone calls, etc. to a minimum unless it is a true emergency. I personally love Campfire, developers can keep it open and interact as needed but are instructed that anything in Campfire is not an emergency so it can wait. If there is an emergency you’ll get an IM or call but on the average day you can focus when you need to and check in on Campfire to follow up when you’re between tasks or need a break.

Twilio bundle for Laravel

Tue, 10 Apr 2012 00:00:00 +0000

Announcing the release of my Twilio bundle for Laravel. Check it out on Github.

See the Twilio docs for API details and usage examples.

Leading a Dev Team - Burnout

Fri, 06 Apr 2012 00:00:00 +0000

An important part of leading a development team is detecting and preventing burnout before it sets in. Software development is this strange mix of creating art and worshipping logic. Programming requires you to creatively solve problems yet in the most rational way possible.

Causes

After working through a rough project, demanding managers, working a ton of hours, or due to some personal issue developers are very susceptible to burn out. Burn out is usually where your brain pretty much turns off the ability to solve problems creatively. You might be able to churn out HTML all day but good luck architecting a new API or solving a difficult bug. Marissa Mayer also has the unique and valid perspective that burnout is caused by resentment.

Solutions

The best way I’ve found to prevent burn out is to create a fun environment with as little stress as possible, give the developer more personal time, and if burnout starts to set in give them an easy project where they see progress often. Another thing to always guard against is creating resentment, so make sure that you aren’t demanding too much and be as flexible as possible. It’s amazing what a three day weekend can do to someone’s outlook. It’s also extremely refreshing for someone to create something and solve a problem without adding to their mental stress.

Leading a Dev Team - Trust

Tue, 03 Apr 2012 00:00:00 +0000

I’m going to do a small series to document some of the things I’ve learned while being a developer all these years and while managing/leading development teams. This is the first post in the series (so get ready bitches).

You have to trust your dev team completely. Only hire people who you can really trust. If you’re spending your time worrying about whether or not someone is doing their job or working their hours or whatever else then that’s energy wasted that should be spent elsewhere. There will of course be issues with certain team members, but deal with those issues quickly and trust them again as soon as possible.

Output is MUCH more important than hours. Your developers need the freedom to not be bound by a clock or a desk or a phone. Sometimes the best way to figure out a problem is to go take a walk. What might be solved by a 10 minute break can easily turn into a completely wasted day if your employees feel like they can’t break away.

Trust also leads to freedom, you’re developers should be able to make their own decisions on the technologies they use (within reason) and how they implement those technologies (where possible). Remember, you hired them for a reason, so let them grow and show you what they can do.

One Line HG Pull/Update for Deployment

Mon, 02 Apr 2012 00:00:00 +0000

The following is a quick one-liner for pulling and updating a mercurial repo with a specified directory, this is especially useful for deployment scripts:

$ hg pull -vu --cwd /full/path/to/dir/to/update

Jekyll - Publish Posts by Date/Time

Tue, 27 Mar 2012 15:30:00 +0000

I had to read through the Jekyll source to figure this out since I didn’t see this feature documented anywhere (I’m sure it is though) so I’m going to document how to filter the display of posts in Jekyll by a published date.

For example, you write a post now but don’t want it to display until a certain time tomorrow.

In _config.yml add/modify the following:

future: false # This will tell jekyll to not display future posts
In the post header add a date attribute with the date and time you want the post to publish:

date: 2012-03-28 18:31:00

How I Work

Sun, 25 Mar 2012 00:00:00 +0000

I’m always interested in the way other people work so I figured I would share my environment and what makes me most productive.

Hardware

13” Macbook Pro. When I’m sitting at my desk I use a 23” external Samsung monitor, Apple wireless keyboard, Magic Trackpad.

Software

OSX Snow Leopard. Firefox for web browsing. Sublime Text 2 for development. Git and HG on the command line for version control. CLI and PGAdmin3 for Postgres. CLI and Navicat for MySQL. Sparrow for email. Gtalk for IM. iTunes and Spotify for music.

Work Day

I usually get up around 8:15am EST. Make some coffee (dunkin donuts), feed my dogs, and let them out. Then start working around 8:30am. I usually work until about 5pm with a 30 minute lunch break but depending on what’s going on I might take a longer lunch and then work later.

I tend to move around a lot during the day. I find that a change of scenery really helps keep me thinking straight. I start the morning in the kitchen most days and then move to my office a couple of hours later for a scrum call. Sometime after lunch (if the weather is nice) I’ll move outside or some random place in the house (living room, bedroom, kitchen, office). Whenever I start to get stir crazy I’ll get out of the house and work from one of the coffee shops downtown.

Ben Edmunds

AI Skills Are the New Platform Interface

The Platform Hierarchy of Needs

Platform Engineering Isn't a Portal

Testing Microservices Without Cloning the World

The Real Problem Is Partial Isolation

What Developers Actually See

The Part That Mattered Most

Rearchitecting CI at SeatGeek

600 Repos Can’t Flip a Switch

Autoscaling CI Is Harder Than You Think

What We Built

The Numbers

Go Read the Technical Posts

Onboarding New Developers to a Legacy Codebase

Evaluating Contractors

CodeIgniter 4 Overview - It's really not dead!

Let’s start with some context around CodeIgniter

Where we are now

Why

CodeIgniter Lives On

Fixing Homebrew PHP / Apache after Yosemite

PHP

Apache

Book Review - Integrating Frontend Components with Web Applications

What’s it cover

Thoughts

Criticisms

Recommend or Hate?

Want it?

Advanced CSRF Usage in PHP

Multiple CSRF Tokens

Garbage Collection

Want to Learn More about PHP Security?

Securing against Cross Site Request Forgery (CSRF) exploits in PHP

How to protect against it

Want to Learn More about PHP Security?

Building Secure PHP Apps - Early Release

My New Motto

Life Hack - Pomodoro

Fix PHPUnit using Zend Server CE on OSX

Appcelerator JS SDK for Node.js

Ion Auth now supports MongoDB

Boxcar.io API library for CodeIgniter and bundle for Laravel

Last.FM for PyroCMS Released by AppStucco

Composer bundle for Laravel

A Magical CodeIgniter Super Object

AppStucco Launch

Appcelerator PHP SDK for CodeIgniter, Laravel, and vanilla PHP

Writing a Nagios plugin with Javascript using Node.js

Writing a Nagios plugin with PHP

Simple Node.js Express MVR Template

What we’re going to be using

Setup

Dependencies

Application Core

# Review

Setup the config

Models

Views

Routes

# Review

Done!

Get the code

Translations

Want to Learn More about Node?

Tumblr bundle for Laravel

Logging Client Side Javascript Errors

Frontend

Backend

Log File

Connecting to MongoHQ with Node.js MongoDB Native

Leading a Dev Team - Focus

The Zone

Human RAM

Implementation

Twilio bundle for Laravel

Leading a Dev Team - Burnout

Causes

Solutions