Rails vs WordPress

At Alkami we specialize in Ruby On Rails and believe that for most of our target clients this is a great, cost effective solution for getting their MVP up and running within a reasonable timeframe. We are sometimes asked what the difference is between building Rails vs WordPress apps. Without fully understand what type of app they want, clients often assume WordPress would be a simple solution.

Many people aren’t aware of the differences between the two. Rails is a Module View Controller(MVC) framework for building things – it gives you a toolset that helps make rich web applications. Rails is built using the Ruby programming language, hence the combination Ruby On Rails. WordPress is an application in itself, built without a framework in the PHP programming language. So if the requirements of your application fall within the boundaries of what’s possible in WordPress then WordPress might be a good choice. But once you step outside those boundaries you will quickly hit a wall of what’s possible.



Ruby On Rails(ROR) is a web application framework written in Ruby. It is a MVC framework, providing default structures for a database, a web service, and web pages. If you’re trying to build a web based transaction processing system that heavily focuses on generating reports, Rails is the way to go. Point Of Sale(POS) systems are also great for Rails. We’ve also built quite a few e-commerce apps that our clients are very happy with. Rails has an amazing community of developers that post solutions to pretty much any problem one can encounter. Many programmers, no matter what language(s) they specialize in, reach for Rails when it’s time to build a RESTful API. Rails makes it super easy to build an API with minimum amount of code. Many of the coolest most badass applications on the web have been built using Rails: Airbnb, Bloomberg, Couchsurfing, Goodreads, Groupon, Hulu, and KickStarter just to name a few!



WordPress is a web software written in PHP that you can use to create websites that come packaged with a powerful admin panel. It’s no surprise, if you’re just looking to build a blog you should go with WordPress. Not to say that you can’t build a blog using Rails, cuz you most certainly can but it would take much more time/money to do so. WordPress has a very robust admin panel right out of the box! It would take a good chunk of time to rebuild all these nifty features in Rails. So if you’re just interested in a pure publishing platform that allows you to manage all of your content from an admin panel, certainly consider WordPress. 26% of all websites globally use WordPress.

Final Thoughts

If you’re just looking for a cheap basic website with publishing capability, you’re better off going with WordPress. WordPress has a very large selection of free to low cost themes you could choose from. WordPress also has a bunch of plugins like WooCommerce that will allow you to process transactions. Scaling and customizing your WordPress site is going to be more challenging and potentially more expenses unless you know PHP. Learning PHP, especially as your first programming language, can be very complicated. The community of Ruby On Rails developers is growing like wildfire. Ruby is arguably one of the simplest programming languages to learn. Building, customizing, maintaining, and scaling a Rails application is becoming very affordable. Many startup founders learn Ruby and Rails so they can better communicate with the developers they hire. There’s no right or wrong choice, it just depends on what type of application you want to build. At Alkami we have experts in both technologies and will advise you based on your requirements.

Minimum Viable Product (MVP)

A core component of Lean Startup methodology, developed by Eric Ries, is the build-measure-learn feedback loop. The first step is figuring out the problem that needs to be solved and then developing a minimum viable product (MVP) to begin the process of learning as quickly as possible.


Once the MVP is created, a startup can begin working on tweaking the product. Most adjustment should be made based on user feedback. If users don’t adopt the MVP, managers need to start asking pertinent “Why” questions in order to investigate the root of the problem. Why are visitors not converting to registered users? Why are users not opting to pay for extra features? Why are users closing their accounts in under a month? Questions like these can uncover structural problems in the product and potentially lead to a pivot or product course correction.

“Minimum” Is Deceiving

Don’t let the “Minimum” in MVP fool you, many entrepreneurs and successful businesses fail miserably at something that sounds very intuitive. A true MVP has a minimum set of features needed to learn from early users. The core purpose of building an MVP is to avoid building something no one actually wants. If you realize you’ve already built something no one wants, you can quickly pivot or drop the product all together so as to avoid depleting more resources. This is easier said than done. Companies with millions of dollars to spend on testing products are less attached to any particular product. Most of the entrepreneurs we do business with don’t have that luxury; precisely why we guide them toward MVP and steer them clear of costly features that their end users might not care for!

The Pivot


