Let’s start by installing nvm using Brew:

brew install nvm

For those of us using Zsh as our Mac OS X shell, append the following to ~/.zshrc in your user home directory; it handles the automatic version switching per code project folder:

# If a .nvmrc file is present in the folder that we just changed into, switch to the version specified in it.
autoload -U add-zsh-hook
load-nvmrc() {
  local node_version="$(nvm version)"
  local nvmrc_path=".nvmrc"

  if [ -f "$nvmrc_path" ]; then
    local nvmrc_node_version=$(cat "$nvmrc_path")
    if [ "$nvmrc_node_version" != "$node_version" ]; then
      nvm use "$nvmrc_node_version"
    fi
  fi
}
add-zsh-hook chpwd load-nvmrc
load-nvmrc

Next, you likely need to install a couple of different versions of Node.js; for example, to find the latest exact version of v18 to install, run:

nvm ls-remote 18

Now all we need to do is put a .nvmrc file in each project folder to switch to an installed version; if my ~/code/yllus_site/ folder needs version v18.20.8, a file at ~/code/yllus_site/.nvmrc should simply consist of:

 18.20.8 

Reference:

• Medium: Automatically Switch to Correct Version of NodeJs Based on Project

GRANT ALL PRIVILEGES ON *.* TO 'newuser'@'%' IDENTIFIED BY 'password';

However, MySQL database in Amazon RDS and Amazon Aurora only allow one superuser to exist; however, you can neatly replicate the effect of having a superuser (the same full set of privileges) by modifying your SQL query to the following:

GRANT EXECUTE, PROCESS, SELECT, SHOW DATABASES, SHOW VIEW, ALTER, ALTER ROUTINE, CREATE, CREATE ROUTINE, DELETE, CREATE VIEW, INDEX, EVENT, DROP, TRIGGER, REFERENCES, INSERT, CREATE USER, UPDATE, RELOAD, LOCK TABLES, REPLICATION SLAVE, REPLICATION CLIENT, CREATE TEMPORARY TABLES ON *.* TO 'newuser'@'%' WITH GRANT OPTION;

References:

• User Guide for Aurora: Master user account privileges

If you’re already making use of Amazon AWS Cloud, a very low cost and foolproof solution is to utilize Amazon S3’s static website hosting feature along with Amazon CloudFront to handle the redirect:

1. Create a new Amazon S3 bucket (eg. domain-redirect-olddomaincom) with ACLs disabled, the checkbox to block all public access unchecked (as we wish to allow public access) and bucket versioning disabled; create the bucket.
2. Edit the newly created S3 bucket; under the Properties tab, edit the Static Website Hosting properties.
3. In the Static Website Hosting properties page:
   • Static website hosting: Enable
   • Hosting type: Host a static website
   • Index document: index.html
   • Redirection rules: Copy/paste the following, with the appropriate changes made to the values of HostName and ReplaceKeyPrefixWith:

     [
         {
             "Redirect": {
                 "HostName": "www.newdomain.com",
                 "HttpRedirectCode": "301",
                 "Protocol": "https",
                 "ReplaceKeyPrefixWith": "path/to/redirect/to/"
             }
         }
     ]

4. Hit the Save Changes button to finalize the redirect using the S3 bucket; it should work immediately and allow you to test it via the Bucket Website Endpoint URL shown on the page.
5. Create a new Amazon CloudFront distribution, making sure to:
   1. Create Origin: Ensure that it points to the static website endpoint of your new S3 bucket (eg. domain-redirect-olddomaincom.s3-website.ca-central-1.amazonaws.com, not the default of domain-redirect-olddomaincom.s3.ca-central-1.amazonaws.com)
   2. Alternate domain name (CNAME): Enter all versions of the domain you wish to be handled and redirected (eg. olddomain.com and www.olddomain.com)
   3. Custom SSL certificate: Request a certificate that handles the domains you entered above; this is the (free) option that allows your newly set up domain redirect to respond properly to both HTTP and HTTPS requests
