In this article, Thomas Peham, a tech marketer at Usersnap, explains how and why static site generators can help with your landing page workflow. Nobody likes finding bugs. Even worse, no one enjoys finding bugs while shopping for digital products. That is why, as a company providing a web-based bug tracking tool to tens of […]
Continue reading %Developing a Static Site Generator Workflow%
A tutorial about creating search form with advanced filtering options and quick link suggestions with CSS and jQuery.
Have you ever worked on a project, and it seemed that something was off visually? Maybe the project was nearly finished, but some elements didn’t look so good? These may be small details, but they make a difference.
If your project contains unattractive select boxes and you want to add more features to them, you will find Chosen and Select2 very useful. These are two jQuery plugins that help style your select boxes to improve their look, customize their behavior and make them more user-friendly.
In this article, I will put these two plugins head-to-head, and compare their features and their use cases, so that you can make an informed choice as to which is best for you.
Both Chosen and Select2 are available via GitHub. This means you can clone the respective repository and obtain the files you need.
git clone http://ift.tt/1oaCH71
git clone http://ift.tt/1PlG6GW
Otherwise, you can install both plugins with Bower (which serves as an interface to GitHub). If Bower is your preferred route, you might as well grab jQuery while you’re at it.
bower install jquery
bower install select2
bower install chosen
Otherwise, grab the files from your CDN of choice (e.g. CDNJS) and include them in your page in the usual manner. This is what I have done in the templates below which you can use this to follow along with the examples in the tutorial.
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Chosen/Select2 Template</title>
<link rel="stylesheet" href="//cdnjs.cloudflare.com/ajax/libs/chosen/1.4.2/chosen.min.css">
</head>
<body>
<script src="//code.jquery.com/jquery-1.11.3.min.js"></script>
<script src="//cdnjs.cloudflare.com/ajax/libs/chosen/1.4.2/chosen.jquery.min.js"></script>
<script>// Additional logic goes here</script>
</body>
</html>
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Select2 Template</title>
<link rel="stylesheet" href="//cdnjs.cloudflare.com/ajax/libs/select2/4.0.1/css/select2.min.css">
</head>
<body>
<script src="//code.jquery.com/jquery-1.11.3.min.js"></script>
<script src="//cdnjs.cloudflare.com/ajax/libs/select2/4.0.1/js/select2.min.js"></script>
<script>// Additional logic goes here</script>
</body>
</html>
As you can tell by visiting the its GitHub page, development of the Chosen plugin is not as active as it once was and the most recent version of Chosen dates from Febraury 6th 2014. This is not to say that the library has been abandoned — far from it! Rather the developers have got it to the place they want it to be and it remains a reliable and robust plugin.
Contrast that with Select2 on the other hand and the difference is noticeable. Development of this library is going full steam ahead and it recently released its official fourth version (4.0.0). This means that new features are being added, whilst others are being deprecated and/or removed.
Another useful metric might be the amount of questions with these tags on Stack Overflow. You can try this for yourself here: http://ift.tt/gE9fRX
If you type in “Select2” and then contrast that “Chosen”, you’ll see that there seems to be much more activity around the Select2 plugin. You’ll also see that it has a number of integrations, such as with AngularJS and Ruby on Rails.
Continue reading %jQuery Select Box Components – Chosen vs Select2%
This article is part of a web development series from Microsoft. Thank you for supporting the partners who make SitePoint possible.
This is the third part in the Angular 2 series. You can read part two here.
Code for this article can be found on Github here. Browse to the src/data-flows folder to find the applicable source. This application running on Node in Azure can be found here.
[author_more]
Data binding can be a touchy topic. Prior to Angular 1 it was reserved largely for compiled and server rendered languages or UI frameworks such as Silverlight and Flex. When Angular 1 broke onto the scene we were amazed at the "magic" that data binding provides in the UI.
If you've been reading up on Angular 2 you've probably heard things like "immutability" and "one-way data flow". But how exactly do these relate to Angular? Do they work with NgModel? How can we manage the state of our application when everything flows in one direction.
This article covers first how to treat Angular 2 data bindings similarly to Angular 1. Then we will talk about converting to a one-way data flow and will make the needed modifications to do so.
We will build the most basic Todo app I can think of. No styling, just an input allowing the user to type a Todo and hit Enter to submit. Then a list of Todos with the ability to mark them Done.
The final product looks like this
Browser screenshots in Microsoft Edge
Building this in Angular 1 should be relatively straight-forward. We have a simple HTML form with an ng-submit (so our form handles the Enter key), a controller method that turns the text we entered into a new Todo, and a way to toggle done vs not done Todos.
The markup looks something like this:
<h2>Angular 1 Todo App</h2>
<div ng-controller="AddTodo as addTodo">
<form ng-submit="addTodo.addTodo(todo)">
<input ng-model="todo" placeholder="Create a Todo"/>
</form>
</div>
<div ng-controller="TodoList as todoList">
<ul>
<li ng-repeat="todo in todoList.todos"
ng-click="todoList.toggleTodo(todo)"
ng-class="{completed: todo.completed}"
>{{todo.title}}</li>
</ul>
</div>
There is a simple service that manages the list of Todos that are rendered. The service also handles adding and toggling the completed state of each Todo:
function TodoService () {
return {
// Default a couple Todos for initial rendering
todos: [
{title: "Read the todo list", completed: true},
{title: "Look at the code", completed: false}
],
add: function (todo) {
if (!todo.length) {
return;
}
this.todos.push({title: todo, completed: false});
},
toggle: function (todo) {
todo.completed = !todo.completed;
}
}
}
When a user types into the <input> they will be adding to the “todo” model property. Hitting Enter will submit the form and run addTodo() on the AddTodo controller, which looks like this:
functionAddTodoController (TodoService) {
this.todoService = TodoService;
}
AddTodoController.prototype.addTodo = function (todo) {
this.todoService.add(todo);
}
And finally the list of Todos is rendered in the <ul> tag and each Todo can run the toggleTodo() method. The TodoList controller looks like this:
functionTodoListController (TodoService) {
this.todoService = TodoService;
this.todos = this.todoService.todos;
}
TodoListController.prototype.toggleTodo = function (todo) {
this.todoService.toggle(todo);
}
While this extremely basic Angular 1 application might not be something you would write for production (I would recommend using directives and/or a router to tie views to controllers rather than using ng-controller), it provides a simple example using basic data binding and dirty checking to render the list of Todos. It’s a good place to start since it touches on the common data flow scenarios in Angular 1.
In Angular 2 we can build an application in the same way as Angular 1. We can use two-way data binding (really it’s just two one-way data bindings, but the end result is two-way data binding) and a service to manage our data. We can rely on dirty checking to re-render the UI when changes happen to our data.
So what would be the advantage of using Angular 2? Well, in looking at the following code samples we’ll see a cleaner separation of concerns. Using components we build the application as a tree from the top down, and the functionality in each component can be easily reasoned about.
Here is the base component for our application:
// TodoApp (app.ts)
import {Component, DoCheck} from 'angular2/core';
import {AddTodo, TodoList, Header} from './components';
import {TodoService} from './services/todos';
@Component({
selector: 'TodoApp',
template: '
<Header></Header>
<AddTodo></AddTodo>
<TodoList></TodoList>
',
directives: [AddTodo, TodoList, Header],
// Add the TodoService so all children components
// have access to the same TodoService instance.
providers: [TodoService]
})
export class TodoApp {}
This is a very basic component, but the key part of note is the providers property being used in the Component decorator. TodoService isn’t being used directly by this base component, but adding it to the providers list means that any child components will receive the same instance of the TodoService (creating a singleton for any child components).
Notice in the AddTodo component how we inject TodoService, but it isn’t included in a providers property. Angular 2 will look up the chain of injectors until it finds TodoService at the top level and inject that one:
// TodoService (services/todos.ts)
import {Injectable} from 'angular2/core';
import {TodoModel} from '../models/todo';
@Injectable()
export class TodoService {
todos: TodoModel[];
constructor () {
this.todos = [
{title: "Read the todo list", completed: true},
{title: "Look at the code", completed: false}
];
}
add (todo: String): void {
if (!todo.length) {
return;
}
this.todos.push({title: todo, completed: false});
}
toggle (todo: TodoModel): void {
todo.completed = !todo.completed;
}
}
Now the TodoList gets a reference to the same TodoService instance and uses it to render the list of Todos:
// TodoList (components/todoList.ts)
import {Component, Input} from 'angular2/core';
import {Todo} from './todo';
import {TodoService} from '../services/todos';
@Component({
selector: 'TodoList',
template: '
<ul class="list-group">
<Todo *ngFor="#todo of todos" [todo]="todo"></Todo>
</ul>
',
directives: [Todo]
})
export class TodoList {
todos;
constructor (todoService: TodoService) {
this.todos = todoService.todos;
}
}
And finally the Todo component itself renders the Todo text. It also wires up a click event to toggle the state of the Todo:
// Todo (components/todo.ts)
import {Component, Input} from 'angular2/core';
import {TodoService} from '../services/todos';
@Component({
selector: 'Todo',
template: '
<li [ngClass]="{completed: todo.completed}"
(click)="toggle(todo)"
class="list-group-item">
{{todo.title}}
</li>
'
})
export class Todo {
@Input() todo;
constructor (public todoService: TodoService) {}
toggle (todo) {
this.todoService.toggle(todo);
}
}
While the implementation is different, the data flows and concepts between the Angular 1 and Angular 2 implementations are identical.
A service manages the list of Todos being rendered. The same service also manages adding and toggling of Todos. Both use a singleton instance of the TodoService so all components of the application are always referring to the same set of data. We mutate the array of Todos (and the individual Todos in the array) and rely on dirty checking to re-render.
Overall this is not a bad way to build an application. But as your applications grow, dependencies between components and the data they render can become cumbersome. It can make reasoning about your application difficult, and relying on data mutation and dirty checking can make testing harder.
Next we will look at a third way to build this simple application: With a one-way data flow.
Continue reading %Data Flows with Angular 2 and Redux%
I’m 85% deaf. I find it hard to understand those that speak even in the same dialect as me, so when I’m visiting different countries I have to make extra effort to try to understand the locals. Physical disabilities come in many different forms - some of them are invisible, like mine, and some are more obvious, but there’s one thing that they all have in common for sure:
[author_more]
Physical disabilities are hard to live with, especially when you’re a digital nomad that “lives” in a different country from one day to the next. With any disability, you have to consider the overall user experience of everyday spaces (supermarkets, travel hubs, et cetera), the quality of their emergency services, and of course there’s the question of medication.
Being disabled is an obstacle. It can’t be removed, but there are always ways around it -- and you shouldn’t let it stop you from becoming a digital nomad. Let's take a look at a few ways that we can make travel more accessible to the disabled.
If you’re travelling with medication (any medication) then there are a few things you must consider. Firstly, all airlines require a doctor’s certificate, as stated in their terms. Most of the time airport security won’t request to see it, but on the off chance that they do, you can be denied boarding, and the risk will surely vary depending on the type of medication.
As a Type 1 diabetic, I travel with both needles and insulin (which goes way over my 100ml*10 liquid limit), but even then I’ve only been stopped once. However, they did ask me a few questions and even called my doctor (your medical certificate must have the surgery name and doctor’s telephone number on it).
You also need to take more than enough medication to cover your entire trip and also confirm that your medication is available in the country you’re visiting. I always stock up whenever I visit home, but once, I did lose my entire stock of medication.
It was awful and scary because I did no research in advance!
Buying medication is a different story in every country. Even if it’s free or covered by health insurance, there is always a process that you must follow, so do your research first.
Emergency treatment is something entirely different - unless your home country and your destination have a treaty (for example, the UK have a European Health Insurance Card for emergencies), you are not entitled to it. You can’t assume that you’ll be taken care of in an urgent case, so always take out health insurance.
World Nomad Insurance is expertly designed for the frequent traveller, but you really should investigate a tonne of other alternatives - ask yourself (and them) all the right questions. Here’s a few to consider:
Continue reading %How to Overcome Physical Disabilities as a Digital Nomad%
I was working on a legacy project recently and needed to import some data from MySQL 5.5. All the queries in the code worked perfectly in MySQL 5.5, so I assumed an upgrade to 5.7 would be seamless. Not so.
First I got errors due to DateTime columns being populated with zeros during import, then when running this query:
select * from ebay_order_items where z_shipmentno is null and ExternalTransactionID is not null and orderstatus = 'Completed' and timestamp > '2015-02-25' group by ExternalTransactionID order by timestamp desc
I got this:
Expression #1 of SELECT list is not in GROUP BY clause and contains nonaggregated column '1066export.ebay_order_items.TransactionID' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by
Continue reading %Quick Tip: How to Permanently Change SQL Mode in MySQL%