To Pivot is to change direction but stay grounded in what you’ve learned. Most startups fail but some fail early, pivot and create something great based on what they learned about their target audience. Some entrepreneurs think pivoting is in some way admitting failure and is bad, but failing in itself is not bad especially if you take all those lessons and apply them to the next iteration. Software developers understand pivoting really well and often welcome it. Building good software is about iteration, and it takes many iterations to get something right but when you get it right it usually sticks and doesn’t need to be changed for a long time.


Lean Startup Principles aim to deal with extreme uncertainty; the number one factor every startup deals with. Your product could be wicked awesome but until the market validates your assumptions everything is uncertain. The faster you build something and bring it to your users the faster you can validate your assumptions and decrease uncertainty. Spending a year(s) building something without constant user feedback is very dumb. Almost every popular application that exists today could be broken down into an MVP with minimum features and users would still use that product. Take away any 5 features that Facebook currently has and people would still use Facebook. Your product has to offer the bare minimum core features that your users need and want before you go slapping on various widgets to the program.

The problem with entrepreneurship is we are often working really hard producing high quality products that no-one wants. The creation of stuff is not valued.
– Eric Riles

Establish The Baseline


One of the most significant jobs of the entrepreneur is establishing a baseline for their product. Iteration 1 cannot contain all the bells and whistles, it cannot even contain most of them. Iteration 1 needs to be the product that crudely solves that one specific problem, nothing else. The baseline has nothing to do with cost, it has to do with speed. Sure it will most likely cost less to build a streamlined product but that’s not the ultimate goal; the goal is to go to market and learn from the target user. If you’ve noticed, I use the word ‘learn’ quite often. No matter how much knowledge you have about your target industry, you can’t possibly know how people will respond to your new product but you can certainly learn as much as fast as possible by establishing a product baseline.


Is it a web site? A web app? Or a native app?

Many people are still confused about the difference between common types of applications(apps). Everyone seems to understand what a web site is, but when you say things like not all web sites are web apps or most web apps are also web sites, eye’s tend to glaze over. Let’s break things down.

What’s A Web Site?


A web site is a location connected to the Internet that maintains one or more pages on the World Wide Web. These web pages are just documents, typically composed in plain text interspersed with formatting instructions of Hypertext Markup Language (HTML).

Typically a web site is just a bunch of static pages that display the same information for any and all visiting users. Web sites are primarily informational. Take a basic portfolio page for example, it just displays a user’s/company’s work, an About section, and other pertinent information that may help visitors understand more about the user/company. To view someone’s portfolio page doesn’t require you to login, there’s no input fields for you to submit personal information, and the content you view on the page is the same content your friend would see if she was to visit the site from her computer.

A basic static web site, like a portfolio page or a coming soon page, should not be called a web application because it’s not doing any heavy lifting; by that I mean processing and saving data. It’s just a bunch of static content that’s displayed to users.

What’s A Web App?


A web application will have things like user authentication(login), allowing users to log themselves in and view information they might have submitted or saved from their previous session. Sites like Twitter, Facebook and LinkedIn are great examples of web applications. These are essentially programs that runs remotely, and depend fundamentally on a processing and a data storage backend. Web applications have databases that save your information and display it back to you every time you check back in. Web applications are very powerful and are able to reach anyone that is using a web browser connected to the internet.

The reason people understand the term web site better than the term web app is because back in the olden days, early 90’s to be precise, there weren’t any web apps. Back then everything was a static web site. We didn’t have big user centric apps with all these nifty features; we had basic informational pages that lived on the web. Once we started hooking up databases to web sites and adding all of these user centric features web sites gradually became robust web applications. The problem these days is whenever people here the term app they immediately think about those icons in their smart phone, which are actually Native apps and that’s what we’re going to discuss next.

What’s A Native App?


As you may have extrapolated, both Web sites and Web apps live on the World Wide Web! We typically access the world wide web through a Web browser. A Web browser is a software application used to locate, retrieve and display content on the world wide web, including web pages, images, video and other files. You’re using a Web browser right now to view this blog post. You might be using Google Chrome or Safari or Mozilla Firefox but hopefully not the dying Internet Explorer!

