My first post on web technology talks about what we are trying to accomplish when building for the web. There are four ways we can break down the standard flow of client action/server action/result: delivering, serving, rendering and developing. This post focuses on delivering content by understanding the network. Why use a [cdn][cdn]? What’s all the fuss about connections and compressed static assets? The network is often overlooked but understanding how it operates is essential for building high performing websites. A 50ms rendering time with a 50ms db query is meaningless if it takes three seconds to download a page.
Building for the Web: Understanding The Network
January 6th, 2012 § 0 comments § permalink
Building for the Web: What Are We Trying to Accomplish?
January 4th, 2012 § 0 comments § permalink
The web technology landscape is huge and growing every day. There are hundreds of options from servers to languages to frameworks for building the next big thing. Is it [nginx][nginx] + [unicorn][unicorn] + [rubinus][rubinus] or a [node.js][nodejs] restful service on [cassandra][cassandra] running with [ember.js][ember] and html5 on the front end? Should I learn [python][python] or [scala][scala]? What’s the best nosql database for a socially powered group buying predicative analysis real-time boutique mobile aggregator that scales to 100 million users and never fails?
Thoughts on Kanban
December 14th, 2011 § 5 comments § permalink
One of my favorite achievements in the agile/lean world has been the progression from standard Scrum practices to a Kanban approach of software development. In fact, Kanban, in my opinion, is such an ideal approach to software development I cannot imagine approaching team-based development any other way.
My post about image delivery on the Getty Images Blog
December 7th, 2011 § 1 comment § permalink
I wrote an article covering how we move images to our customers on the new Getty Images blog.
Solr: Improving Performance and Other Considerations
November 29th, 2011 § 0 comments § permalink
We use Solr as our search engine for one of our internal systems. It has been awesome; before, we had to deal with very messy sql statements to support many search criteria. Solr allows us to stick our denormalized data into an index and search on an arbitrary number of fields via an elegant, RESTful interface. It’s extremely fast, easy to use, and easy to scale. I wanted to share some lessons learned from our experience with Solr.
Where Am I?
You are currently browsing the Programming category at Adventures in HttpContext.
Feeds
