I am excited by the growing popularity of the HTTPS Everywhere plugin. I became aware of it recently when users wrote me to complain that some part of Mises.org did not work over SSL. It turns out that our store
software redirects visitors to the official hostname, so going to https://mises.org/store would redirect to http://mises.org/store, which HTTPS Everywhere would redirect back to https://mises.org/store, and so on. I decided to fix this and also to fix the “this page includes other resources which are not secure” warning.
How I implemented automatic SSL switching:
- SSL proxy: We use CloudFlare as an SSL proxy. Even though we already had SSL configured on our Windows server, CloudFlare makes it easy to share SSL certificates between Windows and Linux servers, which is otherwise quite tricky. But it’s also great if your web server does not have SSL support.
- Relative (scheme-less) Urls: I removed the scheme from all our resources, so they look like <img src=”//images.mises.org/Theme/images/bf_lvmi.png” alt=”” /> We are transitioning to scheme-less URLs for everything. It allows users to choose HTTPS even if your site is served over HTTP by default.
- Request.Url.Scheme: I used to append the URL scheme used by the request when I was not sure if the client (rss reader, email, templates etc) would support scheme-less URL’s. But this has the disadvantage of not working with cached pages. So far, it seems that scheme-less URL’s are safe for all popular web clients.
I don’t think there was ever much sense in having the http://www. prefix in URI’s, so getting it down to just // is very nice.
How to find non-SSL resources on a page:
One frustrating debugging step for me used to be finding the http resources within a page. I would have to search for http resources in the source code. If the page references scripts that load other resources, this could get complicated. Fortunately, Google Chrome offers a simple solution – the network inspector can export information to a searchable JSON file:
- Open a new private browsing session in chrome (to disable your extensions, which may inject non-SSL links within the page)
- Alt-click and “Inspect element”
- Go to the Network tab
- Open the URL to inspect
- Right click inside the Network tab and “Copy all as HAR”
- Paste the JSON into notepad, and search for http:// resources
One last note: If you use third-party widgets or services which do not fully support SSL, please take the time to contact the vendor and request that they add full support for SSL.
You’ve probably heard about the “retina” displays on the iPhone 4/4S and the new iPad. These devices have double the display density of most other devices. The high-DPI displays of these devices are unique, but they won’t be for long. Most analysts are predicting that within a few months, Apple will introduce the same “retina” displays for their laptops as well. Once display manufacturers like Samsung and Sharp ramp up production, the rest of the industry will very likely follow.
In other words, we are facing the equivalent of the HD TV transition for personal computing. It will come to smartphones, tablets and then desktops. Speculating about the timeline of the transition is of course risky, but I suspect that there will be many high-DPI devices being sold by the end of 2012 – not limited to Apple. Certainly within a few years, we can expect the rest of the industry to follow. Because websites and applications can display content appropriate to the viewer’s hardware, they can gain a competitive advantage without imposing costs on non-HD visitors.
What this means in practical terms:
- You should start preparing double resolution graphics and video for new content, especially important elements like headers & front page content.
- If you target iPad or iPhone users, you should already be updating your website’s technology to support HD graphics & video.
- When initiating projects going forward, you should give increasing consideration to adding support for high-DPI resolutions.
Update: visual guide.
Some notes from a short presentation I gave on building quality software development teams:
- Effective teams start with good people. A business is not a charity and cannot wait for people to grow into the role required of them. Intelligence and inherent motivation cannot be taught. These and many other aspects must be screened for.
- But hiring good people is not enough. Getting the most of a development team requires certain environmental factors. I have organized them into three areas: internal/motivational, structural/organizational, and interpersonal/communication. Sometimes they will conflict with practical considerations, but we ought to take them consideration whenever possible.
- Instill a sense of professional pride
- Developers should take part in the technical design
- Provide interesting, challenging work
- Developers should own the technical solution
- Technical architects should be part of the development team
- Respect the developer time
- Provide a quiet environment dedicated to development work
- Buy the best tools for the jobs – powerful computers, large monitors, etc.
- Reward learning and exploration
- Take (reasonable) risks with new technologies
- Schedule time for self-education and information sharing
- Create a sense of project ownership
- Delegation “ownership” of functional parts to individual people
- Assign developers responsibility for follow-up maintenance (don’t just hand it off to a maintenance team)
- Hold people accountable for their work:
- Use a work unit tracking system (TFS, etc)
- Make task status publicly visible
- Hold daily stand ups (Scrum)
- Consider a public scrum board
- Provide clear project requirements
- Lean development approach
- No time-wasting tasks (useless documentation)
- Isolate developers from unrelated tasks (no business interruptions)
- Hold high expectations
- Monitor quality of work with code reviews
- Regular training & information sharing sessions
- Consequences for bad work
- Set well defined deadlines
- Don’t set arbitrary deadlines, but all work should have a deadline
- Developers should have input on deadlines for their work units
- Instill a sense of collective ownership of the project
- Hold architectural education sessions
- High-bandwidth communications
- Entire team should work in physical proximity
- Make quality visible
- Use continuous integration and automated testing to provide immediate feedback of quality
- Developers should fix their own bugs
- Track quality over time
- Explicit mentor roles
- Mentor roles should be explicitly defined
- Mentoring time should be scheduled into the project
From the Mises Blog:
A look at the Mises.org CMS I’ve maintained for the last 7 years.