A native application (native app) on the other hand is an application program that has been developed for use on a particular platform or device, like a smart phone operating on iOS. Because native apps are written for a specific platform, they can interact with and take advantage of operating system features and other software that is typically installed on that platform.

Native apps are Not accessed through a browser. If you have a smartphone you already have a bunch of native apps installed. Just look at all those icons on your home screen, those are all native apps you’ve either purchased through an app store or apps that came pre-installed. These apps are written for specific operating systems. If you have an iPhone you’re running iOS, Apple’s operating system. If you have some other type of smartphone you’re most likely running Android, which is an operating system that is developed by Google.

Because a native app is built for a particular device and its operating system, it has the ability to use device-specific hardware and software, meaning that native apps can take advantage of the latest technology available on mobile devices such as a global positioning system (GPS) and camera. But web browsers are becoming far more powerful and gaining access to smartphone cameras and GPS, you ever receive a pop-up in your browser asking for permission to access your camera or location?

Wrap It Up! No You Wrap It Up!

Web sites are just static pages on the internet, check out this classic. Web apps are dynamic pages that interact with a database. Native apps are stand alone apps that are native to your operating system and do not run in a browser. At Alkami we build web sites and web apps because we rarely encounter someone that absolutely needs a native app. 9.9 out of 10 times our responsive web apps meet the demands of the architect/entrepreneur.

Search Engine Optimization – Part 3

What’s the point of having a website if no one can find it? In part-2 of this wicked gnarly series we covered anchor tags, images, heading tags, robots.txt file, and re=’no-follow’. This is our final part and will focus on mobile.

Notify Google Of Mobile Sites

The world is going mobile! Mobile phones are everywhere and many users do most of their internet surfing on their mobile phones. As a webmaster, running a mobile site and tapping into the mobile search audience isn’t easy. Mobile sites require different management methods, which pose new challenging. While many mobile sites were designed with mobile viewing in mind, they weren’t designed to be search engine friendly. Let’s take a look at some troubleshooting methods that will ensure your site in crawled and indexed.


Create a mobile-sitemap, which is slightly different from the desktop site-map we covered in part-1. A mobile sitemap can be submitted using webmaster-tools just like a regular site-map.

Some mobile sites refuse access to anything but mobile phones, making it impossible for Googlebot to access the site. Google has a specific crawler for mobile called “Googlebot-Mobile.” If you’d like your site crawled, allow any User-agent including “Googlebot-Mobile” to access your site.

Once Googlebot-Mobile crawls your URLs, Google checks for whether each URL is viewable on a mobile device. Pages Google deams are not viewable on a mobile phone are not stored in Google’s mobile site index. This determination is based on a variety of factors that our out of the scope of those post. Here’s the best place to start for gathering more information.

Guide Mobile Users Accurately


Some companies like to build two separate versions of their website, one for desktop and another for mobile. The most common problem that arises with this scenario is mobile users land on the desktop version. Redirecting users to the mobile website is essential.

When a mobile user or crawler (like Googlebot-Mobile) accesses the desktop version of a URL, you can redirect them to the corresponding mobile version of the same page. Google notices the relationship between the two versions of the URL and displays the standard version for searches from desktops and the mobile version for mobile searches. -WebMaster Docs

Keep in mind that Google is not responsible for displaying the mobile version of your site in search results for someone using a mobile device. There’s many ways to enable Google search results to display the correct version of your site, but that’s a blog post of its own. The simplest way to solve this problem is to track a visitors User-Agent and provide a mobile user a link to view your mobile optimized site incase he/she lands on the desktop version.

At Alkami we don’t believe in building separate sites for different sized screens. We believe in building one responsive site using mobile-first design principles. What this means is we build you one site that looks and works great on any screen, and because we begin designing your site with mobile in mind you end up with a lean version that clearly gets your message across in as few words as possible.

Promote Your WebSite In The Right Ways


As we wrap up our final post of our 3-part series, I would like to beat the dead horse one last time by emphasizing the importance of positive promotion. Effectively promoting your new content will allow target users to locate your site. The more people discover and link to your site the more of a web presence you’re going to establish. Become a master at making announcement via blog posts. Write pertinent blog posts that speak to your target audience. Engage with your audience in as many positive ways as possible. Setup social media accounts for your business and share what’s going on in your ecosystem.

