Tuesday, March 22, 2016

Ultimate #SocialMedia Cheat Sheet For Perfectly Sized Images In 2016 - #infographic

The Ultimate Cheat Sheet to Social Media Image Sizes - infographic

Social media is a novice giant and one that is constantly evolving. As difficult as it is to keep up with its latest trends, it is equally vital to know the technical details behind those changes so that you can extract the maximum from them. Review reporting on social media trends has very aptly revealed that visual posts which contain an image are far more likely to get noticed than those without any.

The visual form is a proven method to grab eyeballs. The human brain is easily distracted and it takes something to stand out amidst the sea of content that is available on the internet. Images, memes, creative digital art and various other formats of showcasing your product/idea are now available at your disposal and not using them for upping your business quotient would be suicide. In order to do so, you need to know the what dimensions and pixels of images are best suited for which platform. If these minor technicalities are overlooked, the image may fail to highlight what is most important and completely miss the point of its existence!

by Guest Author via Digital Information World

Building Faster Websites with Grav, a Modern Flat-file CMS

Nowadays, there’s an interesting get-back-to-the-basics tendency among web developers. Some modern, best-in-class technologies --- like Markdown, Twig, and YAML --- are often used together to produce many new, lightweight CMSs, focused on speed, simplicity and productivity. The principle they all follow is pretty straightforward: when things get too complex, it’s better to start from scratch, instead of trying to clean up the existing mess.

In this article, I’m going to introduce you to one of the best examples of such a started-from-scratch platform, called Grav.

Screenshot of the Grave website

What Is Grav and Why Should I Use It?

Grav is a modern, flat-file CMS, developed by RocketTheme. Why modern? Because it uses modern PHP and latest standards like Markdown, Twig, YAML, Doctrine Cache, etc. Flat-file CMS means that there’s no database involved, and instead all the site’s content and configuration settings are stored in plain text files.

To grasp this relatively new concept better, imagine a regular, HTML-based website, as in the good old days, but with added ability to create and maintain the actual HTML files dynamically. While you picture this view, bear in mind two things:

  • First, Grav is not a static site generator. The content is written in Markdown files, and these files are processed and converted to HTML files dynamically on demand. You won’t find any static HTML file inside your site directory.
  • Second, even though Grav doesn’t use a database, it still gives you a way to manipulate your content dynamically --- almost as a database-driven CMS such as WordPress.

So, you can think of Grav as a kind of a hybrid, combining the best from both static and dynamic worlds. Furthermore, a flat-file CMS gives you some additional very attractive advantages:

  • A database-free site eliminates all the headaches and bottlenecks that dealing with a database can bring.
  • Because you deal with files only, you can easily add 100% version control for all of them by using Git and services like GitHub or GitBucket.
  • You can copy all of your content and configuration files and move them wherever you wish, which makes your site completely portable and easy to back up.

No matter whether you are a developer, a designer, or just a user, Grav may have something for you.

Grav is developer friendly
It offers many useful tools for developers such as a CLI Console, GPM (Grav Package Manager), and a Debug Bar. All these tools make for easier developing, debugging, installing and updating themes and plugins.

Grav is designer friendly
Designers often aren’t experienced coders, and they need an easy way to bring their designs to life. With the power and simplicity of the Twig template engine, this can be done fairly easily. Using Twig to output PHP is as simple as using a CSS preprocessor, like Sass, for outputting CSS.

Grav is user friendly
Thanks to the Admin Panel plugin, users can create and manipulate their site’s content, and manage the entire site itself, in a convenient GUI-ified way.

Continue reading %Building Faster Websites with Grav, a Modern Flat-file CMS%


by Ivaylo Gerchev via SitePoint

How to Write Atom Packages Using Vanilla JavaScript

Atom is a modern, to the core hackable editor. This is great, but for developers who aren't fluent in CoffeeScript, it is hard to follow the documentation. Understanding the ecosystem of Atom can become confusing. Let's go through all aspects of how writing an Atom package in JavaScript works.

Understanding Atom

Atom is a Node.js and Chromium based application, written with GitHub's Electron framework. That means it is technically a web application, running on the desktop. Atom's internal functionality is split up into tiny core packages; they're developed the same way as any other package from the community. Although they are all written in CoffeeScript, it is possible to either write them in plain JavaScript, or transpile them via Babel.

Activating Full ES2015 Support with Babel

Babel is a source-to-source compiler; turning ECMAScript 2015 (formerly known as ES6) code into ECMAScript 5 code. Since the environment is Chromium, there are already a lot of supported ES2015 features available. But instead of always looking up which ones are implemented, I recommend using Babel to transpile your code. In a later release — when ES2015 is better supported in Chromium — you can deactivate Babel again and keep your code base (almost) untouched.

To activate transpiling with Babel, each file needs a 'use babel'; statement at the beginning, similar to strict mode in ECMAScript 5. This gives you also the ability to decide which files should be transpiled and which not, by omitting the statement.

The package.json

