Last Friday afternoon, I was happily looking forward to a long Labor Day weekend. My business partner has left for the beach and I was handling customer service. I log into our production MoonClerk app, and low and behold, all of our custom fonts were broken. Then the tweets came.
I’m at a total loss. No deploy, nothing changed. It’s just broken. This started a 10 hour endeavor to figure out a fix for our specific situation. In case you happen to be in the same situation, hopefully this will help.
I realize after stumbling upon the Aug 28 update and it’s source that Google automatically updated Chrome and the new version stop allowing cross origin fonts from loading. Here is our situation:
- Rails 4 app hosted on Heroku
- Assets on Amazon CloudFront CDN
- SSL Only Access
Most of the suggestions were to update Apache or nginx to serve up the appropriate headers (Access-Control-Allow-Origin) for the font files. Unfortunately, there is no web server to configure on Heroku. That leave us with a Rack middleware solution. Thanks to Kenneth I learned about the font_assets gem. Awesome solution.
Adding the font_assets gem got me close but it still wasn’t working. Requesting the font on my server had the appropriate headers but the same font request via CloudFront (even after cache invalidation) did not contain the headers.
Then I noticed that the CloudFront version was returning a 301 redirect which clued me into the last piece of the puzzle. After another couple hours of nosing around the AWS documentation and CloudFront site, I finally found what I though may be the issue.
There is a setting in the CloudFront AWS console:
CloudFront Distributions > Origins > Origin Policy Protocol
It has two options: HTTP & Match Origin. I left the default (HTTP) when initially setting up my distribution. As it turns out, this tells CloudFront how to access the Origin server when getting a new version of a file. Although the request to our font file was using HTTPS, CloudFront was then using HTTP behind the scenes to retrieve the file and was getting redirected to the HTTPS version and losing the headers in the process. After changing this setting and invalidating the cache for the specific font files (for the 27th time), our fonts worked again.
Hopefully it won’t take you 10 hours.
I first saw “cowork” as a concept on a Twitter post a year or so ago. Not knowing what it was, it forced me to create a new mental category about work environments. I come from a pretty traditional work environment. For the past 10 years, I’ve worked in a fairly typical office space. It was owned (or leased) by the company by which I was employed. I had a private office with door. It was certainly better than the cubicles of my youth, but I never thought much about it. It was just the office that you had to go to each day as a part of the job.
In August 2009, I was informed that my “job” would be ending as all software development would be moving to the home office in Houston, TX. I was given three months notice. It was November 1st before I knew it and I was no longer employed. While searching for another job, I decided to ramp up Sourcescape, my then part-time consulting business. The economy had other plans. I couldn’t find much work and there were no full-time jobs on the horizon.
Fast forward 10 months. It’s September 2010, Sourcescape is gaining some momentum. I’m working in various places. Some days I’m at home, others are in coffee shops, and others are in my good friend’s office who graciously offered me some office space. I see through Twitter that CoWork Greenville is expanding and taking applications for full and part-time spots. This got the wheels turning and I decided to learn more.
Figuring it Out
Was it just a place where people who were fed up with coffee shops go to work? What was the benefit? After all, I have some space to work at Amy Adele for free. However, I was isolated and really missed working with other intelligent people in my field. Maybe I should check out CoWork and see about coming down there a day or two a week.
It just so happened that the CoWork Greenville open house for their new location was around the corner, so I decided to go and check it out.
What I found was some of what I expected and something that I didn’t. It was a group of “web people” work worked in the same building, some working together, some independently, all growing their businesses. That, I expected. The surprise came when I realized that this was more than just a common work place. One of the overarching goals was to build a community of independents that could make an impact on each other and the greater Greenville community.
It’s hard to nail down what that means or how it will play out, but it was something that I wanted to be a part of. It seemed clear that joining the community would be tough to do once or twice a week. Even though Sourcescape wasn’t exactly in the place financially to justify the move, I felt like it was clearly where I needed to be. I took a leap of faith and signed a 1-year lease to become a CoWorker once the new location opened on November 1, 2010.
The First Month
The first week was a tough adjustment. Not only did I move to a new office, but I has just taken on a new client working with the great team at Rails Dog. It has been a long time since I’ve been one of the the new kid on the block. It was clear that many in this group had been working together for a while. The recent move brought a few of us new guys to bring the CoWorker count up to 16.
It’s always tricky navigating a new environment. So far, though, it’s been well worth it. As providence would have it, I’m fortunate to sit next to the super talented Matthew Smith of Squared Eye fame. As I get to know each of the guys (and girl) at CoWork, I continue to be amazed at the graciousness, talent and depth that this group brings together. I count myself blessed to be a part of it.
I have little idea of the the future holds for CoWork, or for Sourcescape for that matter, but I’m convinced that it is a journey worth taking and one that will continue to surprise me and bring a smile to my face.
If you’re interested in seeing how things unfold, please join us on the journey. You can follow us @cowork on Twitter or check out the CoWork photo stream on Flickr.
As always, I’ll occasionally blog right here.
I’m in the process of figuring out the best way to estimate time and cost on a proposal for an agile project. It’s always a tricky thing. Agile, by nature, is constantly embracing change and harnessing it for the good of the product and the client. So how do you communicate when it will be done or for that matter estimate how much it will cost?
I came across this quote from Ron Jeffries. It was so well put, I developed a giddy little grin and shouted out “AMEN”!
So here’s an example of how he answers the question, “So when will this project be done?”.
Right now, this appears to be a 200-point project. Based on our performance on other projects (or a random guess), with N programmers on it, and your intimate involvement in the project, a project of this size will take between 4 and 6 months. However, we will be shipping software to you every two weeks, and we’ll be ticking off these feature stories to your satisfaction. The good news is that if you’re not satisfied, you can stop. The better news is that if you become satisfied before all the features are done, you can stop. The bad news is that you need to work with us to make it clear just what your satisfaction means. The best news is that whenever there are enough features working to make the program useful, you can ask us to prepare it for deployment, and we’ll do that. As we go forward, we’ll all see how fast we’re progressing, and our estimate of the time needed will improve. In every case, you’ll see what is going on, you’ll see concrete evidence of useful software running the tests that you specify, and you’ll know everything as soon as I know it. (emphasis mine)
Ron Jeffries, as quoted in Mike Cohn’s book “Agile Estimating and Planning”, Upper Saddle River, N.J.: Prentice Hall PTR – 2006
Now that is well put!
One of the things that I’m passionate about is the development process. So much of the battle is won or lost by the type of development process you have. Leaning on a couple smart guys, I’ve established a very clean workflow in git. If you haven’t read these posts, please do so before continuing. Both are excellent and will help clarify my question.
The only discrepancy between them is how to handle feature branches. Should you interactively rebase (
git rebase -i) your feature branch to one commit (or possibly a couple)? Rein takes this approach. Vincent on the other hand prefers to leave the feature branch intact and do a non-fast forward merge (
git merge --no-ff feature) to merge the feature back into the develop branch.
I’ve tried it both ways. Neither is right or wrong and both have their advantages.
Both go into the develop branch as a single commit, one as a normal commit and one as a merge commit. With the interactive rebase, you lose the granular commit history and potentially have a significantly larger commit. But you have a clear comment (with summary bullets if you follow Rein’s suggestion) as to what the commit it.
With a forced merge commit, you maintain the feature branch history which is nice to track down where some error entered the code, but the merge commit is auto-commented with something like ‘
Merge branch 'feature-x'’. It’s less clear when looking down the commit list of develop what is represented. Another downside of this approach is that you create a lot of unnecessary merge commits in the tree.
At this point, I think I lean more toward the interactive rebase over the merge, but I’m still not thoroughly convince. Have an opinion, please let me know in the comments.
For the past few years, I’ve used Slicehost for all my production hosting needs. I have been very happy with them. Recently I had a need for a new staging server. It takes a good amount of time to set up a site from scratch on Slicehost, which is fine for production servers, but I needed a site up quickly.
I’ve been using Heroku’s incredible service recently for staging sites. This site however had a ton of uploaded images and I really did want to go through the hassle of setting up S3 for use with Heroku. So I started looking for other options and found Webbynode.
Their ReadyStack concept made it really easy to get a VPS server up and running quickly, yet you still have full access to the server as root (same as Slicehost). Their web user interface was clean and enjoyable to use. For my situation, it was the best of both worlds. I wasn’t limited by a read-only file system like Heroku and didn’t take nearly the time to set up and configure as Slicehost.
I ran into one bug where you couldn’t use certain special characters in your root password, but got a prompt reply that they would look into it. Overall, I was very pleased. Good work guys.