If you run a local business, adding its information to Google Places will help you reach customers on Google Maps and web search. The Webmaster Help Center has more tips on promoting your local business.


Search Engine Optimization – Part 2

What’s the point of having a website if no one can find it? In part 1 we discussed creating accurate page titles, making use of the description meta tag, improving structure of your URL’s, making your site easier to navigate, preparing a sitemap and offering quality content and services. Let’s continue our dive into the mysterious world of SEO.

Write Better Anchor <a> Text


Anchor text is the clickable text that users will see as a result of a link. It is placed within the anchor tag <a href=”…”></a> . This text tells users and Google crawlers a little bit about the page you’re linking to. Links on your page may point to other pages or your site or pages of other sites. In either of these cases, the better your anchor text is, the easier it is for users to navigate and for Google to understand what the page you’re linking to is about. The anchor text you use for a link should provide at least a basic idea of what the page linked to is about.

Optimize Your Use Of Images

How you use your images is important. All images can have a distinct filename and “alt” attribute, both of which you should take advantage of. Sometimes images can’t be displayed to some users, this is where the alt tag comes in handy; it tells the user what the image is about. Filenames are important as well, make sure to name your image files properly. Anyone should take a glance at the filename and have a good idea of what the image looks like or contains.

Use Heading Tags Appropriately


Since heading tags typically make text contained in them larger than normal text on the page, this is a visual cue to users that this text is important and could help them understand something about the type of content underneath the heading text. Use multiple heading sizes(<h1>, <h2>, <h3> etc…) in your document to create a hierarchical structure that visually separates different sections of your page.

Make Effective Use of robots.txt


A “robots.txt” file tells search engines whether they can crawl parts of your site. This file, which must be named “robots.txt”, is placed in the root directory of your site. You may have a page or a few pages you don’t want users to land on by clicking a link they came across while doing a Google search. You can tell Google to not display these pages in their search results in your “robots.txt” file.

Be Aware of rel=”nofollow” For Links


Setting the value of the “rel” attribute of a link to “nofollow” will tell Google that certain links on your site shouldn’t be followed. No-following a link is adding rel=”nofollow” inside of the link’s anchor tag <a>. This would be very useful if your site has a blog with public commenting turned on. Links within those comments could pass users to sites you might not agree with. Blog comment areas are very susceptible to comment spam. No-following these user-added links ensures that you’re not giving your page’s hard-earned reputation to a spammy site.

Most blogging services like WordPress automatically nofollow user comments, but those that don’t can often be manually edited to do this. This advice also goes for other areas of your site that contain user generated content. It’s ok to allow users the right to link to other pages from your site, just be careful and make sure these are pages you agree with. Google has interesting ways of identifying how spammy a page is, and your site’s reputation could be tarnished if you have many links to spammy content.

Search Engine Optimization Part 1

What’s the point of having a website if no one can find it? following the best practices outlined by Google, I’ve decided to summarize the basics in a 3 part series. If you follow the pointers in this series, it will make it easier for search engines to crawl, index and understand the content on your site. Over time this should lead to more visitors and better search rankings.

Create Unique, Accurate Page Titles

A title tag tells both users and search engines what the topic of your page is. The <title> tag should be placed within the <head> tag of your HTML document. Ideally, you should create a unique title for each page on your site. If you don’t have many pages on your site, one concise easy to understand title will suffice. Make sure to choose a title that effectively explains the content that’s being presented on the page. Avoid choosing a title that has nothing to do with the content on the page.


Make Use Of The Description Meta Tag

A page’s description meta tag gives Google and other search engines a summary of what the page is about. Whereas a page’s title may be a few words or a short phrase, a page’s description meta tag might be a  few sentences or a short paragraph. Like the <title> tag, the description meta tag is placed within the <head> tag of your HTML document. <meta name=”description” content=”accurately summarize the page’s content”> Similar to the title tag, make sure to avoid writing a description meta tag that has no relation to the content on the page.

Improve The Structure Of Your URLs