It helps to view an Atom package as npm module. You have the same access to the API as any tool running on Node.js. Therefore it's possible to add any npm dependency needed. A package.json is also required, containing all meta data for your project. The basic file should be as follows:

{
  "name": "your-package",
  "main": "./lib/main",
  "version": "0.1.0",
  "description": "A short description of your package",
  "keywords": [
    "awesome"
  ],
  "repository": "http://ift.tt/1T5vSjA;",
  "license": "MIT",
  "engines": {
    "atom": ">=1.0.0 <2.0.0"
  },
  "dependencies": {
  }
}

The important keys are main — defining the main entry point of your package (defaults to index.js/index.coffee) — and engines — telling Atom on which version your package runs. There is also a set of optional keys available, documented in the "wordcount" package documentation (section package.json).

The Package Source Code

All your package code belongs in the top-level directory lib/. I recommend having your entry point in this folder as well, as it keeps the structure clean and makes it easier to scan the project.

Your main file must be a singleton object that maintains the entire lifecycle of your package. Even if your package consists only of a single view, it will all be managed from this object. Your entry-point requires one activate() method, but should also have the optional deactivate() and serialize().

// lib/main.js
'use babel';

// This is your main singleton.
// The whole state of your package will be stored and managed here.
const YourPackage = {
  activate (state) {
    // Activates and restores the previous session of your package.
  },
  deactivate () {
    // When the user or Atom itself kills a window, this method is called.
  },
  serialize () {
    // To save the current package's state, this method should return
    // an object containing all required data.
  }
};

export default YourPackage;

Activate Your Package

The activate() function is the only required method. Initialise all your modules, views or helpers here. It is passed an object, containing the previous serialized state of your package. If you don't serialize anything in your package, it will be an empty object. That means, it is entirely up to you and your package architecture on what to serialize.

Deactivating

The deactivate() method is optional, but important. It will be called by Atom when the window is shutting down, or the user deactivates it in the settings. When your package gets deactivated by the user, and you don't dispose of added events/commands, they are still available. This isn't a problem when Atom is shutting down the window. It will tear down events and commands. But if your package is watching files or doing any other work, you should release them in deactivate().

Event Subscription

A package usually subscribes to multiple events like adding custom commands, listening to changes, or modified files. It is possible to bundle these into an instance of CompositeDisposable(), and this way they can all be disposed of at once.

// lib/main.js
import { CompositeDisposable } from 'atom';

const YourPackage = {
  subscriptions: null,

  activate (state) {
    // Assign a new instance of CompositeDisposable...
    this.subscriptions = new CompositeDisposable();

    // ...and adding commands.
    this.subscriptions.add(
      atom.commands.add('atom-workspace', {
        'your-package:toggle': this.togglePackage
      })
    );
  },

  // When your package get's deactivated, all added
  // subscriptions will be disposed of at once.
  deactivate () {
    this.subscriptions.dispose();
  },

  togglePackage () {
    // Code to toggle the package state.
  }
};

Serialize All the Things!

Serialization is a powerful, but again optional, feature of Atom packages. Serialization/deserialization happens when a window is shutting down, refreshed or restored from a previous session. It is up to you to define which and how many of your components should serialize their data. What's important is that it returns JSON. If you have a view, and want that to be able to be refreshed, you need to make it compatible with serialization and deserialization.

This very basic component takes an object, which will be used as the component's internal data. Your component then might do some work with the data and can allow its state to be serialized via the serialize() method.

// lib/fancy-component.js
class FancyComponent {
  constructor (configData) {
    this.data = configData;
  }

  // This method will be called when the class
  // is restored by Atom.
  static deserialize (config) {
    return new FancyComponent(config);
  }

  // The returned object will be used to restore
  // or save your data by Atom.
  // The "deserializer" key must be the name of your class.
  serialize () {
    return {
      deserializer: 'FancyComponent',
      data: this.data
    };
  }

  doSomethingWithData () {}
}

// Add class to Atom's deserialization system
atom.deserializers.add(FancyComponent);

export default FancyComponent;

To make all this useful, this component must be called and serialized in your packages main singleton.

// lib/main.js
import FancyComponent from './fancy-component';
import SomeView from './some-view';

const YourPackage = {
  fancyComponent: null,
  someView: null,

  activate (state) {
    // If the component has been saved at a previous session of Atom,
    // it will be restored from the deserialization system. It calls your
    // your components static 'deserialize()' method.
    if (state.fancy) {
      this.fancyComponent = atom.deserializers.deserialize(state.fancy);
    }
    else {
      this.fancyComponent = new FancyComponent({ otherData: 'will be used instead' });
    }

    // More activation logic.
  },

  // As well as your component, your package has a serialize method
  // to save the current state.
  serialize () {
    return {
      fancy: this.fancyComponent.serialize(),
      view: this.someView.serialize()
    };
  }
};