6. Add the Amazon CloudFront domain (eg. d1gyvh82u10kd6.cloudfront.net) to your domain name’s DNS records for the root and subdomains you wish to redirect.

You’re done! While a bit long-winded as a process, this appears to be the cheapest and most foolproof way to set up a domain redirect for the long term.

SELECT
	table_schema AS `Database`,
	table_name AS `Table`,
	ROUND(((data_length + index_length) / 1024 / 1024), 2) AS `Size in MB`
FROM information_schema.TABLES
ORDER BY table_schema, (data_length + index_length) DESC;

Reference:

• How to get the sizes of the tables of a MySQL database?

mysqldump -h {host} -P {port} -u {username} -p{password} {database_name} {table_name} --where="ID = 1" --no-create-info --no-create-db

Reference:

• Stack Overflow: Get Insert Statement for existing row in MySQL

1. Take a look at the list of currently supported PHP platforms on Elastic Beanstalk; you’ll want to decide which Solution Stack Name (eg. “64bit Amazon Linux 2 v3.4.1 running PHP 8.1”) corresponds to the platform you wish to upgrade to.
2. In the Elastic Beanstalk web configuration page, get the environment ID for the environment you wish to upgrade (eg. “e-jwfjvy57r3”).
3. Run the aws command to upgrade the environment in place:
   aws elasticbeanstalk update-environment --solution-stack-name "64bit Amazon Linux 2 v3.4.1 running PHP 8.1" --environment-id "e-2iuwivbgzc" --region "ca-central-1"

Reference:

• Blue Keyboard – How to update PHP versions on Elastic Beanstalk environments

sudo yum install sysstat -y

And running the sar command, looking at the value of tps:

sar -d 1

find . -type f -printf "%T@ %p\0" | sort -zk1nr | xargs -0 printf "%s\n"

• https://material.io/devices/

But there’s a potential downside that has to be addressed: Software is complex, and the requirements of web development often extremely so. How does a small team come through with everything that’s needed to make a project work? My answer has been to build the core of the team around generalists – people who tend to be very good in one area of development, but also knowledgeable and capable in most others as well.

Here’s an excerpt from the Pragmatic Programmer series titled Be A Generalist that speaks to why generalists are the answer to meeting a modern business product’s software needs:

For at least a couple of decades, desperate managers and business owners have been pretending that software development is a manufacturing process at heart. Requirements specifications are created, and architects turn these specifications into a high-level technical vision. Designers fill out the architecture with detailed design documentation, which is handed to robot-like coders, who hold pulp-fiction novels in one hand while sleepily typing in the design’s implementation with the other. Finally, Inspector 12 receives the completed code, which doesn’t receive her stamp of approval unless it meets the original specifications.

It’s no surprise that managers want software development to be like manufacturing. Managers understand how to make manufacturing work. We have decades of experience in how to build physical objects efficiently and accurately. So, applying what we’ve learned from manufacturing, we should be able to optimize the software development process into the well-tuned engine that our manufacturing plants have become.

In the so-called software factory, the employees are specialists. They sit at their place in the assembly line, fastening Java components together or rounding the rough edges of a Visual Basic application on their software lathes. Inspector 12 is a tester by trade. Software components move down the line, and she tests and stamps them in the same way each day. J2EE designers design J2EE applications. C++ coders code in C++. The world is very clean and compartmentalized.

Unfortunately, the manufacturing analogy doesn’t work. Software is at least as malleable as software requirements. Things change in business, and businesspeople know that software is soft and can be changed to meet those requirements. This means architecture, designs, code, and tests must all be created and revised in a fashion more agile than the leanest manufacturing processes can provide.

In this kind of rapidly changing environment, the flexible will survive. When the pressure is on, a smart businessperson will turn to a software professional can solve the problem at hand. So, how do you become that person whose name comes up when they’re looking for a superhero to save the day? The key is to be able to solve the problems that may arise.

