What’s a Webhook?

A webhook (also called a web callback or HTTP push API) is a way for an app to provide other applications with real-time information. A webhook delivers data to other applications as it happens, meaning you get data immediately. Unlike typical APIs where you would need to poll for data very frequently in order to get it real-time. This makes webhooks much more efficient for both provider and consumer. The only drawback to webhooks is the difficulty of initially setting them up.

Screen Shot 2018-02-02 at 6.48.22 PM

Webhooks are sometimes referred to as “Reverse APIs,” as they give you what amounts to an API spec, and you must design an API for the webhook to use. The webhook will make an HTTP request to your app (typically a POST), and you will then be charged with interpreting it.

Consuming a Webhook

The first step in consuming a webhook is giving the webhook provider a URL to deliver requests to. This is most often done through a backend panel or an API. This means that you also need to set up a URL in your app that’s accessible from the public web.

The majority of webhooks will POST data to you in one of two ways: as JSON (typically) or XML (blech) to be interpreted, or as a form data (application/x-www-form-urlencoded or multipart/form-data). Your provider will tell you how they deliver it (or even give you a choice in the matter). Both of these are fairly easy to interpret, and most web frameworks will do the work for you. If they don’t, you may need to call on a function or two.

Important Gotchas

There are a couple things to keep in mind when creating webhook consumers:

  • Webhooks deliver data to your application and may stop paying attention after making a request. This means if your application has an error your data may be lost. Many webhooks will pay attention to responses and re-send requests if your application errors out. If your application processed the request and still sent an error, there may be duplicate data in your app. Understand how your webhook provider deals with responses so you can prepare for the possibility of application errors. Additionally, you may want to check out our tool Reflector.io for help dealing with webhook errors and queuing.
  • Webhooks can make a lot of requests. If your provider has a lot of events to tell you about, they may end up DDoSing your app. Make sure your application can handle the expected scale of your webhook. We made another tool, Loader.io, to help with that.

Get Your Feet Wet

The best way to truly understand a webhook is to try one. Luckily, lots of services use webhooks so you can easily play with them to your heart’s content. Check out some of the webhooks below:

Advertisements

Good Design vs Bad Design – Information overload

The Bad: Parking Signs in Los Angeles

Parking signs in Los Angeles (LA) have been the epitome of information overload for decades. They’ve always been notoriously hard to understand, because the traffic rules are complex, resulting in the need to convey a lot of information in a small area.

How confusing are these signs? Traditionally, very—look at this example from the 2010s:

Author/Copyright holder: Jorge Gonzalez. Copyright terms and licence: CC BY-SA 2.0

As LA parking signs go, this example is already a pretty simple one.

Imagine you are a driver along this road on a Tuesday morning at 9 a.m. Can you park at this spot? What sounds like a simple question takes a lot of mental processing to answer.

As designers, we’re often faced with situations where we have to design for a lot of information to be displayed in a small space. The parking signs in LA might be an extreme case, but many times designing for mobile apps means facing the same problems. Is there a way out—for both the parking signs and designers in general?

The Good: Nikki Sylianteng’s Parking Sign

Designing a sign to display all the information, while being easy to understand, sounds like an impossible task. But that’s exactly what Brooklyn designer Nikki Sylianteng did.

Author/Copyright holder: Nikki Sylianteng. Copyright terms and licence: CC BY-NC-SA 4.0

Nikki’s proposed parking sign was eventually used in LA as part of a trial run.

Part of why Nikki’s design1 works well is that it is user-centred: Nikki realised drivers simply want to know whether they can park at a spot. Yes or no—that’s all drivers needed, and that’s all the parking sign shows.

Her design also made use of visuals, rather than text, to convey information. The result is incredibly intuitive: green for OK, red for No Parking. It’s even designed for the colour blind, with stripes for No Parking.

Now when you look at the sign, you’ll know that on Tuesday at 9 a.m., parking is not allowed. The bars show what’s what at a glance—simple.

Lessons Learnt: Best Practice

  • Understand what your users need, then design based on that. This helps reduce information overload.
  • Have lots of information to convey to your users? Try using visuals instead of text. Learn more about data visualisation here.

Test Responsiveness of website by using viewport resizer chrome app

If you want the responsiveness of your website, here is excellent free tool (basically a chrome plugin) which will simulate different devices resolution.

Tool website : http://lab.maltewassermann.com/viewport-resizer/

Chrome store link for plugin in : https://chrome.google.com/webstore/detail/viewport-resizer/kapnjjcfcncngkadhpmijlkblpibdcgm?hl=en

viewPort_resizer.png

Here is video demo / tutorial

HTML5 – New Features