All objects you want to serialize need the serialize() method. It must return a "serializable object", and a deserializer key with the name of a registered deserializer. According to Atom, "it usually is the name of the class itself". Additional to that, a class also needs the static deserialize() method. This method converts an object from a previous state to a genuine object.

Continue reading %How to Write Atom Packages Using Vanilla JavaScript%


by Moritz Kröger via SitePoint

PostCSS Mythbusting: Four PostCSS Myths Busted

With the introduction of any new front-end tool, there comes the important questions with regard to its potential value in an already congested marketplace. Does it offer developers anything new? Is it going to be worth investing the time and effort to learn and implement it?

Since its inception, PostCSS has faced an interesting problem. With it vying for attention in a reasonably mature area alongside established CSS tooling such as Sass and Less, there have been a number of misconceptions made relating to its categorization and use.

So let’s address some of the most common myths around PostCSS and in doing so show how it can enhance your workflow and improve how you work with CSS.

N.B. If you want to find out more about what PostCSS actually is and how to set it up, check out this introduction to PostCSS and then come back here for some mythbusting!

Myth 1 – PostCSS is a Pre or a Postprocessor

Let’s start with perhaps the biggest point of confusion relating to PostCSS.

When PostCSS was first released, it was promoted and categorized as being a ‘Postprocessor’. Many of the first PostCSS plugins took valid CSS and extended it in some way, rather than the previously familiar approach taken by preprocessors of taking custom syntax and compiling it into valid CSS.

To call PostCSS a postprocessor is somewhat misguided and actually plays down its capabilities. I prefer to refer to it simply as a CSS Processor, as it can perform a number of different tasks, using PostCSS plugins, at several points in your CSS authoring process.

A number of PostCSS plugins take custom syntax and convert it into valid CSS, as you would associate with a conventional preprocessor like Sass. One such example would be the PostCSS Nested plugin which lets you nest selectors – in the same way that Sass and Less implement selector nesting. Other PostCSS plugins take valid CSS and extend it, such as PostCSS’s most well-known plugin, Autoprefixer, which adds vendor prefixes automatically to your stylesheet.

Some PostCSS plugins don’t actually transform your CSS at all, but instead provide useful insights into your styles. Stylelint can be used to lint your CSS, while a plugin like Colorguard can help you to maintain a consistent color palette across a project.

In addition to all of this, PostCSS can parse SCSS syntax as well as standard CSS. This means that you can extend your Sass .scss files with PostCSS plugins – something which we will go into in more detail in Myth 2.

So to bust our first myth — PostCSS is neither a Pre or a Post–processor. It is a CSS Processor that can extend or report on your styles at a number of different points in your workflow.

Myth 2 – PostCSS Is an Alternative to Preprocessors like Sass and Less

A common misconception among developers is to compare PostCSS as an alternative to already existing preprocessing tools such as Sass and Less.

I believe this to be down to the fact that a number of the first PostCSS plugins focused on emulating features commonly seen in preprocessors, such as variables, conditionals, loops and mixins. As the PostCSS community has grown, a much more diverse range of plugins has emerged, offering a number of features that differentiate it from traditional preprocessors.

So although you could use PostCSS as an alternative to using a preprocessor like Sass or Less, you could alternatively power-up your existing toolset by extending the features of your favourite preprocessor.

PostCSS is capable of parsing both CSS and SCSS syntax, which means that you can use PostCSS plugins to transform your styles both before and after your Sass compilation step. For example, on a current project I use PostCSS to lint my Sass files using Stylelint before it is compiled into CSS. The resulting CSS is then extended with plugins like Autoprefixer and postcss-assets to add vendor prefixes and inline image assets as data URIs. So your workflow could look something like this:

Flow diagram of example workflow process

Ultimately, how you choose to use PostCSS is up to you. If you want to use it as your sole CSS processing tool, you can certainly do that. But if you’re perfectly happy using Sass or Less, consider that PostCSS is equally capable of working alongside those tools to provide additional features that your preprocessor cannot.

Continue reading %PostCSS Mythbusting: Four PostCSS Myths Busted%


by Ashley Nolan via SitePoint

JsSpeechRecognizer – JavaScript Speech Recognition

JsSpeechRecognizer is a javascript based speech recognizer. It allows you to train words or phrases to be recognized, and then record new audio to match to these words or phrases.


by via jQuery-Plugins.net RSS Feed

What Can Developers Expect in Android N?

Android N is the next installment of Google's Android platform, due at some point this year.

Usually Google announces the next version of Android during the I/O conference in May, but the timeline for Android N is different. Starting from March, Google will be releasing successive previews to give developers time to prepare their apps for a compatible N release. The finalization of Android N (and it's official naming) won't be completed until the third quarter of the year.

Like all Android updates, N comes with a range of new features and improvements which I will cover today.

Continue reading %What Can Developers Expect in Android N?%


by Simon Codrington via SitePoint

Hedge for Mac

Hedge for Mac

Slick, dark-schemed One Pager for a new OS X backup application called 'Hedge'.

by Rob Hope via One Page Love