All posts by admin

Why You can use Continuous Integration and Continuous Deployment

Having a nasty development workflow will cost you numerous. It could make your senior engineers be productive like juniors, or maybe worse push them to go away the corporate. an exceptional workflow could make push your good developers to be great and your best to be exceptional.

Getting this workflow so as is one of several most crucial steps any business and team can take.

Two best practices which have gained plenty of traction during the last years are Continuous Integration and Continuous Deployment.

Continuous Integration is the practice of testing each change done on your codebase automatically and as early as possible. But this paves the style for the more important process: Continuous Deployment.

Continuous Deployment follows your tests to push your changes to either a staging or production system. This makes sure a version of your code is often accessible.

First, allow us to take a look at Continuous Integration. I’ll show you ways to start with testing. Later we are going to speak about Continuous Deployment that is the subsequent logical step and can increase efficiency of your development team tremendously.

Continuous Integration

Every step on your development workflow that may be automated has to be. You will want this automation to be capable of focus your entire time on building your product and providing value for your customers. Testing is a type of steps where automation is prime.

Automated testing helps you to implement new features quickly, as you could always prove that your foremost features still work as you are expecting. This offers you the arrogance to experiment.

The way to start testing software

When starting testing your software it’s important to view the app from a user’s perspective. Let’s take a look:

  • What are the standard workflows?
  • What features do users suffer often?
  • What steps do users plow through often?

Get started with Selenium, PhantomJS or other frontend testing tools to ensure your application works as expected from the users perspective. Move from testing the user interface to testing lower level code, not the opposite direction around.

Often teams struggle with defining those first important test cases. We’ve provide you with a guide on the way to start testing, so have a look and notice if this works on your team besides.

Tools you need to use to begin testing your frontend:

Now that we have got a robust base of tests let’s go into lower levels and begin with Unit-Testing. We wish to be sure that the workflows are fine and that our UI works. With every change!

You have the tools, you understand how to do it. Now crucial thing is: Start with testing! It pays off immediately, not only from a software development perspective. You could examine the business advantages of constant Integration on this blog post by Joe Green.

Continuously running your tests

It’s too easy for us as developers to mention that a particular change won’t break something and later realise it did break the app. Often we’re just too lazy to essentially run all of our tests. It is where an automatic system that runs or tests whenever we do any changes continuously may help us from falling into the trap.

Oftentimes teams work on 2 week or maybe longer sprints. Initially of the sprint a developer pushes some changes that breaks a test. The team doesn’t have continuous integration, so nobody detects the mistake for per week. On the end of the sprint, before deploying to production, the lead developer runs all tests on a test machine to ensure everything is ok. And only at this point does the team detect the failed test. Now going back and determining which change broke the test is tough and takes a very long time, totally unnecessarily. The failing test might have been detected only minutes after it was pushed, but as there has been no automated system in place the team wasted precious time late within the sprint, as opposed to fixing it early on.

The longer the sprint, the more costly this cycle becomes. This workflow doesn’t help the team, the only developer and particularly not the corporate. Counting on automation to inform us early on when something goes wrong has to be on the core of your development workflow.

Continuous Integration is the primary, but vital step in Continuous Deployment.

Have a glance at Martin Fowler’s in-depth article about Continuous Integration to be informed more about it.

Continuous Deployment

Code rots. It is going to always run somewhere. There are various changes which may break your app without you realizing it. Consider external dependencies being updated, API’s changed, server packages installed… The list goes on. Often we don’t be able to manage every little thing of our infrastructure. We depend on other products and corporations to keep up parts of our stack.

This is where Continuous Deployment shows all of it’s power. Whenever your main code branch passes the tests it’s going to immediately be deployed to no less than a staging environment. Even better should you can visit production immediately. With the master branch running no less than on staging always have your QA or development team have a look or perhaps use this last version. This shortens the cycle until you discover an error or usability problem tremendously.
It moves finding those problems very early into the lifecycle, where it really is cheap to mend them, in place of late where you regularly can’t fix them to any extent further.