What are those problems? That’s right: you don’t know. Neither do I. What I do know is that those problems are as diverse as deployment issues, critical design flaws that need to be solved and quickly reimplemented, heterogenous system integration, and rapid, ad hoc report generation. Faced with a problem set as diverse as this, poor Inspector 12 would be passed over pretty quickly.

The label jack-of-all-trades—master of none is normally meant to be derogatory, implying that the labelee lacks the focus to really dive into a subject and master it. But, when your online shopping application is on the fritz, and you’re losing orders by the hundreds as each hour passes, it’s the jackof-all-trades who not only knows how the application’s code works but can also do low-level UNIX debugging of your web server processes, analyze your RDBM’s configuration for potential performance bottlenecks, and check your network’s router configuration for hard-to-find problems.

And, more important, after finding the problem, the jack-of-all-trades can quickly make architecture and design decisions, implement code fixes, and deploy a new fixed system to production. In this scenario, the manufacturing scenario seems quaint at best and critically flawed at worst.

Another way in which the software factory breaks down is in that, although in an assembly line the work keeps coming in a steady flow, software projects are usually very cyclical. Not only is the actual flow of projects cyclical, but the work inside a project is cyclical. A coder sits on the bench while requirements are being specified, architected, and designed, or the coder multitasks across many projects. The problem with multitasking coders is that, despite the software factory’s intentions, when the rubber meets the road, the coders rely a great deal on context and experience to get their jobs done. Requirements, architecture, and design documents can be a great head start, but ultimately if the programmers don’t understand what the system is supposed to do, they won’t be able to create a good implementation of the system.

Of course, I’m not just picking on coders here. The same is true at nearly every spot on the software assembly line. Context matters, and multitasking doesn’t quite work. As a result, we have an inefficient manufacturing system. There have been various attempts to solve this problem of inefficiency without departing from the manufacturing-inspired system, but we have not yet figured out how to optimize our software factories to an acceptable level.

If you are just a coder or a tester or a designer or an architect, you’re going to find yourself sitting idle or doing busywork during the ebbs of your business’s project flow. If you are just a J2EE programmer or a .NET programmer or a UNIX systems programmer, you’re not going to have much to contribute when the focus of a project or a company shifts, even temporarily, out of your focus area. It’s not about where you sit on the perceived value chain of project work (where the architect holds the highest spot of royalty). It’s about how generally useful you make yourself.

References:

• The Pragmatic Programmer: Be A Generalist
• QSM: Small Teams Deliver Lower Cost, Higher Quality

Here we can see that mobile consumption has clearly exploded, with a 44% gain in mobile app usage and a 38% gain in mobile web usage. This has contributed to mobile growing its share of digital media time spent from 50% to 60% in the past year and owning a clear majority of time spent.

But importantly, desktop usage has held up in the face of increased competition from mobile for consumers’ attention, with a negligible overall decline in total time spent from 477 billion minutes to 466 billion minutes. The net result of is that we’ve seen a 20% overall increase in time spent on digital in the past year, which means a lot more opportunity to reach consumers and monetize content.

As a web developer, this tells me that websites with analytics that tell me that desktop users are predominant aren’t to be forgotten; mobile Web usage is growing, but native app usage is where people’s attention is.

Enter Download Analytics, which will ask for input of a URL to the report page you’re viewing, and will automatically prompt to e-mail you (when ready) a link that will allow you to download the entire list of rows in your report. Simple, fast, effective.

1. Install php5-xdebug:

sudo apt-get install php5-xdebug

2. Edit the xdebug configuration file /etc/php5/fpm/conf.d/xdebug.ini , most notably changing the default port to 9001 as PHP-FPM itself runs a daemon on port 9000. We also change the log file location to /var/log/xdebug (remember to create this folder):

xdebug.profiler_output_dir=/var/log/xdebug
xdebug.profiler_enable_trigger=1
xdebug.profiler_enable=0

