Inbox by Gmail supports all the above actions and cards, as well as the five interactive cards described below.
Highlights in Inbox
Inbox uses the same schema.org markup as Gmail to highlight the most important information within an email, and allow user to act on it. It supports the RSVP, One-click and Go-to actions as well as shows Highlights for the following markup types:
Last night was pretty wild, with Google confirming an update over the weekend targeting spammy queries and also Google's Matt Cutts posting on Twitter that Panda 4.0 was released.
This is a new Panda algorithm, not a refresh that we've seen almost monthly but enough for Google to name this 4.0, which means a new algorithm update to it.
Google's Matt Cutts told us at Search Engine Land that this Panda 4.0 update impacts ~7.5% of English queries to a degree that a regular user might notice.
Also when I spoke to Matt Cutts, he made it sound like this update may appear gentler for some sites but it does lay the groundwork to future changes in the direction of a softer and gentler Panda algorithm.
This began rolling out yesterday and is unrelated to the Google Spam Algorithm 2.0released over the weekend and unrelated to anything Penguin.
So no, I was not crazy expecting something big that happened over the weekend and throughout the month and this week. Even though Google said nothing is going on, we've been seeing signs of major changes and ranking shifts all throughout the month. I suspect those were tests for both this Google Spam Algorithm version 2.0 and the Panda 4.0 release.
Here is some of the history on the Panda update, but to dig deeper, see our Panda category.
Google stopped confirming Panda updates last year and then started doing rolling updates but that doesn't mean they haven't done work on fine tuning the algo. Theysoftened it recently and there have been refreshes monthly, some larger than others but it is hard to know if it was Panda or something else.
Over the next few days, we are going to need to look at our analytics and isolate if we were impacted by one of these algorithms. I'll ask you to fill out a poll in the near future and share those results.
We all know that Facebook and open-source software go hand in hand. Open source has been a big part of their philosophy. James Pearce, the open source lead at Facebook also confessed on the company blog, “Since Facebook’s first line of PHP, and its first MySQL INSERT statement, open source has been a huge part of our engineering philosophy.”
In 2013, there were some noteworthy contributions from Facebook to the open-source community in 2013. Here they are:
xctool: This was created as a replacement for Apple’s xcodebuild, which is responsible for making it easier to create and test iOS and Mac projects.
Buck: This is an Android/Java build tool that helps in faster, better Android builds.
Rebound: This is a Java library meant for animations.
React: This is a JavaScript library that is aimed at building new user interfaces.
Regenerator: This is a Node.js tool that helps to replace generator functions by means of efficient JavaScript-of-today (ECMAScript 5 or ES5 for short) that behaves pretty much the same way.
Huxley: This is a test-like system for capturing visual regressions in Web applications. This keenly watches you browse, takes screenshots, and informs when they change.
Presto: This is a distributed SQL engine that is aimed at running interactive analytic queries.
RocksDB: It is an embeddable persistent key-value store that helps for faster storage. It can also act as the foundation for a client-server database.
Pearce further told Venture Beat, “We know there is still a huge amount to work on, across each of the major themes above. We’re very lucky to have strong and enthusiastic communities on our projects, and with that comes great responsibility.” Ref:efytimes
The massive growth in rich, JavaScript-heavy web applications has lead to a huge array of frameworks designed to help you build apps. There are so many that it can often be difficult to choose which best suits your needs, so in this article I'll discuss five of the most popular, and look at where each of their strengths lie.
You shouldn't base your decision entirely on this article - I encourage you to play further with a framework before committing - but I hope this sets you off in the right direction.
Most frameworks follow roughly what's known as an MVC pattern: model, views and controllers. Models deal with data, fetching it from databases and returning it. Views then display the data, and controllers link the models and views together. Of course, that's a very simplified explanation, but the idea in essence is to keep the presentation and the data completely separate, which brings huge benefits as your code starts to grow in complexity. If you've ever worked with a framework like CodeIgniter or Rails, the MVC approach will be familiar to you.
01. Backbone.js
We start with one of the most well known frameworks,Backbone.js. With Backbone, your data is represented in Models. Models can then be contained within Collections which are a collection of model instances. Views also offer more than just templates for displaying data, they also deal with binding events. One of my favourite things about Backbone is the hugely extensive documentation, which makes it much easier to really get to grips with the framework.
An important note is that there is no such thing as a typical controller in Backbone. The job of the controller tends to more be done partially by Views - they contain UI logic along with represting data, as we'll see shortly, and the Backbone Router, which maps URLs to functions. Collections are described on the Backbone site as "A group of models on the client-side, with sorting/filtering/aggregation logic".
You typically define methods to filter your data on collections. For example, the example Backbone todo app defines methods to filter just the todos marked "done":
The above todo app is well worth examining if you're new to Backbone - it's fully commented and very helpful when it comes to deciding how best to lay out your application. One of the issues (if you could call it that) with Backbone is that there are a lot of different ways to achieve the same end goal. Don't get confused if online tutorials do things slightly differently.
In my opinion, Backbone is great for small, one page applications, and that's how I tend to use it. However there are plenty of people who have built impressive, vast applications with it, including USA Today and the New Rdio. Plenty more are cited on the Backbone site. I encourage you to give it a try and see how you find it.
02. Ember.js
Second is Ember.js. Whilst Backbone is fairly low level, with a lot of code that you need to write yourself, such as code to update the view when model data changes, Ember does a lot of that work for you. It's more opinionated because it tries to do a lot more for you, but that also leads to you having to write less boilerplate code.
Ember's main features are its data binding; obejcts in Ember can bind properties to each other, so when a property changes in one object, the other is kept in sync. Another is the ability to define functions on an object that you can then treat as properties. Hence, if a model has a first and last name, you could create a function to define a person's fullname, and have it treated as if the model has a fullname property. For example, here's how you might define such a property:
fullName: function() { var firstName = this.get('firstName'); var lastName = this.get('lastName'); return firstName + ' ' + lastName; }.property('firstName', 'lastName')
You can then reference fullName as if it was a property throughout your code and in your views. For example, with the above property defined, your view might look something like:
<p>Hello, <b>{{fullName}}</b>!</p>
And this would automatically update when the value changed. A combination of data binding and computed properties is very powerful.
Coming from a Backbone perspective, the feature most likely to draw you in is that Ember automatically updates its views when data changes - saving you a lot of work. This comparison post between the two sums it up quite nicely: "Backbone is more explicit and less magical". Depending on your perspective, that can be a good or a bad thing. Some prefer Backbone because it keeps things simple, and lets you do everything how you want, whereas Ember does much more for you. A framework that does more for you means you relinquish some of the control, but gain time in not having to write code to handle a lot of the mundane functionality.
Ember also has more traditional controllers. Views (usually written in Handlebars) provide ways of attaching certain buttons or links to Ember controller actions. Of course, controllers don't need to deal with updating content, but can house methods to deal with just about everything else. This is where most of your methods will go that deal with the data. In a todo app, for example, you might write methods that return just the completed todos, or the methods that save another todo item.
03. Angular.js
Next up is Google's offering, the relatively new AngularJS. Angular takes a slightly different approach by doing data binding directly in your HTML. It also uses just plain JavaScript for its controllers, meaning there's no need to extend other objects as you have to do in other frameworks. The data binding means data in views is automatically updated when the data changes, but also Angular makes it effortless to bind forms to models, meaning a lot of the code you typically write to link a form to creating a new instance of a model is not needed. Its data binding is bi-directional. For example, here's the HTML for a form for a todo app (taken from the Angular documentation):
<form ng-submit="addTodo()"> <input type="text" ng-model="todoText" size="30" placeholder="add new todo here"> <input class="btn-primary" type="submit" value="add"> </form>
Notice the use of ng-* attributes within the HTML, which is where the majority of the magic lies. The ng-submit attribute will capture the form submit event and pass it to the addTodo method, which is a method on the todo controller. By declaring the ng-model attribute on the text field, you can easily get at the value without having to reference the field's DOM element and grab the value.
By moving a lot of the binding directly into the HTML, Angular leaves you with much leaner controllers and less JavaScript to write. It might take a while to get your head around, but this approach is really powerful. The Angular home page contains multiple sample apps and videos of those apps being built, so if this interests you I highly recommend you check them out.
04. Knockout.js
Knockout.js is an MVVM (Model-View-View Model) framework written in pure JavaScript. MVVM frameworks are split into three parts. Firstly, there are models, which are exactly what you'd expect. Typically these sync data with a server.
You then have view-models, which are pure JavaScript and are a code representation of your data along with exposing methods for manipulating the data - these are as close to controllers as an MVVM framework comes. The bulk of your logic goes into these. Finally there are views, which display the information. These are written in pure HTML with bindings inserted as attributes (similarly to how Angular JS does it), which Knockout then uses to update views with the data. Knockout does this for you.
As an example, to display the firstName property of a model instance, my view would contain:
You then activate Knockout by applying the bindings. You pass this function an instance of your view model, which defines the value of properties. For example, something like:
function AppViewModel() { this.firstName = "Bert"; };
You can then activate the bindings like so:
ko.applyBindings(new ViewModel());
And you'll see the strong tag show "Bert". This code was taken from the interactive KO tutorial, which is the best place to start if you're interested in learning more.
05. Batman.js
Finally, I wanted to pick something different to all of the above and went with Batman.js, and not only because of the name. Batman is written in CoffeeScript. It can be used with JavaScript or CoffeeScript, but your code will look much cleaner in CoffeeScript as Batman makes use of CoffeeScript's classes heavily.
I'd only recommend Batman if you are happy to write CoffeeScript. With Batman you create an instance of Batman.App, which acts as a wrapper around your application. Then, you create controllers and models within this App class. App classes are very straight forward:
class Todo extends Batman.App @global yes @root 'todos#index'
The first line sets it to global, so it's added as a property on the global object. The second line will look familiar to those with Rails experience. This sets the application's root path to be the index action on the controller. Controllers and methods get added as properties on this class. Batman also uses data-bindings in the HTML. For exmaple, to output a list item for each item in a product model, it's as easy as:
<li data-foreach-product="Product.all"> <a data-route="product" data-bind="product.name">name will go here</a> </li>
Batman is a great choice if you're a fan of CoffeeScript. It's quick to pull simple apps together and is also probably the framework to stay closest to what I would consider a typical MVC pattern.
Nick Small, Batman.js' creator, has a great presentation on how and why you should use Batman.js. It unfortunately doesn't seem to be as popular as the other frameworks out there which I think is a shame, as the amount you can do in such little code is fantastic.
06. Conclusion
It was very hard in this article to pick out five frameworks and try to give them a fair overview in a limited number of words. The last four are pretty similar, with Backbone probably the odd one out. It does leave you with more work to do, and doesn't provide bindings, a key feature of the others, but if you want full control over everything, it's a good one to look into.
The key advice I would give is to look at apps written in these libraries and try to write your own small apps before commiting to one. Each has subtle differences which will either suit you or not, and it's good to find those out sooner rather than later.
Of course, there are plenty more than these five, and the Todo MVC project is a great place to start if you'd like to explore other options. That site has a huge collection of applications written in a great variety of frameworks, including all the ones mentioned in this article. You can find the repository of these applicationson Github.
Thanks to Addy Osmani for his peer review of this article
Jack Franklin is a 20 year old developer living in London, UK. He runs a JavaScript blog at javascriptplayground.com and also writes PHP, Ruby and other languages. He tweets as @Jack_Franklin.
From clients to bosses, everyone wants a programmer to deliver their products in the shortest of time! But it seems that anyone hardly cares about the needs of developers to get the job done. From pointless meetings to useless productivity parameters and know nothing bosses, here are 10 biggest hindrances to a successful programming project. 1. Meetings
In the survey by CIO, a majority of developers readily agreed that meetings are the biggest factor which acts as a roadblock and kills their productivity time. Bosses preaching on every little detail and co-programmers going on and on about petty bugs or features or architecture is a let down.
2. Reading And Replying All Emails
Agreed that meetings are bad but so are their alternative, that is emails. Discussing everything on emails and then going through all those mail trails can be a bigger killer! And while there are options of skipping of blocking the mails, that way you can even miss some important communication.
3. Useless productivity measures
There comes a time when managers suddenly start to count your commits and lines of code or number of bug fixes. And if you are putting up programmers in this gameplay, they instead of making the code better, start to concentrate on increasing the writing lines and solving bugs or doing whatever is being counted. So such measurements instead of boosting the productivity can encourage the programers to create long files of overly engineered codes.
4. The First Coders
If there is one person at work who can be worse than your boss then he is the person who was working on these codes earlier and then left. If you are trying to understand what the code was all about, he will make sure that it sounds as bad it can be. And trying to understand the basic function of the program via them can be a big time productivity killer!
5. Nonprogrammer managers
While some programmers are happy about having non programmer managers as they are easy to make excuses to, others say that these guys just call meetings and get in the way. Some blame them for not giving enough guidance.
6. Programming pro boss
This was an obvious on the list as those who love non programmer managers, hates those who are pro in programming. These former geniuses often micromanage the project and want to change almost everything that you create. Result: Productivity killed!
7. Programmer v/s programmer
“You can't always blame it on others," say a lot of respondents of the survey. Many programmers often lock their horns on pettiest of features without even considering what the client actually wants. And what suffers in this battle of two is again productivity.
8. Poor Documentation
Yes, we understand that documentation takes a little time but imagine getting into someone's code without having any documentation. It surely is when you have to try and err and understand what feature do what. Infact for the current coders also documenting it all at end might be even more time consuming. A well explained documentation which is updated time to time will help you to retain which coding was for what and will save a lot of time.
9. Circus atmosphere
This specially happens when you are sent to the client's office to work and they make you sit at a place which is full of distractions. Be it new trainees or next to pantry. Yes, these things kills productivity big time!
10. Clinging to historic technologies
There still are project leads that want you to code in a technology that should better be placed in museums. Out of many purposes of the upcoming languages, one is definitely meant to cut down on time and effort. And here if you are stuck to older ones that need even deeper analysis and reading by the programmer, it is definitely a productivity killer!