Configuring a deployment pipeline

Deployment pipelines describe how a transformation on your application moves through your infrastructure into production. It lays out all necessary automated and manual steps. Every step that may be automated have to be, to make the deployments as productive as possible.

Having this predefined workflow pipeline in place will you should definitely follow the whole necessary procedures in case you have to ship a fix quickly. A small mistake could mean a downtime, so counting on automation is important for this.

The ability to ship, get feedback out of your customers and iterate to your product quickly is a significant competitive advantage. Intercom wrote a blog about why shipping is your companies heartbeat. Especially when building the primary iterations of your product the significance of shipping quickly and frequently can’t be overstated.

Today, because the costs for creating and publishing software shrunk dramatically, it is very important to get your product on your customers quickly. Your competition has an identical cheap and productive tools available. Getting the main from your workflow and push your productivity to the following level is the right way to differentiate. Continuous deployment will let you make this happen.

Getting started

We’ve identified several steps which can allow you to start with continuous deployment. These steps have pop out of interviews with dozens of businesses and incessant feedback from the thousands of developers using our product.

Test everything, but in a sensible way

Automation is the important thing to pushing your productivity. Testing a crucial step to automate your entire qc. Once you wish to change your product it’s a must to be capable to quickly and automatically assess that everything still works. Attending to this point assures you may iterate and innovate quickly while not having to fret about breaking things. It allows to push much farther than you were ever able before.

Tests are initially a device to maintain your users happy. You don’t put effort into testing to make your development team happy or fulfill some vague workflow, but to make certain that you just don’t break stuff your customers use. And additionally also to have the ability to implement the subsequent features they would like and pay you for. So start testing with the user in mind. Start testing the Frontend and interactions there first, before moving to lower level tests. Remember we test to make our users happy, not only to create better software.

Tests make software as Clemens specified in his blog post.

Example

This script tests that after entering good day into google translate it’s properly translated from german into english.
With CasperJS you can begin testing your front-end quickly and move to more complex scenarios later.

Automate Deployment

Every step for your deployment should be automated. There can’t be any manual steps involved, as you’ll fail to do them once, as a way to kill your application. As you’re aware you automatically start deploying less often. This creates a vicious cycle where the fewer you deploy the more serious your deployment infrastructure becomes. Continuous Deployment works due to automation, so be sure you invest enough time here.

Automate Rollback

Automating rollbacks is important when pushing regularly. Or you will always fear to push more. Rollback includes your application code but additionally your database. Regular backups are an absolute must. Try and restore them regularly in addition, or you isn’t sure if it works until you desperately need them.

Deploy to Staging

Automatically push your master branch right into a staging application. The staging application is your first defensive position, so that you can easily review any changes going into production. This will even include automated tests, so that you know your staging server works fine.

Use your staging environment

Using your individual product is extremely helpful to choose problems to your application. While using your production server is okay, using your individual staging system is even better. It makes sure that you simply immediately detect errors which may take down your application, as you team always uses the most recent available codebase.

Automatically deploy to production

Finally deploy continuously on your production environment. This workflow will dramatically change the way in which your entire organization thinks about releasing software. It isn’t a little bit faster deployment, but must be planned and included for your daily work and planning. It’s been an incredible part within the innovation of a few of the most important tech companies on this planet and also you should give it a trie too.

Conclusions

Finding new how to become more productive is vital for each software team. Getting slower, especially compared to your competition, could easily harm or perhaps kill your organization and product. You would like to have the capacity to push quickly and often in your customers, in order that they get the precise product possible. Continuous Deployment can get you a ways there.

If any questions arise or if there’s the rest we will help tell us either here inside the comments or send us a tweet to @codeship. We’ve also recently released a free ebook that walks you thru our development workflows and may assist you to dive deeper into Continuous Deployment. You may grab the book here.

Exploring the Battery Status API