xdebug.remote_enable=true
xdebug.remote_host=127.0.0.1
xdebug.remote_port=9001
xdebug.remote_handler=dbgp
xdebug.remote_autostart=0

3. Restart PHP-FPM:

sudo /etc/init.d/php5-fpm reload

4. In Aptana Studio 3, we’ll start by ensuring that Aptana recognizes XDebug as being installed as a debugger on the system. Go to Window > Preferences > Aptana Studio > Editors > PHP > Debug. Ensure that under Installed Debuggers, XDebug is listed on port 9001.

5. While still in the Preferences window, go to General > Web Browser and change the option to Use external web browser. Leave Default system web browser marked.

6. Close the Preferences window and go to Run > Debug Configurations… Right-click PHP Web Page and select New.

7. Name your configuration whatever you’d like (localhost if you’re lacking ideas). Ensure that Server Debugger is set to XDebug. Create a new PHP Server by clicking the + button, and ensure that you set the Base URL and Document Root properly for the website you are trying to debug.

8. Almost done! We now need to Xdebug Helper in the Google Chrome browser. After it’s installed, enable it on your locally viewed web page by clicking the bug icon until it changes colour to green (if you hover over it, it will inform you that it has debugging enabled).

9. Let’s switch back to Aptana Studio 3. Under Window > Perspective, switch to Debug. We left the “Break on first line…” option under Window > Preferences > Aptana Studio > Editors > PHP > Debug, but you can just as easily double-click in the margin beside any line in your PHP script to add a breakpoint at that location. Navigate to a page that will execute that PHP script and watch as execution halts and your debugger steps in, giving you the ability to inspect variables or control execution at will.

10. Inspect the value of any variable quickly by adding the Expressions window while in Debug mode at Window > Show View > Expressions. Pop in a variable such as $page and press Enter to see the value immediately.

Need to switch back to regular coding view? Under Window > Perspective, switch to Web. Bear in mind that even outside of the Debug perspective your debugger will be active – click the bug icon in Chrome until it is grey to disable activating XDebug.

1. Move the large folder you wish to have Aptana ignore out of your project and replace it with an empty folder.
2. Refresh the project to ensure the empty folder appears in the project.
3. Right-click on the empty folder and select Properties, and then Resource.
4. Under Attributes, check Derived.
5. Copy the contents of the folder back into place – Aptana should ignore it and keep UI responsiveness quick.

Sources:

• Stack Overflow: Eclipse – Ignore Entire Directories
• dans.blog – Excluding a folder or file from being searched in Eclipse

This is rather cynical, but I imagine that these pronouncements aren’t for my ears anyways: They’re made to justify keeping “information technology professionals” on the overtime exempt list, or to raise immigration caps for technology workers. (Which is often well justified, but I wonder at the distortion it introduces to the domestic labour pool.)

TIME.com – The Skills Gap Myth: Why Companies Can’t Find Good People

…

The first thing that makes me wonder about the supposed “skill gap” is that, when pressed for more evidence, roughly 10% of employers admit that the problem is really that the candidates they want won’t accept the positions at the wage level being offered. That’s not a skill shortage, it’s simply being unwilling to pay the going price.

But the heart of the real story about employer difficulties in hiring can be seen in the Manpower data showing that only 15% of employers who say they see a skill shortage say that the issue is a lack of candidate knowledge, which is what we’d normally think of as skill. Instead, by far the most important shortfall they see in candidates is a lack of experience doing similar jobs.

Employers are not looking to hire entry-level applicants right out of school. They want experienced candidates who can contribute immediately with no training or start-up time. That’s certainly understandable, but the only people who can do that are those who have done virtually the same job before, and that often requires a skill set that, in a rapidly changing world, may die out soon after it is perfected.

…

Another way to describe the above situation is that employers don’t want to provide any training for new hires — or even any time for candidates to get up to speed. A 2011 Accenture survey found that only 21% of U.S. employees had received any employer-provided formal training in the past five years. Does it make sense to keep vacancies unfilled for months to avoid having to give new hires with less-than-perfect skills time to get up to speed?