Creating descriptive categories and filenames for the documents on your website will keep your site better organized and it could also lead to better crawling of your documents by search engines. Also, it creates more pleasing to look at URLs for those that want to link to your content. Visitors may be turned off by very long and cryptic URLs that contain few recognizable words. URLs need to be relevant to your site’s content. You want to make it easier for visitors to remember them better. Instead of having a URL look like this: http://surfingtheglobe.com/blog/posts/january/nicaragua-adventure/235hgihng45h , you’re better off making it like this: http://surfingtheglobe.com/blog/nicaragua-adventure

Make Your Site Easier To Navigate

The navigation of a website is important in helping visitors quickly find the content they want. It also helps search engines understand what content the webmaster(site owner/manager) thinks is relevant. If you have a website deeply nested in the file structure of your site, you’re implying that the content of that page is not very important. Google likes to have a sense of what role a page plays in the bigger picture of your website.


You can ensure more convenience for users by using breadcrumb lists. A breadcrumb is a row of internal links at the top or bottom of the page that allows visitors to quickly navigate back to a previous section or the root of your site. Many breadcrumbs plug-ins/widgets have the root page as the first, left-most link and list the sections you visited before ending up on the the current page.

Prepare A SiteMap


An XML Sitemap file, which you can submit through Google’s Webmaster Tools or create one yourself if you’re using a static site generator like jekyll, makes it easier for Google to discover the pages on your site. Using a Sitemap file is also one way to tell Google which version of a URL you’d prefer as the canonical one (e.g. http://surftheglobe.com/ or http:// www.surftheglobe.com/).

Offer Quality Content And Services

This goes without saying but creating compelling and useful content will likely influence your website far more than anything else we discuss here. You’ve likely heard the mantra “Content Is King.” Users have a sense for good content and will likely want to direct other users to it by sharing. This could be through blog posts, social media outlets, email, or forums. Organic word-of-mouth advertising goes a long way in building your site’s reputation with both users and Google. Write captivating easy to read text. Stay organized around a topic you are passionate about. Create fresh content regularly; as often as possible because Google loves seeing a consistent stream of new content. And don’t forget to create content for Users not search engines! You’re primary focus should be the user, if users love it Google will love it!

So You Wanna Make An App? Start Wireframing!

What is wireframing?

A wireframe is an architectural blueprint for your web-site. Before contractors go to work building the web-site of your dreams, they need a clear vision into what exactly you’re trying to construct. How many pages is your site going to have? Each page should have it’s own wireframe. At a much deeper level, a wireframe is very useful in determining how the user interacts with the interface. So as you conceptualize your web-app always keep the end user in mind.

How do I begin wireframing?

Well first, get some inspiration! Visit your favorite web-sites but this time really think about how those sites are laid out. Most of them probably have a universal navigation bar (nav-bar), a body, and a universal footer that includes contact information and all the links typically found in the nav-bar. Here’s an awesome tool called Wirify that lets you view any page as a wireframe. Try it out on your favorite sites.

Unless you have some experience using UI/UX tools like Sketch or Adobe Illustrator, your best bet is to either start with a pencil and paper or use this nifty online tool called Balsamiq. Balsamiq has a huge library of reusable components which you can drag and drop very easily to design your wireframes. Forget about things like colors and typefaces in the beginning, just focus on boxes. At it’s core, a web-site design begins with drawing boxes and then later these boxes will be filled with things like pictures, buttons, links, icons, maps etc… The navigation bar is probably going to be on every page of your site so it’s a great place to start! It’s just a rectangle with a bunch of links/buttons inside of it. Focusing on the nav-bar first will force you to think about all the other pages you would like your users to easily navigate to.

Next is the body of the page. Since you’re starting out on the homepage, make sure to clearly inform the user of what your site is. It could be a 1-3 sentence mission statement or a collage of images that illustrate what it is the user has landed on. Depending on your concept, the body could be broken up into many sections/boxes each containing pertinent information. Same as the nav-bar, start out with one big rectangle and draw smaller rectangles inside of it with labels that refer to what type of content you would like inside.

Lastly, design the footer. Sometimes the footer is just a bigger version of the nav-bar. It’s bigger because it might contain a contact form, a google map with a location marker and/or a quote. Think of it this way, after a user scrolls through your site and reaches the bottom you want to provide a way for them to continue the journey or you want to facilitate some kind of call to action. The last thing you want is a user scrolling to the bottom, losing interest and just leaving. Providing a bunch of options will help you retain attention.


What should I focus on when I’m wireframing?

Focus on user experience. If you show any one of your friends your black and white simple wireframe and they can’t understand how to get from one page to the next, you’re doing something wrong. Every good web-application has a flow to it and it’s almost impossible to get lost or not know where you are. If it’s an e-commerce site the flow is going to be designed to make the transaction process as simple as possible with the fewest amount of clicks. There’s this rule of 3-clicks that many companies have adopted, it states that your product(s) should never be more than 3-clicks away from the home-page. In fact, the fewer web pages you have the better. Usually, having a separate page just for user login is unnecessary; you can have the user login from any publicly visible page.

What kind of notes should I add to my wireframe?

If your wireframe is exceptional, which is rarely the case, any web-developer will review it and very quickly grasp what you’re trying to accomplish. Notes are great for letting developers understand what data you want to be visible on these pages and how a user is going to request certain data. Logged-in users will typically be able to view more information than non-logged-in users. When a user clicks a link that’s part of an accordion-like-element and that accordion section opens up, what data would you like to be rendered in that section? Does that data depend on other factors e.g. other users or time of day? Well placed notes could be very informative to developers. The more complex behavior your app exhibits the more notes your wireframes need. If you feel like notes are cluttering up your app, create a separate page(s) for notes.

Wireframes usually start out simple and could end up looking something like the sketch below, but it’s important to start out from a very high level perspective and gradually work your way down.



Static Site Generators?

What’s a dynamic site?

A dynamic site runs a server side scripting language(PHP, Rails, Pearl) to dynamically create the page being requested by each user. The pages on your WordPress-powered blog are built on the fly! Database queries are run to get the different pieces, such as the title, content, or links. These are then returned and processed by PHP for EACH request. Every time a user visits one of your pages fresh HTML, styled by CSS and made fancy-shmancy by JavaScript, is built and served to the user.

In any app, or any part of life, there’s always a problem/limitation. What’s the problem with this? The problem is if you have one particular page getting requested again and again, and nothing is changing on the page itself, all that dynamic creation of that page over and over… can lead to resource usage problems on the server. Let’s say for instance this page you’re currently viewing is getting requested 1,000 times an hour because I dropped some gossip about Justin Bieber. Each time this page is requested the server has to run a script. It’s basically a waste of computing power!

What’s a static site?

A static website is a site in which the information stays the same over a relatively long period of time. With a static website, you simply have the raw HTML that creates your page in a file on the server. A user’s web-browser will just directly request that specific file, and all the server has to due is hand it off as is without running a script. A static website consists of a series of HTML files (that require CSS and JS files), each one representing a physical page of a website. So on static site, each page is a separate HTML file. When you visit the homepage, you are viewing the actual homepage file. Even if two pages contain a chunk of identical content, e.g. a nav-bar, they both contain the same code for the nav-bar. So, if you want to update the nav-bar, you must do so in multiple files. This is fairly straightforward and it’s how all websites were built during the early hay days of web. The days when being an HTML developer meant 6-figure salaries and high potential for start-up immortality. These days no-one will even hire you as a junior developer without a fundamental understanding of multiple languages and frame-works. With my current web-dev skills, I could have probably freelance consulted for Fortune-500 companies in the early 90’s…. sigh, Anywayz.

How are they different?

Static site generators like Jekyll read some local configuration files, and build all of the HTML, CSS, and JavaScript on your local machine before deploying everything to your remote server. This actually makes your server administration much easier, safer, and faster.

Browsers read HTML, CSS, and JavaScript natively. Every other language is used to generate these three types of files. Static sites are created from hard-coded static files that do not rely on any server processes (unlike PHP, Ruby, Python or any other server-side language). Jekyll, a very popular static site generator, relies on the editor’s local environment to generate the static files that will eventually be deployed.

Wait… What?
Say, for example, you have five blog posts in your WordPress blog. When you visit http://yoursite.com, excerpts from these five posts show up on your home page. You click on a link to take you to the full post page. Each of these pages is served to your browser as HTML, styled by CSS; you may or may not have JavaScript that helps define some interactive behaviors. But every time you/user visit each page a PHP script in being run on the server.

What are my options for a static site?

Too many to list but here are some of the ones I find interested.


Jekyll is a parsing engine bundled as a ruby gem used to build static websites from dynamic components such as templates, partials, liquid code, markdown, etc. Jekyll is known as “a simple, blog aware, static site generator”.

Octopress is a static blogging framework built on top of Jekyll. It uses scripts to build static files to be deployed to a server.

If you’re looking for sheer performance, Hugo should be at the top of your list. It has plenty of features, but its biggest draw is that it’s built with Go — a language famous for its speed. If I were starting a blog with a frequent publishing schedule and the expectation of thousands of pages, I’d choose Hugo.

Hexo is a fast, simple and powerful blog framework powered by Node.js, that supports multi-thread generating, so hundreds of files take just seconds to generate. Your posts are parsed with Markdown which then generates static files, with installation taking just a few minutes.

I’m a Ruby on Rails developer, so tools like Jekyll and Middleman are super attractive to me. If, however, you’re a Python kind of girl, then check out Pelican — the most popular static blog generator built with Python.

Fairly new open source tool that seemlesly integrates with GitHub pages. All you need is a GitHub account and unlike all the other blogs I mentioned, you have access to an online admin panel, where you can write your blog posts. Pretty awesome feature if you ask me.


Foundation-Icons and Google Fonts

In the last post I outlined what the Asset Pipeline is, how it works, and why it’s important. This post I’ll explain web-fonts, icon-fonts, and how to get both to play nice on Heroku in your asset pipeline. I’m going to assume that you use Sass for your stylesheets and every one of those stylesheets have the .scss extension. So make sure you have the sass-rails gem in your Gemfile. Since Rails 3.1, new Rails projects will be already configured to use Sass. Let’s rock!

What are Web-Fonts?

Web-Fonts are fonts that don’t exist on your system, they exist on some server somewhere. They’re downloaded by a user’s browser while rendering a web-page, kinda like linking to a remote image that you don’t have saved in your local environment. Web-Fonts can slow your sites load time because they have to be requested from somewhere. Optionally you can usually download a web-font and add it to your project, if you want to maximize performance.

Integrate Web-Fonts into my app please

Google recently released this sweet Web-Font: Lily Script One. And I wanted to take it for a test drive. @import allows stylesheets to import other stylesheets, it’s basically a link. So google provides this link: @import url(http://fonts.googleapis.com/css?family=Lily+Script+One); The classic newbie(myself) mistake is to throw that to the top of the stylesheet you happen to be using for styling these icons, wrong! You want to throw that @import link into your scss manifest(applications.scss).

What are Icon-Fonts?

Icon-Fonts are just fonts! However, instead of containing letters or numbers, they contain symbols and glyphs. You can style them with CSS in the same way you style your regular text which has made them very popular on the web. Icon-Fonts have so many awesome features like easy size, color, and shadow manipulation. You basically style these icons the same way you would style Text-Fonts. I’m going to show you how to add foundation-icon-fonts-3 to your asset pipeline, but will a little shimmy-ing this technique will work for any icon-font set.

First visit the foundation-icons link above and download the whole set. You’ll get a foundation-icons folder with a bunch of files and an svg sub-folder. Copy the whole foundation-icons folder and paste it inside the assets folder of your Rails project. Change the name of the folder to “Fonts”, Rails convention. Inside your Fonts folder add .scss to your foundation-icons.css. In fact, all of your .css files should have a .scss extension. This allows you to use both css and scss syntax(like nesting) inside your stylesheet and the Sass pre-compiler works its magic.

Next, open your fondation-icons.css.scss and notice how it’s @importing a bunch of other files with funky extensions (.eot .woff .ttf). For development this will work fine but for production this will not compile properly. We need to tweak the paths to look like this:

Don’t hold me to this, but what I believe is happening is this is creating relative-path url’s for each of the files. E.g. url(/assets/fonts/foundation-icons.eot). Last thing left to do is require this file in our stylesheet manifest(application.css.scss) like so:

Honestly, I figured this last part(*=require) wasn’t necessary. The Fonts folder is in the right place and the foundation-icons.css.scss file is importing everything it needs. I tried many many different ways to make these font-icons work both on my local server in development and in production. Foundation docs discuss nothing about integrating font-icons into your asset pipeline, even though they tout how compatible their framework is with Rails. What I’m doing works both locally and on Heroku, and I really don’t feel like digging deeper into the abyss.

Enter Font-Awesome!

In Rails projects the awesomeness of font-awesome is unmatched. All you need to do is add their gem, yeah they have a gem!, to your Rails gemfile and import their icons like so:

That’s it! That simple

Asset Pipeline

I once spent roughly 3.5 hours trying to figure out why my custom google font and foundation-icons-3 would not render in production on Heroku, and you know what? I learned a lot! Turns out there’s this thing called the asset pipeline, not the kind you’re offered at a rave or the world class Hawaiian reef break, and it determines whether your Rails app is worthy of style when you push it to your production server.

Turns out, the asset pipeline is one of the simplest and least understood rails features for developers. Instead of me just telling you how to make your custom web-font and font-icons work on Heroku, which I will in part-II, I rather compress the brain-drain I just experienced into something of value. Keep in mind this is just a high to mid-level overview, we’ll get into more tricky aspects in part-II.

What is the asset-pipeline?

Your Rails application has a folder called “assets”, assets are just all of your css, javascript, and image files. Think of it as everything that’s going to turn your plain ol HTML page into a stylish, interactive beauty. The asset pipeline serves 3 very important purposed: precompiling higher level languages, concatenating assets, and minifying files.


The only native language to most browsers is JavaScript, but browsers also have HTML and CSS parsers. These are lower level languages for the browser. Your stylesheets written in Sass and scripts written in CoffeeScript have to be pre-compiled(translated) into these lower level languages for the browser to properly render your pages.



Any file you create inside the assets folder essentially becomes part of the asset-pipeline, but you should stick to convention and add CSS files to the stylesheets folder and JS files to the javascripts folder. There’s 2 dominant files you need to pay attention to: application.js and application.css. These files are called Manifests, no relationship and not nearly as destructive as the Manifest Destiny. Essentially each of these files pull in(concatenate) all other files with like extensions. It’s actually the Sprockets Gem that’s doing this magic. For example, if you have 5 custom CSS files inside of Assets, the application.css is going to pull in all of those files and create one big file. How? The require_tree . directive, inside the Manifests is a command that says “get over here all you like files.” The require_self directive just says: “every bit of code inside this Manifest file is gonna join the party as well.” Why? Because concatenating things into one file for the server to hand to the client(browser) improves Performance! In the JS Manifest the directives begin with //= and in CSS with *= , they essentially do the same thing.



Lastly, the asset-pipeline is responsible for minifying these Manifest files. Think of how much extra space and comments each one of your stylesheets and JavaScript files contain, and picture removing all of that, that’s what a minified file looks like. Long variable names are also chopped down. The functionality ends up unchanged, the code is just smooshed together like that house party I was at last week. Why minify? Performance!


Awesome, but how does your application actually find these Manifest files? Magic! Along with link_tags inside your application layout: app/views/layouts/application.html.erb. Consider this file a universal default master file for all the views. It’s sorta like a Manifest file in the sense that it pulls all of the HTML from each one of your view files into itself by way of <%= yield %> (if you’re using erb as your templating language). We link stylesheets and scripts in the <head> of this file like this: <%= stylesheet_link_tag “application” %>. This points to the Manifest CSS file.

Sometimes just the order in which you require files might be incorrect, which causes certain files to override others. This is quite possibly the most important and overlooked section in Rails docs:

Directives are processed top to bottom, but the order in which files are included by require_tree is unspecified. You should not rely on any particular order among those. If you need to ensure some particular JavaScript ends up above some other in the concatenated file, require the prerequisite file first in the manifest. Note that the family of require directives prevents files from being included twice in the output.


In conclusion, you’re application layout file has a link pointing to your Manifest files. These Manifests should already be requiring all of your assets in the order in which you intend. Roughly 90% of problems I’ve seen people have with the asset pipeline come from improperly requiring files or frameworks from within their Manifests.