With the upward thrust in approval for mobile web apps there’s been a large push to develop device APIs that let web developers to achieve out of the browser and access the underlying device hardware. We’ve seen the introduction of getUserMedia, allowing you to access the device camera; the device orientation API, enabling the event of interactive gaming experiences; and the touch events API.

In this post you’re going to profit concerning the Battery Status API, another member within the family of device APIs which are helping to expand the capabilities of mobile web apps.

The BatteryManager Object

The Battery Status API permits you to access details about the device battery, including it’s charging status and current power level. This data is exposed throughout the BatteryManager object.

The BatteryManager object may be accessed at the global navigator object.

var battery = navigator.battery || navigator.mozBattery;

Older versions of Firefox used the seller-prefixed name mozBattery. The prefix was dropped in Firefox 16.

BatteryManager Properties

The BatteryManager object incorporates a selection of read only properties which might be used to accumulate details about the device’s power status.

Charging Status

The charging property is a boolean (true / false) value indicating whether the battery is currently charging or not.

navigator.battery.charging;

Charging Time

The chargingTime property represents the time in seconds until the battery is fully charged.

navigator.battery.chargingTime;

Discharging Time

The dischargingTime property represents the time in seconds until the battery is absolutely discharged and the system is suspended.

navigator.battery.dischargingTime;

Battery Level

The level property indicates the extent of charge within the battery, represented as a host between 0 and 1.

navigator.battery.level;

BatteryManager Events

As well as these four properties, the BatteryManager also defines quite a lot of events that may be used to observe changes in battery status.

Changes in Charging State

Changes to the charging property may be monitored by listening for the chargingchange event. This may be fired whenever the charging state changes. For instance, when the ability cord is plugged in, or the battery is full.

navigator.battery.onchargingchange = function(event) {
     // a metamorphosis in charging state occurred.
 };

Changes in Charging Time

The chargingtimechange event can be utilized to listen for changes inside the chargingtime property.

navigator.battery.onchargingtimechange = function(event) {
     // The charging time was updated.
 };

Changes in Discharging Time

The dischargingtimechange event is fired when the dischargingtime property is updated.

navigator.battery.ondischargingtimechange = function(event) {
     // The discharging time was updated.
 };

Changes in Battery Level

The levelchange event is used to trace changes to the extent of charge inside the battery.

navigator.battery.onlevelchange = function(event) {
     // The battery level changed.
 }

Browser Support for the Battery Status API

The Battery Status API is currently supported in Firefox 11+ (16+ for the the unprefixed API).

The API was previously implemented in Chromium but has since been removed after lengthy discussions across the specification and potential use cases.

An intent to implement was recently posted within the blink-dev discussion group, but there’s no indication of when (or if) this will likely make it into Blink.

As this API interacts with the underlying device hardware it’s impossible to create a polyfill which adds this functionality to other browsers.

The Battery Status API in Action

Battery Status API Demo

Battery Status API Demo

I’ve prepare an easy demo app to teach find out how to use the events and properties of the BatteryManager object to create a battery monitor. Explore the source code on codepen to determine the way it works.

See the Demo View on CodePen Download the Code

Summary

In this post you’ve learned easy methods to use the Battery Status API to watch a device’s power usage. Getting access to this data permits you to build applications which may adapt in response to different power conditions. For instance, you’re able to choose to not run battery-intensive animations if the device isn’t plugged right into a power source, or the battery is low.

Despite the somewhat troubled past this API has had in Chromium, I’m confident that we’ll see it reach more browsers one day. Until then you definitely can still use this API to progressively enhance the functionality of your web apps in Firefox.

What are your thoughts concerning the Battery Status API? Are you glad to look more device APIs being implemented, or is that this something you’re not that bothered about?

Accepting Speech Input in HTML5 Forms

The way that we interact with computers has changed dramatically during the last decade. Touch-screen devices and laptop trackpads have enabled a way more

Accepting Speech Input in HTML5 Forms