Employers further complicated the hiring process by piling on more and more job requirements, expecting that in a down market a perfect candidate will turn up if they just keep looking. One job seeker I interviewed in my own research described her experience trying to land “one post that has gone unfilled for nearly a year, asking the candidate to not only be the human resources expert but the marketing, publishing, project manager, accounting and finance expert. When I asked the employer if it was difficult to fill the position, the response was ‘yes but we want the right fit.’”

Another factor that contributes to the perception of a skills gap is that most employers now use software to handle job applications, adding rigidity to the process that screens out all but the theoretically perfect candidate. Most systems, for example, now ask potential applicants what wage they are seeking — and toss out those who put down a figure higher than the employer wants. That’s hardly a skill problem.

Meanwhile, applicants are typically assessed almost entirely on prior experience and credentials, and a failure to meet any one of the requirements leads to elimination. One manager told me that in his company 25,000 applicants had applied for a standard engineering job, yet none were rated as qualified. How could that be? Just put in enough of these yes/no requirements and it becomes mathematically unlikely that anyone will get through.

…

Adam Wiggins – How To Scale a Development Team

As hackers, we’re familiar with the need to scale web servers, databases, and other software systems. An equally important challenge in a growing business is scaling your development team.

Most technology companies hit a wall with dev team scalability somewhere around ten developers. Having navigated this process fairly successfully over the last few years at Heroku, this post will present what I see as the stages of life in a development team, and the problems and potential solutions at each stage.

Stage 1: Homebrewing

In the beginning, your company is 2 – 4 guys/gals working in someone’s living room, a cafe, or a coworking space. Communication and coordination is easy: with just a few people sitting right next to each other, everyone knows what everyone else is working on. Founders and early employees tend to be very self-directed so the need for management is nearly non-existent. Everyone is a generalist and works on a little bit of everything. You have a single group chat channel and a single all@yourcompany.com mailing list. There’s no real need to track any tasks or even bugs. A full copy of the state of the entire company and your product is easily contained within everyone’s brain.

At this stage, you’re trying to create and vet your minimum viable product, which is a fancy way of saying that you’re trying to figure out what you’re even doing here. Any kind of structure or process at this point will be extremely detrimental. Everyone has to be a generalist and able to work on any kind of problem – specialists will be (at best) somewhat bored and (at worst) highly distracting because they want to steer product development into whatever realm they specialize in.

Stage 2: The first hires

Once you’ve gotten a little funding and been able to hire a few more developers, for a total of 5 – 9, you may find that the ad-hoc method of coordination (expecting to overhear everything of importance by sitting near teammates) starts to break down. You have both too much communication (keeping tabs on six other people’s work is time-consuming) and too little communication (you end up colliding on trying to fix the same bug, answer the same support email, or respond to the same Nagios page).

At this point, you want to add just a sprinkle of structure: maybe an iteration planning on Monday, daily standups, and tracking big to-do items and bugs on a whiteboard or in a simple tool like Lighthouse. Perhaps you switch to a support system like Zendesk where incoming support requests can be assigned, and you add a simple on-call rotation for pages via Pagerduty. Your single internal chat and email channels continue to work fine.

Resist the urge to introduce too much structure and process at this point. Some startups, on reaching this stage, declare “we’ve got to grow up and act like a real company now” and immediately try to switch to heavy-handed tactics. For example: full-fledged SCRUM, heavyweight tools like Jira, or hiring a project manager or engineering manager. Don’t do that stuff. You’ve got a team that works well together in an ad-hoc way; you probably have some natural leaders on the team who direct a lot of the work while still being hands-on themselves; and while your product is launched and in the hands of users, in many ways you’re still trying to figure out what your company is really all about. Introducing bureaucracy into this environment is almost guaranteed to block you from doing what you’re really supposed to be doing, which is pivoting in search of your scalable business model.