HTML5 – New Features

Some of the most interesting new features in HTML5:

  • The <canvas> element for 2D drawing
  • The <video> and <audio> elements for media playback
  • Support for local storage
  • New content-specific elements, like <article>, <footer>, <header>, <nav>, <section>
  • New form controls, like calendar, date, time, email, url, search

 

Removed Elements

The following HTML 4.01 elements are removed from HTML5:

  • <acronym>
  • <applet>
  • <basefont>
  • <big>
  • <center>
  • <dir>
  • <font>
  • <frame>
  • <frameset>
  • <noframes>
  • <strike>
  • <tt>

HTML5 has several new input types for forms. These new features allow better input control and validation.

  • date
  • datetime
  • datetime-local
  • email
  • month
  • number
  • color
  • range
  • search
  • tel
  • time
  • url
  • week

image

image

HTML5 Web Workers

When executing scripts in an HTML page, the page becomes unresponsive until the script is finished.

A web worker is a JavaScript that runs in the background, independently of other scripts, without affecting the performance of the page. You can continue to do whatever you want: clicking, selecting things, etc., while the web worker runs in the background.

Java programmers can easily co-relate this with a multi threading concept.

What is HTML5 Web Storage?

When web developers think of storing anything about the user, they immediately think of uploading to the server. HTML5 changes that, as there are now several technologies allowing the app to save data on the client device. It might also be sync’d back to the server, or it might only ever stay on the client: that’s down to you, the developer.

Earlier, this was done with cookies. However, Web Storage is more secure and faster. The data is not included with every server request, but used ONLY when asked for. It is also possible to store large amounts of data, without affecting the website’s performance. The data is stored in key/value pairs, and a web page can only access data stored by itself.

There are several reasons to use client-side storage. First, you can make your app work when the user is offline, possibly sync’ing data back once the network is connected again. Second, it’s a performance booster; you can show a large corpus of data as soon as the user clicks on to your site, instead of waiting for it to download again. Third, it’s an easier programming model, with no server infrastructure required. Of course, the data is more vulnerable and the user can’t access it from multiple clients, so you should only use it for non-critical data, in particular cached versions of data that’s also “in the cloud”.

Session Storage and Local Storage

It is important to know that there are two types of Web Storage objects:sessionStorage and localStorage.

sessionStorage is only available within the browser tab or window session. It’s designed to store data in a single web page session.

localStorage is kept even between browser sessions. This means data is still available when the browser is closed and reopened, and also instantly between tabs and windows.

Web Storage data is, in both cases, not available between different browsers. For example, storage objects created in Firefox cannot be accessed in Internet Explorer, exactly like cookies.

Cookies Vs Local Storage

HTML5 introduces two mechanisms, similar to HTTP session cookies, for storing structured data on the client side and to overcome following drawbacks.

  • Cookies are included with every HTTP request, thereby slowing down your web application by transmitting the same data.

  • Cookies are included with every HTTP request, thereby sending data unencrypted over the internet.

  • Cookies are limited to about 4 KB of data . Not enough to store required data.

Sample code to access local Storage
<!DOCTYPE HTML>
<html>
<body>

  <script type=”text/javascript”>
    if( localStorage.hits ){
       localStorage.hits = Number(localStorage.hits) +1;
    }else{
       localStorage.hits = 1;
    }
    document.write(“Total Hits :” + localStorage.hits );
  </script>
  <p>Refresh the page to increase number of hits.</p>
  <p>Close the window and open it again and check the result.</p>

</body>
</html>

Delete Web Storage:

Storing sensitive data on local machine could be dangerous and could leave a security hole.

The Session Storage Data would be deleted by the browsers immediately after the session gets terminated.

To clear a local storage setting you would need to call localStorage.remove(‘key’); where ‘key’ is the key of the value you want to remove. If you want to clear all settings, you need to call localStorage.clear() method.

CSS: div id VS. div class

what’s the difference between DIV class and DIV Id when it comes to css ?

ids must be unique where as class can be applied to many things. In CSS, ids look like#elementID and class elements look like .someClass

In general, use id whenever you want to refer to a specific element and class when you have a number of things that are all alike. For instance, common id elements are things like header,footer, sidebar. Common class elements are things like highlight or external-link.

It’s a good idea to read up on the cascade and understand the precedence assigned to various selectors: http://www.w3.org/TR/CSS2/cascade.html

The most basic precedence you should understand, however, is that id selectors take precedence over class selectors. If you had this:

<p id="intro" class="foo">Hello!</p>

and:

#intro { color: red }
.foo { color: blue }

The text would be red because the id selector takes precedence over the class selector.