This extended category features articles on client-side and server-side programming languages, tools, frameworks and libraries, as well as back-end issues. Experts and professionals reveal their coding tips, tricks and ideas. Curated by Dudley Storey. Subscribe to the RSS-Feed.
Whether you’re in a Fortune 500 company or part a two-person team launching your first web app, email is one of the most important tools for reaching your customer base. But with the ever-growing number of emails to send, getting them all out the door can seem a little overwhelming.
By putting in place a solid email design workflow, you’ll be able to regularly ship engaging and mobile-friendly emails with ease.
I recently migrated my blog from WordPress to Jekyll, a fantastic website generator that’s designed for building minimal, static blogs to be hosted on GitHub Pages. The simplicity of Jekyll’s theming layer and writing workflow is fantastic; however, setting up my website took a lot longer than expected.
In this article we’ll walk through the quickest way to set up a Jekyll powered blog, how to avoid common problems with using Jekyll, how to import your content from WordPress, use your own domain name, and blog in your favorite editor, how to theme in Jekyll, with Liquid templating examples, a couple of Jekyll 2.0’s new features, including Sass and CoffeeScript support and collections.
Like most web developers, I spend my days giving instructions to computers. These instructions generally involve some input (a request for a web page), some logic (get the right content from a database) and some output (send the content to the requesting browser). This process of telling a computer how to perform a task, such as generating a web page, is what we commonly call “programming,” but it’s only a subset of programming: imperative programming.
There’s another type of programming, declarative programming, that most web developers also use every day but don’t often recognize as programming. With declarative programming, we tell a computer what, not how. We describe the result we want, and the details of how to accomplish it are left to the language interpreter. This subtle shift in approach to programming has broad effects on how we build software, especially how we build the future web.
Front-end development is no longer about individual frameworks. Tools are available — we merely have to choose. To make the right choices for your project, you need to start with a general approach, or methodology. But most methodologies have been created by big companies? Are they still useful for small companies, or do we need to reinvent them at a small scale?
You probably already know of BEM, one of those methodologies developed by a big company — namely, Yandex. BEM posits that three basic entities (blocks, elements and modifiers) are enough to define how to author HTML and CSS, structure code and components, describe interfaces and scale a project up to an industry-leading service.
It's one thing to create a web application and quite another to keep it accessible — independent of the device that the user is using and its capabilities. That's why Heydon Pickering, now the accessibility editor on Smashing Magazine, wrote an eBook Apps For All: Coding Accessible Web Applications, outlining the roadmap for well-designed, accessible applications.
This article is an excerpt of a chapter in the eBook that introduces many of the ideas and techniques presented. Reviewed by Steve Faulkner, it's an eBook you definitely shouldn't miss if you're a developer who cares about well-structured content and inclusive interface design. – Ed.
Because the W3C’s mission from the outset has been to make the web accessible, accessibility features are built into its specifications. As responsible designers, we have the job of creating compelling web experiences without disrupting the inclusive features of a simpler design.
Functional programming is the mustachioed hipster of programming paradigms. Originally relegated to the annals of computer science academia, functional programming has had a recent renaissance that is due largely to its utility in distributed systems (and probably also because “pure” functional languages like Haskell are difficult to grasp, which gives them a certain cache).
Stricter functional programming languages are typically used when a system’s performance and integrity are both critical — i.e. your program needs to do exactly what you expect every time and needs to operate in an environment where its tasks can be shared across hundreds or thousands of networked computers.
SmashingConf isn't the eighth wonder of the world, but we are pretty close. Join us at SmashingConf Oxford on March 16–19 or meet us at the shores of Santa Monica for SmashingConf LA on April 27–30. You won't be disappointed.