Focus at this stage is key. Everyone is still a generalist, but the whole development team should be aligned behind a single goal (aka milestone) at a time. If you try to attack multiple battlefronts at once, and you’ll do everything badly. Great companies are more likely to die indigestion from too much opportunity than starvation from too little. Pick your battles carefully and stay focused.

Crisis on the brink of Stage 3

Grow to 10 – 15 developers, and you’re on the verge of a major team structure change. I’ve been told that many promising startups have been killed by failing to weather the transition between these stages.

With this many developers, iteration planning, standups, or any other kind of development-team meeting has become so big that the attendees spend most of their time bored. Any individual developer will find it difficult to find a sense of purpose or shared direction in the midst of trudging through laundry lists of details on other people’s work.

In programming, when a class or sourcefile gets to big, the solution is to break it down into smaller pieces. The same principle holds for scaling a development organization. You need to break into targeted teams.

Stage 3: Breaking into teams

Dividing your single team of generalists is harder than it sounds. Draw the fences in the wrong place, and you’ll create coordination problems that make things even worse. Find the right places to divide and you’ll see a massive increase in focus, happiness, and productivity.

The key to a good team is a well-defined sphere of authority, with clear interfaces to other teams. The team should own the vision and direction for the part of your product that it works on. It should be able to operate with maximum autonomy on everything it owns without having to ask for permission or information from other teams, except for the infrequent case of a feature or bug that crosses team boundaries.

A close mapping between your software architecture and your team architecture will be a big help here. By this time you have probably already converted your monolithic application into a distributed system of multiple components communicating over REST, AMQP, or other RPC mechanism. (And if not, you should strongly consider doing so, coincident with your dev team split.) There should be an obvious mapping between software components – each of which has their own source repository and deployment location/procedure – and your nascent teams.

Deciding what person goes on what team will be somewhat arbitrary at first. My approach was to sit down with each developer and dig in to try to understand what parts of the system they were most passionate about working on. From there I divided up the teams as best I could. Some people found perfect homes on their first team assignment, others were dissatisfied and needed to transfer to another team fairly quickly. Over time, the team territories became very well-defined, so it became much easier to slot new hires in the right place. Let developers follow their own passions and they will gravitate toward the team where they will do the best work.

Separately, you should have found your product/market fit by this point. If you’ve grown to this size and are still figuring out your company’s meaning for existence, you’ve got big problems. If that’s the case, stop growing, and scale back down until you nail product/market fit.

Specialization

Another reason to break into teams is specialization. Types of engineering specialists include ops engineers/sysadmins, infrastructure developers, front-end web developers, back-end web developers, business engineers / data analysts, and developers who focus on a particular language. Language specialists are becoming more common, because many internet-scale companies write high-concurrency components in functional programming like Erlang, Scala, or Clojure, generally handled by a different set of developers than the authors of the Ruby, Python, or PHP web components.

Early on, specialists are rarely desirable. There’s too many different layers to work on in delivering a software product relative to the number of people available to contribute, so the everyone pitches in on everything. This may put a developer doing such far-ranging work such as ops projects like kernel updates on the OS, to front-end projects like writing JQuery effects for the UI.

Once you reach the point where you’ve got a dozen developers, your product has reached a level of usage and maturity where the problems are getting much harder. Scaling the database is something that is not only a full-time job, but requires a deep level of specialized knowledge that can’t be acquired if that person is also simultaneously learning to be a JQuery expert and an iOS expert and an Erlang expert.

You need people who can and are willing to focus on just a few closely related areas so that they can build very deep knowledge in those areas. Some of these will be your existing generalists deciding to specialize, and some will be new hires. You can now hire for the kind of specialist that would not have been appropriate when your company was smaller. Generalists are always useful to have around, and some of them may move into management – filling business owner roles for a team, rather than hands-on development.

Heroku’s first teams

Heroku’s initial team breakdown looked like this:

