This is a play-by-play screencast of me moving a component out of SSToolkit into its own library. I cover setting up a good open source component, writing Core Graphics drawing code, a bit of low-level C stuff, and some of my workflow.

You can find the code so far for this on GitHub: github.com/soffes/SAMGradientView We’ll be adding a lot more in part 2.

Here are some things I mentioned:

• SSToolkit: sstoolk.it
• SAMBadgeView: github.com/soffes/SAMBadgeView
• Three20: github.com/facebook/three20
• NimbusKit: nimbuskit.info
• My blog post on ARC: sam.roon.io/automatic-reference-counting

Also note, this video is to give you a sense of how I work and hopefully teach you stuff along the way. There are a few edits. Mainly to save you time. I cut out about 12 minutes of me wasting time. There wasn’t anything of value you missed out on I promise. I’m just looking out for your time

I’d really love some feedback. Leave a comment here or tweet me at @soffes on Twitter.

The post Setting Up Open Source and Live Coding with Sam Soffes – Part 1 appeared first on Treehouse Blog.

I’ve been working on a project called Monocle these past few weeks, and it’s time to show it to the world.

Monocle is an experiment in creating a friendly and intelligent community around sharing quality content with a focus on technology, startups and frankly anything that appeals to the inquisitive mind.

Philosophy

Over the next few weeks I’m going to be writing about the more interesting aspects to Monocle, but for now I want to talk about the motivations behind it.

The motivation for developing Monocle was to create a friendly and safe place for ideas and feedback. Criticism is kept to the constructive variety, and social accountability is provided by linking your Twitter or GitHub accounts.

There can be too much negativity in the tech community. It seems the average response to someone out on a limb, showcasing their latest idea or startup, is one of snark and derision. That is no way to foster an entrepreneurial spirit. Monocle is an attempt to remedy that.

Implementation

When an article is added, a summary of the content and an image is pulled in. Speed is critical: search is practically instant, posts are pre-loaded and pages pre-rendered. There are keyboard shortcuts for practically everything (press shift + ? for help), and there’s also a mobile optimized version.

Monocle’s beautiful design is done by the talented Greg Cooper. The backend is all Sinatra, and the front-end uses a custom MVC framework and templating library.

Next

Users can post links, comment, and browse articles. For the moment, you need a beta invite to contribute, but everyone can read the content.

I’m incredibly excited about the direction Monocle is heading in. The key component is in its community, and I look forward to seeing it grow.

Check it out: http://monocle.io

Whilst many designers embrace flat design wholeheartedly, it seems a growing number have already tired of its charms and are casting around for the next big thing.

One contender, being championed by some, is “long shadow” design.

Long shadow design produces an effect like looking at an object late on a Winter’s day, when the shadows lengthen to dramatic proportions. The effect adds a great deal of depth while still retaining an essentially flat aesthetic.

Typified by a 45 degree shadow that extends well beyond the length of a traditional drop shadow, the diagonal lines are reminiscent of early Soviet posters and collages by the likes of Malevich — produced before Socialist Realism became the only acceptable style. It is a similarly positive, ambitious and idealistic style, which is great for icons and branding.

It’s going a little too far to suggest that long shadow design is a solution in itself; it’s simply a development within the larger flat design trend. We’re likely to see many more developments, both revolutionary and evolutionary, before flat design is abandoned in favor of something new.

Whilst not a solution in itself, long shadow design is perhaps a route towards flat design 2.0, and certainly offers a way to introduce drama, tonality and depth to flat design. Used sparingly it can be a highly effective tool.

What do you think of the long shadow trend? Have you used it in a project? Let us know in the comments.

eBook: How to Grow your Business on Twitter – only $9!

The following is a guest post by Brian Kardell. Brian wrote me after I linked up Hitch.js a few weeks ago to give me more insight. It's pretty interesting stuff, so I thought we should share that here. Hitch is an artifact of a larger "Extensible Web" movement, including a manifesto, community group, and funny word.

What is Hitch.js exactly?

