00:00:30.480
Hello everyone, today I want to take you back to the early days of the web with Tim Berners-Lee. Early in the web's history, we didn't have dynamic applications; all we had were static files. The first thing Tim Berners-Lee put together was just some basic HTML, some links, and some rudimentary calls to an HTTP server that ran on the NeXT workstation sitting on his desk.
00:00:44.879
As we started with static websites, we quickly began looking at other options. We explored the possibility of generating content on the fly or via scripts, which allowed us to know simple things like whether or not there was coffee in the CERN's charging room without having to physically go down the hall. We utilized different scripts to generate information about the weather and other data. We learned how to write web applications using technologies like CGI, Perl, and shell scripts, allowing for dynamic content generation as part of the request-response cycle.
00:01:14.320
These applications grew increasingly complex and, as they did, we found ourselves needing databases to manage the amount of content that needed to be presented. In today's landscape, we're making use of various data stores, including NoSQL databases. However, what we are learning is that scaling these applications can be quite challenging. You may start with a web server and a database on your laptop, but as you push applications out, you might find you need additional web servers and database replicas. Soon, this small infrastructure can turn into a management nightmare.
00:02:08.640
In certain cases, certain large services like Twitter, Facebook, or GitHub require such complexity to handle their traffic effectively. Sometimes, for specific campaigns, such as the ones run by the Obama administration, this complexity is necessary to track and manage user engagement effectively. However, not every project needs that level of complexity. Sometimes, it's possible to generate simple static content without requiring a full database or data store, relying instead on information pulled directly from the file system.
00:02:51.680
Thanks to providers like Amazon, we have access to cloud services that allow us to host our sites without worrying about setting up our own servers or managing instances directly. Today, I want to discuss a tool called Middleman that simplifies this process and allows us to easily create data-driven static websites.
00:03:20.319
Middleman is a static site generator and, if you are part of the GitHub community, you may already know about other generators like Jekyll, Hugo, or others. The great thing about Middleman is that it is built on top of Sinatra, which is a lightweight web framework that integrates nicely with Rack. Middleman focuses on the viewing layer, allowing us to create layouts, templates, and partials, much like what we've become accustomed to with Ruby on Rails.
00:03:39.519
In Middleman, we deal primarily with the building of views, as opposed to controlling data from a database. Since we aren't relying on a database, Middleman emphasizes how to build out the presentation layer. As developers, you're already familiar with working with templates, layouts, and partials, especially if you've transitioned from Rails development. Additionally, we have access to view helpers that help us maintain DRY principles in our templates.
00:04:20.000
Middleman supports several templating engines which make it flexible for developers with varying preferences. If you have experience with Rails, you are already accustomed to using ERB for templating. You might also enjoy alternatives like HAML, which minimizes clutter in your markup. Markdown is another excellent option if you are dealing with strictly content-driven pages. In my blog, for instance, I utilize Markdown for content since it allows me to focus on writing content without worrying about HTML tags.
00:05:01.199
One notable feature of Middleman is its composable nature. For example, you could easily integrate ERB within your Markdown templates to insert dynamic values before converting them to HTML. The processing occurs in a way where ERB statements are evaluated first, and then the processed Markdown is handed off to generate the final HTML output, allowing for powerful and flexible content generation.
00:05:51.760
Although we don't have access to a database when deploying our Middleman site, we do have access to data. I'm excited to dive deeper into how we can utilize that data. Configuring Middleman is straightforward since it is driven by a configuration file. As you don't have controllers to manage, you can simply define settings in the config file specifying different paths and extensions to utilize while building your site.
00:06:09.760
As an example of the development cycle, let's say you want to build a site with some content. I have a simple example of a team page that I assembled for this talk. It is straightforward, comprising an index page with a few pictures and links, as well as some detailed pages. This entire site is data-driven and currently running on default.
00:06:56.480
When I run the Middleman server, it boots up a Rack application, loading all middleware that I have configured in the application's configuration file. You interact with it just like any other Rack application, whether it’s an ultra application or a Rails app. At this point, it's still dynamic, meaning you can see it generating content on the fly.
00:07:28.839
Middleman also has a feature called front matter, which is an excellent way to set page data, such as titles, layouts, and tags at the beginning of each content file. This metadata can be incredibly useful to dynamically load specific content into your pages. So, if you prefer working with JSON, Middleman also supports it, allowing you to structure your data as needed.
00:08:01.040
When we use Middleman, we can harness actual data to build out our site. This can include local data, which is a set of JSON or YAML files that you can manage within your project. This data is accessible via the data helper, making it very convenient to integrate into your designs. The data might come from a file like team.yaml within the data directory of your project.
00:08:37.959
The provided YAML file can contain various fields that represent team members, including their names, titles, bios, and links to their profiles or images. As you build your project, you would loop over these data items for each team member to generate the corresponding sections on your team page. This dynamic rendering is what makes using Middleman truly powerful and flexible.
00:09:01.360
Once you've rendered your pages, they come to life with the actual data pulled from whatever data structure you’ve defined. You can easily make adjustments, and the changes will reflect on the generated pages. Should you choose to update any team member's information, you can modify the data file, and the next time it renders, it will display the new content.
00:09:41.840
For example, I can change my name to Fred Gene, and when I refresh the page, it should reflect the updated information. The dynamic capabilities of Middleman allow content changes to be reflected instantly, which is extremely beneficial during development. This setup enhances the development experience and promotes a smooth workflow.
00:10:12.200
As you prepare your site for deployment, you will want to package it into static HTML, CSS, and JavaScript files. Middleman provides tools that allow you to do this effectively by booting up the application, going through a sitemap, applying various extensions, and generating optimized static content you can then serve to users.
00:10:55.840
In preparing your site for production, Middleman can apply various optimization techniques, such as minifying CSS and JavaScript, compressing images, and removing any unnecessary whitespace from your HTML files. It also optimizes assets management, ensuring that paths to your assets are appropriately handled.
00:11:31.600
By utilizing gzip compression for text content, you can save bandwidth while improving load speeds for user access. Once you complete the build, you'll have a full site ready to serve, but shouldn't forget about how to publish it so that users can access it through a web browser.
00:12:05.920
To deploy your site, you’ll want to sync it to a service where the public can access it. For example, using Amazon S3, Middleman can be configured to push your built files directly to your selected S3 bucket, making it incredibly simple to share your content publicly.
00:12:42.880
Once the configuration is in place, which might include your AWS credentials and bucket configuration, you can go ahead and publish, and S3 will manage syncing the updates as necessary. It figures out what needs updating and applies access control lists appropriately, ensuring that users can view your content without complications.
00:13:05.760
One of the benefits of utilizing S3 is its capability to serve static content easily, acting like a web server without much overhead. With your URL correctly set, users can access your website directly from the S3 bucket, provided you have the correct DNS settings in place.
00:13:43.839
Mapping your domain through a DNS service can help make accessing your website more user-friendly. By ensuring that your host name matches the S3 bucket name, you allow for a seamless routing experience. Ultimately, serving content through S3 gives users a reliable way to find and interact with your web pages.
00:14:20.000
To conclude, we have gone through the workflow involving Middleman to build a data-driven site, an example of which is a simple team page. We took it from development through and ultimately packaged it with HTML, CSS, and JavaScript, then published it to the web for users to interact with. We may not return to those early static days, but with the right tools, we can create dynamic and engaging web experiences.
00:15:00.000
Thank you for your time. I'm Frederick or Fred Jean. Feel free to reach out to me through the links shown on your screen.