Blog

Massive Magento Attributes

Published: March 27, 2015

Magento is often criticized for being slow. I won't lie, the first time I used Magento that was my reaction as well. But after more than a year working at a Magento Gold Solution Partner I've learned that with the right hardware, and software, Magento can run rather smoothly...most of the time.

A Workflow That Takes The Pain Out Of (Responsive) HTML Email Development (Using Laravel and Gulp)

Published: February 23, 2015

Tags:

Most front end developers would probably not list coding HTML emails as one of their favorite activities. From table based layouts, to inline styles, to popular email clients that still use Microsoft Word as a rendering engine it is understandable that HTML email development is generally considered a nightmare. Fortunately, starter templates and build tools make the process a lot less painful. In this post I'll outline a workflow I set up on a recent project that made HTML email development downright fun.

Dealing with WHOIS records

Published: January 4, 2015

Recently I've been working on a side project, Domain Clamp, a web app for monitoring domain and SSL expirations and sending notifications. The most unexpected challenge thus far has been dealing with WHOIS records. While SSL expiraton dates can be retrieved simply by asking the server on which the SSL is installed, there is no way to get a domain expiration date without asking a WHOIS server. And that, my friends, is where the trouble begins...

gh-pages: Make Sure CNAME Is In Your Repository Root!

Published: December 19, 2013

I recently ran into an issue when deploying WhatsPopularOnYouTube.com, an AngularJS app that displays a live feed of the most popular videos on YouTube.

The app was scaffolded with the Angular Seed Project, which offers a nice starting structure for Angular apps. When using the Angular Seed Project the document root for the app is the app directory, which is one level above the repository root.

app/
  css/
    app.css
  img/
  index.html ←-In app directory, one level above repository root
  index-async.html
  js/
    app.js
    controllers.js
    directives.js
    filters.js
    services.js
  lib/
    angular/
      angular.js
      angular.min.js
      angular-*.js
      version.txt
  partials/
    partial1.html
    partial2.html
config/
  karma.conf.js
  karma-e2e.conf.js
scripts/
  e2e-test.sh
  e2e-test.bat
etc…

Since the app doesn't involve any server side coding, and a database is not needed, I wanted to use Github pages for hosting. My original plan was to push the entire repository up to Github and put the CNAME file in the app directory, one level above the repository root. I figured this would work since I had seen something similar in the Jekyll repository, where there is a CNAME file in the site directory, one level above the repository root.

I pushed the repository up, with the CNAME file in place, updated the A record at my registrar, and refreshed the page for about 10 minutes, only to continue getting a generic Github 404 error. I re-checked the A record at the registrar, re-checked the spelling on in my CNAME file, but everything was done properly. Finally, after Googling terms like 'github pages CNAME subdirectory' and learning nothing, I decided to contact Github about the issue

Much to my surprise, I received the following response...

Your CNAME file definitely needs to be in the root of the repository.

So I made that change and within 10 minutes my site was up and running.

The point of this blog post is to help out anyone who might have a similar idea about putting the CNAME file in a directory outside of the repository root. For example, someone who has seen the Jekyll repository (which has over 13,000 stars on Github at the time of writing this), might be inclined to think that the CNAME file could be placed there.

Since all the searches I ran on Google provided no quick guidance on this issue, hopefully this blog post will help someone out.

Embedding YouTube Videos Without Sucking

Published: December 2, 2013

Tags:

Using YouTube to integrate video into your website is suspiciously easy. Just use YouTube's iframe embed code and voila, you now have shiny video player on your web page.

<iframe width="640" height="360" src="//www.youtube.com/embed/9bZkp7q19f0" frameborder="0" allowfullscreen></iframe>

However, there's a lot of suck that comes with embedding YouTube videos that way. "How much suck?" you might ask. Well, each YouTube video you embed will force your user to download roughly 400K of data, before they even click play.