Hitch is a proof-of-concept “prollyfill engine” (we'll define that later) specializing in CSS selectors. It gives you jQuery-style selector plugins right in CSS itself. It’s based on proposals from the CSS working group list a few years ago by Yehuda Katz, myself and a few others as well as some very long email threads with Google’s Tab Atkins and Mozilla’s Boris Zbarsky. During the discussions I found myself wanting to prove something, so I’d write a little code. In the end I worked with my friend Clint Hill stringing it together and re-working it into a usable open-source project that might give developers some immediate value. That's Hitch.js.

Has it done that?

I think so. It’s done a few things: First, it shines some light on yet another example of what Alex Russell and Yehuda Katz are talking about in the Technical Architecture Group about a need for layering the design of things and how, for a lot of things, developers wind up re-implementing things that the browser already does much better because we’re sealed off from at high levels and we can’t tweak just one piece. In CSS, we’re missing some primitives and good extension points along the way. It is surprisingly difficult to add this sort of thing. It has also helped to convince certain key members of the CSS Working Group that CSS needs some things like this. Tab wrote about it on his blog in a New Year’s Resolution post. I am pretty confident that we will wind up with some good new abilities in CSS like in the next few years. Until that time, we have Hitch.

What would you really use it for?

This is the key question, whether it was provided via Hitch or natively, what could you do with this new found power? I think you could help change the Web forever. I know that sounds big, but I think it is. We could use it to help better the whole model of how we think about standards. Consider this: CSS 2 became a W3C Recommendation in May 1998. We might still think of “CSS 3″ as being something relatively new – but actually they published the first draft for CSS 3 in August 1999. Way back then, they were discussing way more selector power than is in CSS Selectors Level 3 today. Think about that for a moment. If you were a toddler when they started CSS 3, you would be graduating from high school now. There are a lot of reasons for that, but even if that is artificially long by a factor of 5, it still means that you have to wait a few years for something to make it through the process until anyone really gets to use it. Then it’s sometimes only in nightlies, or behind a flag, so you can’t really use it for anything “real”. Historically then it would be added behind a prefix and a few daring souls might start using it, but it’s hard because it only works in a few browsers. That meant that realistically it was a few more years out until it is usable by a wide enough audience to find out that, actually “I don’t care for half of these selectors and why didn’t they do X instead?” This is exacerbated by the fact that once it is that far, you are really hard pressed to convince anyone to change it because that means potentially “breaking the Web” as they like to say. In a word, that sucks.

How would it help change that? Is this related to the Extensible Web?

What if, instead of that model, I could let you use CSS Selectors Level 4 or 5 – or any proposed selectors right now in a way that was reasonably performant and you could know that the implementation wouldn’t change out from underneath you? It should be possible right? If we use polyfills to “fill the gaps” providing reasonable implementations for standards on the least capable older browsers then why not build reasonable implementations of the proposals in the first place that work on modern browsers – prollyfills - so that we could evaluate, iterate and compete. If we did, we could cut to the chase right? You could complain that they were no good now before they went any further. If we did it out in public on GitHub, you might even be able to fork them and make them better – and you probably would, because, lets face it: Way more people use GitHub than participate in Web Standards discussions. We might even collect data on use, complaints, stability and vendor reviews to determine when one is “baked” enough to worry about moving on to native implementations and prioritize them quickly.

Can you give me some examples?

Let’s say there is something in the Selectors Level 4 proposal that you think might be useful, like the :local-link pseudo-class which lets you select links that are within your domain and at varying URL levels (as you often have in navigation links). Is it? Are you sure you even understand it? With Hitch, we can develop a prollyfill for that and share it – in fact, we did - you can view a demo of it. That means you can actually use it for something real today. You can help make it better too, fork it on GitHub and improve it you can send me a pull request, share your use cases, open issues, or add some reftests. Any feedback that you send, we will relate up to the CSS Working Group.

Here's an even more simple example. We'll make a selector that only selects external links. First link up the Hitch.js:

<script src="http://hitchjs.com/dist/hitch-0.6.3.js"></script&gt;

Then use the Hitch syntax for adding a new selector. We'll make sure the hostname of the href matches the hostname of the window.

Hitch.add([{
      
      type: 'selector',
      name: '-links-external', 
      base: '[href]',
      filter: function (match, argsString, o) {
        if (!match.hostname) {  
          return false;
        }
        return match.hostname !== window.location.hostname;
      }
      
    }]);

Then we can use the name we set up there in our CSS. Note the special attribute on the CSS that ensures Hitch parses it.

<style data-hitch-interpret>
      a:-links-external() {
        background-color: yellow;
      }
    </style> 

Check out this Pen!

Or, let’s say that you had a proposal for a selector that isn’t in any draft: You could write a prollyfill and submit a draft by creating a git just like the one above and share it with the CSS Working Group. In fact, this has happened already and you can read about it in our post About :time – Taming the standards process. Even better, what if browser vendors followed this same pattern whenever possible? Well, that’s happened too: Adobe did something similar with a regions proposal – they didn’t use Hitch because they didn’t know about it, but they wrote a kind of one-off that does something similar. Mozilla did this with X-Tags and Google with Polymer – both of which can more freely evolve, be used in any modern browser and even maybe compete a little outside the browser before we rush in and commit. We’ve followed the same basic idea with Futures/Promises and with Navigation Controller. I consider these all great successes that helped us coordinate a lot of groups and get a lot of minds together in new ways.

How does Hitch relate to Web Components?

It has some stuff about Web Components, but those were based on an earlier draft. It pre-dates Mozilla’s X-Tags or Google’s Polymer and we have no real interest in competing with them. In fact, we’d love to collaborate. Both are considerably better and based off updated work. It just turned out that internally we were doing 95% of the stuff necessary to make a simple element “upgrade” happen easily, so we exposed it. If you just want to break down into modular ‘widgets,’ you can probably get away without more. But that isn’t what it's about.

You mentioned that Hitch wasn’t a pre-processor, why not?

As it stands today, Hitch includes some aspects of a CSS pre-processor, but it’s not a pre-processor. It isn’t intended to be a replacement for things like Sass, it just turns out that internally exposing a bit of simple pre-processing is easy, so we expose it. If you just need some simple token replacement, you can probably get away without more, but that isn’t what it is about. In fact, the input to the actual “engine” in Hitch isn’t even CSS, but a kind of parse tree. It’s layered so that we can move the pre-processing piece out if we can partner up with existing things like Sass. We kept it simple for now because some people don’t have a rich pre-processor and don’t want one and we honestly don’t want to try to compete with those guys. It’s better for us to work together with them for that piece as an optimization.

How does all of this relate to the Extensible Web?

That’s what The Extensible Web Manifesto is all about – changing the way we think about standards. Hitch predates this, so I can’t honestly say that it is the “perfect” example of it all. Several of us came to very similar conclusions about the same time and we’ve been discussing for a long time now and honing it all. But it does illustrate, at a high level at least, some of how we’d like to change the model and make it possible for good developers to help #extendthewebforward. If any of this sounds compelling to you, I’d encourage you to go give it a read. And hopefully to sign it yourself. Then tell a friend!

An Intro to Hitch.js and the Extensible Web is a post from CSS-Tricks

Like many web professionals, I use Google Docs every day to create and share information. It’s a fantastic suite of tools that’s perfect for collaborating with your coworkers and interacting with clients. In fact, I think mastering Google Docs has become an essential professional skill.

At Treehouse, we use Google Docs documents and spreadsheets for everything from writing video scripts to analyzing data and statistics. I’m always looking for new tips and exploring the menus, because in a tool that I use every day, small efficiencies can add up to big time savings. In this post, I’ll share a few uncommon Google Docs tips I’ve learned over the last few years that will make you into a document-wrangling, cowboy-ninja, spreadsheet-wizard… person.

1. Show all keyboard shortcuts.

Using the mouse to click on things may feel easy, but it’s slow. Keyboard shortcuts are one of the fastest ways to get better at any piece of software (especially StarCraft). Whether you’re viewing a spreadsheet, a doc, or you’re in the list of documents, you can bring up a full list of shortcut keys. Just use the following (you guessed it) keyboard shortcut:

• On Mac, press ⌘ + /
• On Windows, press Ctrl + /
  

When you hit these keys, you should get a contextual overlay that gives you the hotkeys for the current view; they’re different for each app. It looks something like this:

2. Use Gmail shortcuts in the list view.

If you’ve mastered the shortcuts in either Gmail or the Google Docs list view, then you’ve actually mastered both. When you’re traversing lots of documents, it’s often helpful to make some bulk edits or star some documents to find them quickly later.

Here are the most important keys for navigating the list view:

• J  Navigate to the next item in the list
• K  Navigate to the previous item in the list
• X  Select/unselect an item
• S  Star/unstar an item

3. Free yourself from distraction and edit fullscreen.

If you need to stay hyper-focused on a document in a distraction free environment, this is for you. In a document, go to the View menu and select the Full screen option.

The controls will disappear so that you can focus on your content. I recommend setting your browser to full screen for maximum effect. To get out of fullscreen mode, simply press the Esc key.

4. Hack the custom header styles to quickly add formatting.

When you’re editing a Google document, it’s helpful to create headings so that each section of your writing is clearly defined. The default headings are good for most purposes, but if you frequently need to apply special formatting, you can make your own “headings” and apply them to any inline text. For example, I use the special headings to highlight parts of Treehouse video scripts that include motion graphics, special camera moves, blocking, and computer code.

To create a new header style, simply format your text how you’d like and highlight it. Then go to the Title menu, click one of the right facing arrows next to a header, and select Update ‘heading X’ to match with X being the header number.

Then, when you need to apply the same formatting, you can simply set the text to one of the title styles in the menu as you would normally.

Note: This will only apply to one document at a time, so don’t worry about ‘messing up’ the default styles for other documents or other people in your organization.

5. Get started with a template.

Google maintains a directory of templates that you can use to get a jump start on your next document. There’s a pretty huge selection and it’s easy to filter and sort. Whether you’re setting up a personal finance spreadsheet or writing a resume and cover letter, there’s probably a template in there that can seriously cut down on your setup time.

6. Automagically create a table of contents.

When I create outlines for new courses on Treehouse, the documents tend to get pretty lengthy. Fortunately, if you structure your document using the various header levels in the Title menu, Google Docs can automatically generate a table of contents for you. This TOC allows you to jump to any part of the document, making navigation quick and easy for long documents.

In a document with several headings, place your insertion point at the top of the document. Then, go to the Insert menu and click Table of contents to add a TOC. Here’s a picture of the finished result:

Note: This probably won’t work properly if you use the header hack in tip 4 to format inline text. I only use TOCs for creating outlines and not scripting videos.

7. Use conditional formatting to color spreadsheets.

Maybe you’re not surprised that spreadsheets in Google Docs are capable of coloring cells based on conditional formatting. Yet for some reason, very few people know about this feature when I tell them. If you’re working with numerical data or dates, coloring cells can help you quickly distill and comprehend large datasets.

I created an example data set that represents a traditional classroom with test scores (and in the process, I also learned about the random number generators in the function list). Let’s say you’re a teacher, and you want to visually identify students that scored 75 or below on a test. To do this, hover over the column header and click the arrow icon that appears to bring up a menu. Then click the Conditional formatting… option towards the bottom.

Note: In the image below, there are numbers in column B that are covered by the menu.

When the conditional formatting modal appears, you can add rules that will color the cells. In the image below, you can see what these rules look like for our example. Any numbers at 75 or below will be highlighted in yellow. Everything else will be green.

Here’s what the data looks like with the added color. Even better, when we sort Column B, we’ll see a visual that depicts the ratio between low scores and high scores. The block of yellow cells will be set against the block of green cells. Conditional formatting is like a grappling hook for climbing the DIKW Pyramid. It’s a tool that can help you make the leap from data to useful information.

8. Extrapolate sets of related terms.

Are you ready for some magic? Google spreadsheets allows you to take two cells and find other related terms. First, fill two cells with related items and highlight them, like so:

Now we need to drag out the set. On a Mac, hold down option. On a PC, hold down Ctrl. While holding down the modifier key, click on the small blue box in the bottom right corner of the highlighted cells, and drag downwards.

Google will fill in other related terms. In this case, Google magically filled in the remaining cells with other Star Wars characters. It’s not perfect, but it works pretty well for most things. From what I understand, this technology is what’s left of Google Sets, a defunct Google Labs project.

It’s hard for me to say exactly how you can use this one, but it’s definitely a fun curiosity that’s helped me brainstorm related ideas in sort of a fuzzy mind-mapping fashion. I’m hoping to see some clever ideas in the comments!

The post 8 Google Docs Tips You May Not Have Known About appeared first on Treehouse Blog.