• API – Owns our user-facing web app and the matching Heroku client gem.
• Data – Builds and runs our PostgreSQL-as-a-service database product.
• Ops – Shepherds and protects availability of the production system.
• Routing – Manages everything necessary to get HTTP requests routed to user web processes.
• Runtime – Handles packaging code for deploy and starting/stopping/managing user processes.

Each of these teams owns between one and five components. For example, the API team owns the Rails app which runs at api.heroku.com and the Heroku client gem. The Data team owns the provisioning and monitoring tool for our database service, as well as all of the individual running databases. (Peter van Hardenburg was the intrapreneur who founded and now leads our Data team. He tells a bit of that story in the later part of this video.)

Team size and roles

For us, the ideal team layout has been two developers and one business owner. One developer is not enough over the long term (they need a second pair of eyes on the code, and besides, one is a lonely number). Three developers works fine as well. Get to four or five and things start to become a bit crowded; there may not be enough surface area for them to all work without stepping on each others’ toes constantly. Almost all of Heroku’s teams have two developers.

“Business owner” is a somewhat clumsy term, but it’s the best we’ve come to describe the person doing some combination of product management, project management, and general management for the team. The business owner fills the important role of knowing the business value of the team’s work to the company and how it fits in with the larger product. They can broker cross-team communication, help prioritize projects and tasks by business value, and may provide status reports on the team’s progress or presentations to the senior executives and/or the entire company to justify the team’s ongoing existence.

I’m a fan of hacker-entrepreneurs in the business owner role: a strong technical background means they have an in-depth understanding of the work being done, and are able to command huge respect from those whose work they are directing. This sort of person is not necessarily available for all teams, but find them when you can. In many cases it involves quite a bit of convincing to get a hacker to give up coding as their primary function.

Avoid having developers belong to more than one team. They are makers and need to be able to focus their full attention on their team’s current projects without distraction or attempts at multitasking. Business owners, however, can sometimes belong to multiple teams. It’s not always a full-time job, and there are benefits to cross-team communication by having one person be a business owner for two or more related teams.

Cohesion

In the earlier stages, you should avoid attacking on multiple battlefronts, and instead keep all developers focused around a single goal for the company. With creation of fiefdoms for each team, this has changed. Now you can and should attack on multiple battlefronts. Each team should be executing independently against its own goals, and not worrying too much about what other teams are doing.

It’s awesome to be able to pursue three, four, five big goals simultaneously. A few months after breaking into teams at Heroku, we had a day where three different teams were all releasing major new features. It’s an incredible feeling.

But now you have a new problem: lack of cohesion. Your decentralized teams are setting their own roadmaps and deciding on features independently. But to avoid fragmentation in your product, someone needs to decide an overall direction and set of product values. More succinctly: you need a strategy.

But this post is long enough as it is. I’ll save discussion of cohesion and strategy for another time.

var scr = document.createElement('script');
scr.src = 'http://openexchangerates.org/latest.json?callback=formatCurrency';
document.body.appendChild(scr);

function formatCurrency(data) {
	// Do stuff with the data that's been returned.
	1;
}

Lines 1 – 3 of the above create a SCRIPT tag in the DOM, defines the URL to retrieve data from and in line 3 makes the request. To continue the execution cycle, the script at openexchangerates.org must wrap its data in a function:

formatCurrency({ "hello" : "Hi, I'm JSON. Who are you?"})

This calls the locally defined function formatCurrency(), which does whatever it needs to do with the returned data. A quick hack to make your API (assuming you control it) work with JSONP would be as follows:

// assume $json holds the JSON response
if ($GET['callback'] != '') $json = $GET['callback']."( $json )";
return $json;

I have yet to test this, but I imagine you could also be much more daring and avoid having to get the following code uploaded to your API of choice. To do this, execute the first bit of JavaScript on this page, and then execute an eval() statement on the data in the manner of the below:

eval('formatCurrency(' + returned_data + ')');