If you are reading this, you have been introduced to something called the Terminal on your Mac by one of your overly pushy developer friends/colleagues.
I am thinking that the conversation went something like this?
You: How can I get to that file?
Them: Just open Terminal and then
$ cd ~/Projects/boilerplate/ && vi .gitignore
So I was presented with this interesting problem by a co-worker to come up with a CSS solution for a very common problem. Basically we are looking at a common layout for a list of items that will be placed into a grid with two columns. Simple, right?
Wrong. How do we do this? There are so many ways we can solve this problem that the solutions are a problem in itself. In this article I will walk through the process that I went through and how I came to a solution that I feel is pretty flexible and will carry us into the future of better layout solutions.
A VERY common solution is to pretend this is a table and think of this as a series of rows and columns. I personally think that this is a very poor solution, why would we want to recreate tables for the sake of creating a table layout? For the sake of argument, I will walk through how this works.
Web fonts are pretty much all the rage. Using a CDN for font libraries, like TypeKit or Google Fonts, will be a great solution for many projects. For others, this is not an option. Especially when you are creating a custom icon library for your project.
Rails and the asset pipeline are great tools, but Rails has yet to get caught up in the custom web font craze.
As with all things Rails, there is more then one way to skin this cat. There is the recommended way, and then there are the other ways.
Here I will show how to update your Rails project so that you can use the asset pipeline appropriately and resource your files using the common Rails convention.
Here is a quick rundown without all the typical blah blah blah ...
Create a new snippet, go to Tools > New Snippet
This step creates an empty file for you to enter your new code snippet into. It should look like the following:
<snippet>
<content><![CDATA[
Hello, ${1:this} is a ${2:snippet}.
I admit it, I have a print background. As much as I try to leave that all in the past, it always creeps up and bites me in the ass.
Pixel based image asset management is a mystery to many in print and in the new purely digital world. What constitutes a quality asset file to be reproduced? In print there are clear rules, but in digital display, there are many other variables at play. This post is a description of my journey in finally figuring this out.
With every image, regardless of intended output, it has three primary attributes; pixel width and height, physical width and height, and dpi. Of course there is color space, color profile and a few others, but that is outside the scope of this discussion.
As of just writing this, Express 4.0 was released and there are points in there that no longer matter. So, this remains as a great >4.0 article.
Node.js is the red-hot new hotness! You can't throw a stick on the internet without hitting someone talking about Node. But why? For one, it's built on JavaScript which is completely ubiquitous. So, why not build a development stack and server on JavaScript? I would argue that the installation is almost painless while the terseness of the language is not.
While you can create apps 100% from Node.js, the Express framework is a great tool that helps you solve many standard problems without having to write boilerplate code.
Node.js is here and it's not going anywhere anytime soon. So if you are new to Node.js, Express, and even JavaScript in general, this is a great newb's step-by-step guide to get started.
Not sure if you are in the same boat as I, but I could not find any good resource out there that pulled this all together. So here is a step-by-step tutorial for creating a Node.js app from scratch, adding in Grunt and then Node-Sass. Yeah, try and find good docs on Node-Sass alone :(
Hope this is of help!
npm init - create a clean node project"private": true, to the package.json so that your project is not globally distributed as a npm app
tl:dr - the following is a long rant about the complexities of presentation layer development as it collides with the growing complexities of JavaScript front-end frameworks. This is a summary of my experiences, issues and proposed solutions to today's world of client-side application development.
It was a trend with the traditional model of app development that the app dev team would take a particular dominance over the presentation layer, as it was rightly so, their domain. The deign teams of the time resorted to non-code ways of communicating their intentions as to influence the design. The 'comp' and 'red-line' documents were the primary resource of communication. Practices that are not all that dead, people still do this stuff you know.
We all know by now that these processes don't really work. They are fraught with error and caused countless hours of frustration between designers and developers. Witness the rise of the 'designer - developer' or 'The Designer w
Having spent the vast majority of my career in the front-end space, there has always been a thirst for better processes and management of resources. For those who have long histories with HTML and CSS, you remember the days of keeping folders of code snippets, our personal library of sorts, the cool code we wrote and wanted to have at the ready for our next project.
Sure there were desktop apps that tried to manage this for us, journler was my tool of choice back in those days. I have also seen some use Google Docs and other document and snippet managers, but they never really worked. And let us never forget all those really crappy websites that were supposed to be our saving grace. In the end, managing assets on the front-end has been nothing but a total fail.
When I began working with a Rails team, I was introduced to better solutions for managing libraries of reusable front-end code. Not to mention, this was my first exposure to Git and Github