intuitive style of interaction than is achievable using a conventional mouse. These changes haven’t been limited to simply hardware. Gestures, predictive text, and speech recognition are all examples of software innovations that experience improved the best way wherein we interact with our devices.

Speech recognition has somewhat eluded innovators for many years. Many organizations have tried (with varying levels of success) to create reliable speech recognition technologies. There’s one company however that appears to have cracked the issue – Google.

In this post you’ll be learning the right way to make the most Google’s speech recognition technologies to reinforce your web forms. You’ll discover ways to give Chrome users the facility to fill-in text fields using speech, and the way to detect support for this new speech input capability in browsers.

Lets start.

Enabling Speech Input

Enabling support for speech input is so simple as adding an attribute on your <input> elements. The x-webkit-speech attribute will illustrate to the browser that the user must be given the choice to finish this manner field using speech input.

<input type="text" x-webkit-speech>

When speech input is enabled the element could have a small microphone icon displayed at the right of the input. Clicking in this icon will launch a small tooltip to point out that your voice is now being recorded. You may also start speech input by focussing the element and pressing Ctrl + Shift + . on Windows, or Command + Shift + . on Mac.

In JavaScript, you may test to work out if a component has speech input enabled by examining it’s webkitSpeech property. It is a boolean property and may therefore be set to true or false. You could override this property to enable or disable speech input on a factor.

// Enable
 element.webkitSpeech = true;

 // Disable
 element.webkitSpeech = false;

A Caveat About Input Types

Speech input isn’t available for the entire different HTML5 input types. In my testing i discovered that the text, number, and tel types do support speech input whereas the e-mail, url, date, and month input types don’t.

If you apply the x-webkit-speech attribute to an <input> element with an unsupported input type, the webkitSpeech property on that element will still be set to true. You therefore cannot depend on this property to inform if the browser is displaying the speech input controls, only that the browser supports speech input ordinarily.

Detecting Browser Support

A simple way of checking if the user’s browser supports speech input is to peer for the webkitSpeech property on an <input> element. An example of the way to do that is shown below.

if (document.createElement('input').webkitSpeech === undefined) {
     // Not supported
 } else {
     // Supported!
 }

Google Chrome is the best browser that currently supports speech input. We’ll examine the explanations for this within the next section.

How Speech Recognition Works

Speech-to-Text with a Web Service

Speech-to-Text with an online Service

The browser will depend on an external service to address speech-to-text conversion. The recording of your voice is distributed to this service which then analyses the audio and constructs a textual representation. The text is then sent back to the browser which populates the <input> element to finish the method. Many speech-to-text services incorporate machine-learning algorithms that let them to get more accurate over the years.

Note: an aspect effect of using an external service to address speech-to-text is that you’re going to need an online connection for speech input to work. This is often something to maintain in mind in case you plan to your web application to work offline.

The Chrome browser depends upon Google’s proprietary speech recognition technology to supply the functionality behind x-webkit-speech. Google has had a team engaged on speech recognition and natural language processing for a very long time. It’s this team that’s been accountable for developing the complex systems had to provide a competent speech-to-text service for products like Google Translate and Voice Search.

Note: If you’re involved in learning more about how speech-to-text works inspect the research papers published by Google engineers.

Developing speech-to-text services is extremely difficult and requires a major amount of investment. It’s probably the primary the reason for this is that no other browser vendor has implemented speech recognition yet. However, now that Apple has acquired Siri, I’m interested to work out if speech recognition will make it’s way into Safari a while soon.

Summary

In this post you’ve learned concerning the x-webkit-speech attribute and the way it could be used so as to add speech input capabilities on your web forms. There’s also a more advanced Web Speech API that we haven’t covered during this post. This API allows developers to feature speech recognition functionality to more aspects in their applications, or even synthesize speech from text.

Whether it’s within the computer in your desk, or the telephone on your pocket, software innovations like Google Voice Search and Siri are paving the way in which for a revolution in how we interact with computers. Welcome to the long run my friends, now if only someone could work out the entire teleportation thing.