Programming | 1081 articles | Tech News, Tutorials & Expert Insights

02 Jun 2015

5 min read

Filtering a sequence

02 Jun 2015

In this article by Ivan Morgillo, the author of RxJava Essentials, we will approach Observable filtering with RxJava filter(). We will manipulate a list on installed app to show only a subset of this list, according to our criteria. (For more resources related to this topic, see here.) Filtering a sequence with RxJava RxJava lets us use filter() to keep certain values that we don't want, out of the sequence that we are observing. In this example, we will use a list, but we will filter it, passing to the filter() function the proper predicate to include only the values we want. We are using loadList() to create an Observable sequence, filter it, and populate our adapter: private void loadList(List<AppInfo> apps) { mRecyclerView.setVisibility(View.VISIBLE); Observable.from(apps) .filter((appInfo) -> appInfo.getName().startsWith("C")) .subscribe(new Observer<AppInfo>() { @Override public void onCompleted() { mSwipeRefreshLayout.setRefreshing(false); } @Override public void onError(Throwable e) { Toast.makeText(getActivity(), "Something went south!", Toast.LENGTH_SHORT).show(); mSwipeRefreshLayout.setRefreshing(false); } @Override public void onNext(AppInfo appInfo) { mAddedApps.add(appInfo); mAdapter.addApplication(mAddedApps.size() - 1, appInfo); } }); } We have added the following line to the loadList() function: .filter((appInfo) -> appInfo.getName().startsWith("C")) After the creation of the Observable, we are filtering out every emitted element that has a name starting with a letter that is not a C. Let's have it in Java 7 syntax too, to clarify the types here: .filter(new Func1<AppInfo, Boolean>() { @Override public Boolean call(AppInfo appInfo) { return appInfo.getName().startsWith("C"); } }) We are passing a new Func1 object to filter(), that is, a function having just one parameter. The Func1 object has an AppInfo object as parameter type and it returns a Boolean object. The filter() function will return true only if the condition will be verified. At that point, the value will be emitted and received by all the Observers. As you can imagine, filter() is critically useful to create the perfect sequence that we need from the Observable sequence we get. We don't need to know the source of the Observable sequence or why it's emitting tons of different elements. We just want a useful subset of those elements to create a new sequence we can use in our app. This mindset enforces the separation and the abstraction skills of our coding day life. One of the most common use of filter() is filtering null objects: .filter(new Func1<AppInfo, Boolean>() { @Override public Boolean call(AppInfo appInfo) { return appInfo != null; } }) This seems to be trivial and there is a lot of boilerplate code for something that trivial, but this will save us from checking for null values in the onNext() call, letting us focus on the actual app logic. As result of our filtering, the next figure shows the installed apps list, filtered by name starting with C: Summary In this article, we introduced RxJava filter() function and we used it in a real-world example in an Android app. RxJava offers a lot more functions allowing you to filter and manipulate Observable sequences. A comprehensive list of methods, scenarios and example are available in RxJava that will drive you in a step-by-step journey, from the basic of the Observer pattern to composing Observables and querying REST API using RxJava. Resources for Article: Further resources on this subject: Android Native Application API [article] Android Virtual Device Manager [article] Putting It All Together – Community Radio [article]

0
0
796

Packt

02 Jun 2015

10 min read

Map/Reduce API

Packt

02 Jun 2015

10 min read

0
0
1345

article-image-creating-spring-application

Packt

25 May 2015

18 min read

Creating a Spring Application

Packt

25 May 2015

18 min read

0
0
5261

Packt

22 May 2015

20 min read

Practical Dart

Packt

22 May 2015

20 min read

This article is written by Martin Sikora, the author of Dart Essentials. This article will focus on the most common features of Dart that you'll use every day for your next Dart project. In this article, we'll look at: Future-Based API, Dart's built-in library for working with asynchronous calls Creating Ajax requests in Dart How packages work in Dart The whole article is intended to be very practical. We'll create a small app that reads a JSON dictionary and lets you search among all the terms in it. To make it more complicated, we'll implement a so-called fuzzy search algorithm, which doesn't search exact matches but the same order of characters instead. (For more resources related to this topic, see here.) The documentation search app We're going to write an app that can search among many terms and show some simple detail for each of them. The search input field will have an autocomplete feature with a list of all the terms that match our search string. Particularly, we'll use the documentation for PHP with 9,047 functions and write a fuzzy search algorithm that will search in it. Fuzzy search is used in IDEs such as PHPStorm or PyCharm and also in the popular text editor Sublime Text. It doesn't search just for the strings that start with your search term but it checks whether the order of characters in your term and in the checked string is the same. For example, if you type docfrg, it will find DocumentFragment because the letters in DocumentFragment are in the same order as docfrg. This is very handy because when there are a lot of functions with the same prefix, you can start typing with just the first character and then jump to the middle of the word and it's very likely that there won't be many functions with the same characters. This is quite common for PHP because there are a lot of functions that start with mysql or str_. If you're looking for a function called str_replace, you can type just splc. We'll load the entire dictionary with Ajax as a JSON string and decode it to a Map object. Dart uses the Future-Based API for all asynchronous calls including Ajax, so we should talk about it first. The Future-Based API Dart, as well as JavaScript, uses asynchronous calls a lot. A common pitfall of this approach in JavaScript is that it tends to make many nested function calls with callbacks: async1(function() { // do something async2(function() { // do something async3(function() { // do something callback(); }); }, callback); }); The downsides of this approach are obvious: It makes it hard to read and debug code, so-called callback hell. Each nested function can access variables from all parent scopes. This leads to variable shadowing and also prevents the JavaScript interpreter from deallocating unused variables. When working with a larger amount of data (for example, asynchronous calls when reading files), even simple script can use the entire available memory and cause the browser to crash. Future in Dart stands for an object that represents a value that will exist sometime in the future. Dart uses Future objects in nearly all their APIs, and we're going to use it in order to avoid passing callbacks around. An example of using Future is HttpRequest.getString(), which returns a Future object immediately and makes an asynchronous Ajax call: HttpRequest.getString('http://...').then(onDataReady); To work with the data returned from a Future object, we use the then() method, which takes the callback function as an argument that can return another Future object as well. If we want to create asynchronous behavior similar to that in the preceding example, we use the Completer class, which is a part of dart:async package. This class has a property called future, which represents our Future object and the complete() method, which resolves the Future object with some value. To keep the same order of function calls, we'll chain the then() methods of each Future object: import 'dart:async'; Future async1() { var completer = new Completer(); // Simulate long lasting async operation. new Future.delayed(const Duration(seconds: 2), () { // Resolve completer.future with this value. This will also // call callback passed to then() method for this Future. completer.complete('delayed call #1'); }); // Call to [Completer.complete()] resolves the Future object return completer.future; } Future async2(String val) { // Print result from the previous async call. print(val); // Then create a new Completer and schedule // it for later execution. var completer = new Completer(); // Simulate long lasting async operation. new Future.delayed(const Duration(seconds: 3), () { completer.complete('delayed call #2'); }); return completer.future; } Future async3(String val) { // Return another Future object. } void main() { // Chain async calls. Each function returns a Future object. async1() .then((String val) => async2(val)) .then((String val) => async3(val)) .then((String val) => print(val)); } We got rid of nested calls and have quite straightforward, shallow code. APIs similar to Dart's Future are very common among most JavaScript frameworks. Maybe you've already seen $.Deferred() in jQuery or $q.defer() in AngularJS. Future objects can also handle error states with catchError() that are emitted by a Completer object with completeError(). Another usage of Future is when we want a function to be called asynchronously, which is internally scheduled at the end of the event queue: new Future(() { // function body }); Sometimes, this is useful when you want to let the browser process all the events before executing more computationally intensive tasks that could make the browser unresponsive for a moment. For more in-depth information about Dart's event loop, see . Using keywords async and await Dart 1.9 introduced two new keywords, async and await, that significantly simplify the usage of asynchronous calls with the Future-Based API. Async The async keyword is used to mark a function's body, which immediately returns a Future object that is executed later and its return value is used to complete the Future object just like we saw previously when using the Completer class: Future<String> hello() async { return 'Hello, World!'; } In practice, you don't have to specify the Future<String> return type because even Dart Editor knows that the async function returns a Future object, so we'll omit it most of the time. This saves some writing but its real power comes in combination with await. Await With Future, the only way to chain (or simulate synchronous) calls is to use the then()method multiple times, as we saw earlier. But there's a new keyword await that is able to pause the execution of the current VM's thread and wait until Future is completed: String greetings = await hello(); The completed value of Future is then used as a value for the entire expression await hello(). In comparison to the preceding example of multiple asynchronous calls, we could use just: print(await async3(await async2(await async1()))); The only limitation here is that await must be used inside an asynchronous function (for example, defined with async) in order not to block the main execution thread. If the expression with await raises an exception, it's propagated to its caller. We're going to use async and await a lot here, but it's good to know how to use the "original" Future-Based API with the Future and Complete classes, because it will take some time for developers of third-party libraries to update their code with async and await. Dart 1.9 actually introduced even more keywords such as await-for, yield, async*, and a few more (also called generators), but these aren't very common and we're not going to discuss them here. If you want to know more about them, refer to https://www.dartlang.org/articles/beyond-async/. Creating Ajax requests in Dart Nearly every app these days uses Ajax. With libraries such as jQuery, it's very easy to make Ajax calls, and Dart is no different. Well, maybe the only difference is that Dart uses the Future-Based API. Creating an Ajax call and getting the response is this easy: String url = 'http://domain.com/foo/bar';Future ajax = HttpRequest.getString(url); ajax.then((String response) { print(response); }); // Or even easier with await. // Let's assume we're inside an asynchronous function. String response = await HttpRequest.getString(url); That's all. HttpRequest.getString() is a static method that returns a Future<String> object. When the response is ready, the callback function is called with the response as a string. You can handle an error state with catchError() method or just wrap the await expression with the try-catch block. By default, getString() uses the HTTP GET method. There are also more general static methods such as HttpRequest.request(), which returns Future<HttpRequest>, where you can access return code, response type, and so on. Also, you can set a different HTTP method if you want. To send form data via the POST method, the best way is to use HttpRequest.postFormData(), which takes a URL and a Map object with form fields as arguments. In this article, we'll use Ajax to load a dictionary for our search algorithm as JSON, and we'll also see JSONP in action later. Dart packages Every Dart project that contains the pubspec.yaml file is also a package. Our search algorithm is a nice example of a component that can be used in multiple projects, so we'll stick to a few conventions that will make our code reusable. Dart doesn't have namespaces like other languages, such as PHP, Java, or C++. Instead, it has libraries that are very similar in concept. We'll start writing our app by creating a new project with the Uber Simple Web Application template and creating two directories. First, we create /lib in the project's root. Files in this directory are automatically made public for anyone using our package. The second directory is /lib/src, where we'll put the implementation of our library, which is going to be private. Let's create a new file in /lib/fuzzy.dart: // lib/fuzzy.dart library fuzzy; part 'src/fuzzy_search.dart'; This creates a library called fuzzy. We could put all the code for this library right into fuzzy.dart, but that would be a mess. We'd rather split the implementation into multiple files and use the part keyword to tell Dart to make all the functions and classes defined in lib/src/fuzzy_search.dart public. One library can use the part keyword multiple times. Similar to object properties, everything that starts with the _ underscore is private and not available from the outside. Then, in lib/src/fuzzy_search.dart, we'll put just the basic skeleton code right now: // lib/src/fuzzy_search.dart part of fuzzy; class FuzzySearch { /* ... */ } The part of keyword tells Dart that this file belongs to the fuzzy library. Then, in main.dart, we need to import our own library to be able to use the FuzzySearch class: // web/main.dart import 'package:Chapter_02_doc_search/fuzzy.dart'; // ... later in the code create an instance of FuzzySearch. var obj = new FuzzySearch(); Note that the fuzzy.dart file is inside the lib directory, but we didn't have to specify it. The package importer is actually not working with directory names but package names, so Chapter_02_doc_search here is a package name from pubspec.yaml and not a directory, although these two have the same name. For more in-depth information about pubspec.yaml files, refer to https://www.dartlang.org/tools/pub/pubspec.html. You should end up with a structure like this: Note that the package has a reference to itself in the packages directory. One package can be a library and a web app at the same time. If you think about it, it's not total nonsense, because you can create a library and ship it with a demo app that shows what the library does and how to use it. You can read more about Dart packages at https://www.dartlang.org/tools/pub/package-layout.html. Writing the fuzzy search algorithm We can move on with writing the fuzzy search algorithm. A proper name for this algorithm would be probably approximate string matching, because our implementation is simpler than the canonical and we don't handle typos. Try to read the code: // lib/src/fuzzy_search.dartpart of fuzzy; class FuzzySearch { List<String> list; FuzzySearch(this.list); List<String> search(String term) { List<String> results = []; if (term.isEmpty) { return []; } // Iterate entire list. List<String> result = list.where((String key) { int ti = 0; // term index int si = 0; // key index // Check order of characters in the search // term and in the string key. for (int si = 0; si < key.length; si++) { if (term[ti] == key[si]) { ti++; if (ti == term.length) { return true; } } } return false; }).toList(growable: false); // Custom sort function. // We want the shorter terms to be first because it's more // likely that what you're looking for is there. result.sort((String a, String b) { if (a.length > b.length) { return 1; } else if (a.length == b.length) { return 0; } return -1; }); return result; } } The app itself will require a simple HTML code (we're omitting obvious surrounding code, such as <html> or <head>): <body> <input type="search" id="search" disabled> <ul id="autocomplete-results"></ul> <div id="detail"> <h1></h1> <div></div> </div> <script type="application/dart" src="main.dart"></script> <script data-pub-inline src="packages/browser/dart.js"></script> </body> We don't want to hardcode the dictionary, so we'll load it using Ajax. JSON file with all search terms, and it looks like this: { ... "strpos": { "desc": "Find the numeric position of the first occurrence of 'needle' in the 'haystack' string.", "name": "strpos" }, ... "pdo::commit": { "desc": "...", "name": "PDO::commit" }, ... } The key for each item is its lowercased name. In Dart, this JSON will be represented as: Map<String, Map<String, String>> Now, we'll write a static method that creates an instance of our app and the main() function: import 'dart:html'; import 'dart:convert'; import 'dart:async'; import 'package:Chapter_02_doc_search/fuzzy.dart'; class DocSearch { static fromJson(Element root, String url) async { String json = await HttpRequest.getString(url); Map decoded = JSON.decode(json); return new DocSearch(root, decoded); } DocSearch(Element root, [Map<String, dynamic> inputDict] { // Rest of the constructor. } // The rest of the class goes here. } main() async { try { await DocSearch.fromJson(querySelector('body'), 'dict.json'); } catch(e) { print("It's broken."); } } Note how we're creating an instance of DocSearch and are declaring main() as asynchronous. We call a DocSearch.fromJson()static method, which returns a Future object (the async keyword does this for us automatically), which is completed with an instance of DocSearch when the Ajax call is finished and when we decoded JSON into a Map object. The source code for this example contains both Dart 1.9 implementation with async and await and pre 1.9 version with the raw Future and Completer classes. Handling HTML elements You can see that if we hardcoded our dictionary, we could call the constructor of DocSearch like with any other class. We can now look at the constructor particularly: // web/main.dart class DocSearch { Element _root; InputElement _input; UListElement _ul; FuzzySearch _fuzzy; Map<String, dynamic> _dict; static Future fromJson(Element root, String url) async { /* The same as above. */ } DocSearch(Element root, [Map<String, dynamic> inputDict]) { _root = root; dict = inputDict; _input = _root.querySelector('input'); _ul = _root.querySelector('ul'); // Usage of ".." notation. _input ..attributes.remove('disabled') ..onKeyUp.listen((_) => search(_input.value)) ..onFocus.listen((_) => showAutocomplete()); _ul.onClick.listen((Event e) { Element target = e.target; showDetail(target.dataset['key']); }); // Pass only clicks that are not into <ul> or <input>. Stream customOnClick = document.onClick.where((Event e) { Element target = e.target; return target != _input && target.parent != _ul; }); customOnClick.listen((Event e) => hideAutocomplete()); } /* The rest of the class goes here. */ } To set multiple properties to the same object, we can use the double dot operator. This lets you avoid copying and pasting the same object name over and over again. This notation is equal to: _input.attributes.remove('disabled') _input.onKeyUp.listen((_) => search(_input.value)) _input.onFocus.listen((_) => showAutocomplete()); Of course, we can use it for more nested properties as well: elm.attributes ..remove('whatever') ..putIfAbsent('value', 'key') In the constructor, we're creating a custom Stream object, as we talked about earlier in this article. This stream passes only clicks outside our <ul> and <input> elements, which represent autocomplete container and a search input filed, respectively. We need to do this because we want to be able to hide the autocomplete when the user clicks outside of the search field. Using just onBlur in the input field (the lost focus event) wouldn't work as we wanted, because any click in the autocomplete would hide it immediately without emitting onClick inside the autocomplete. This is a nice place for custom streams. We could also make our stream a public property and let other developers bind listeners to it. In vanilla JavaScript, you would probably do this as an event that checks both conditions and emits a second event and then listen only to the second event. The rest of the code is mostly what we've already seen, but it's probably good idea to recap it in context. From now on, we'll skip obvious things such as DOM manipulation unless there's something important. We're also omitting CSS files because they aren't important to us: // web/main.dart class DocSearch { /* Properties are the same as above. */ static fromJson(Element root, String url) async { /* ... */ } DocSearch(Element root, [Map<String, dynamic> inputDict]) { /* ... */ } // Custom setter for dict property. When we change // the dictionary that this app uses, it will also change // the search list for the FuzzySearch instance. void set dict(Map<String, dynamic> dict) { _dict = dict; if (_fuzzy == null) { _fuzzy = new FuzzySearch(_dict.keys.toList()); } else { _fuzzy.list = _dict.keys.toList(); } } void search(String term) { if (term.length > 1) { int start = new DateTime.now().millisecondsSinceEpoch; List<String> results = _fuzzy.search(_input.value.toLowerCase()); int end = new DateTime.now().millisecondsSinceEpoch; // Debug performance. Note the usage of interpolation. print('$term: ${(end - start).toString()} ms'); renderAutocomplete(results); } else { hideAutocomplete(); } } void renderAutocomplete(List<String> list) { if (list.length == 0) hideAutocomplete(); } // We'll use DocumentFragment as we talked about earlier. // http://jsperf.com/document-fragment-test-peluchetti DocumentFragment frag = new DocumentFragment(); list.forEach((String key) { LIElement li = new LIElement(); li.text = _dict[key]['name']; // Same as creating 'data-key' attribute or using data() // method in jQuery. li.dataset['key'] = key; frag.append(li); }); _ul.children.clear(); _ul.append(frag.clone(true)); showAutocomplete(); } void showDetail(String key) { Map<String, String> info = _dict[key]; _root.querySelector('#detail > h1').text = info['name']; String desc = info['desc'] ..replaceAll('\n\n', '</p><p>') ..replaceAll('\_', '_'); _root.querySelector('#detail > div').innerHtml = '<p>' + desc + '</p>'; hideAutocomplete(); } void showAutocomplete() { _ul.style.display = 'block'; } void hideAutocomplete() { _ul.style.display = 'none'; } } Note that we defined a custom setter for the dict property, so when we change it from anywhere in the code, it also changes the list property in the instance of the FuzzySearch class. Dart allows writing both custom getters and setters: void set property(<T> newValue) { // Custom logic here. } <T> get property { // Custom logic here. // return an instance of <T> } Finally, we can test it in the browser: When you type at least two characters in the search field, it opens autocomplete with suggested function names. You can click on one of them; it closes the autocomplete and shows a simple detail window with its name and description. You can open Developer Tools and see how much time it took for Dart to traverse the entire 9,047 string list (it's about 25 ms in Intel Core Duo 2.5 GHz). As we're already creating the FuzzySearch class as a reusable library, it would be nice if we could use it not just in Dart but also in JavaScript. Summary This article focused on a very practical aspect of Dart. From Streams and the Future-Based API to Ajax, Dart 1.9 took a significant step forward in simplifying the usage of asynchronous APIs using new async and await keywords. If you don't find yourself familiar with the Future-Based API, at least try to understand the new async and await features and try to compare Dart's approach to an asynchronous code to what you already know from JavaScript. Resources for Article: Further resources on this subject: Handling the DOM in Dart [article] Handle Web Applications [article] Dart with JavaScript [article]

0
0
1421

Packt

22 May 2015

27 min read

Financial Derivative – Options

Packt

22 May 2015

27 min read

0
0
1038

article-image-vrops-introduction-and-architecture

Packt

22 May 2015

10 min read

vROps – Introduction and Architecture

Packt

22 May 2015

10 min read

0
0
6830

article-image-learning-selenium-testing-tools-python

Packt

08 May 2015

3 min read

Learning Selenium Testing Tools with Python

Packt

08 May 2015

3 min read

0
0
2175

article-image-learning-r-geospatial-analysis

Packt

08 May 2015

3 min read

Learning R for Geospatial Analysis

Packt

08 May 2015

3 min read

The defining feature of spatial data analysis is the reference, within the data being analyzed, to locations on the surface of the earth. This is a very broad subject encompassing distinct areas of expertise such as spatial statistics, geometric computation, and image processing. In practice, spatial data is commonly stored, viewed, and analyzed in Geographic Information System (GIS) software, of which the most well-known example is ArcGIS. However, most often, menu-based interfaces of GIS software are too narrow in scope to meet with specialized demands or too inflexible to feasibly accomplish customized, repetitive tasks. Writing scripts rather than using menus or working in combination with external software are two commonly used paths to solve such problems. However, what if we can use a single environment, combining the advantages of programming and spatial data analysis capabilities with a comprehensive ecosystem of computational tools that are readily implementable in customized procedures? This book will demonstrate that the R programming language is indeed such an environment and teach you how to use it in order to perform various spatial data analysis tasks. (For more resources related to this topic, see here.) What you will learn This book covers the basic concepts related to writing R code. You will also learn how to work with vectors, time series, tables, rasters, points, lines, and polygons. The book also covers several advanced themes associated with raster data analysis in R. Demonstrations on how rasters and vector layers can be combined in a single analysis are shown. Transformation between raster and vector data structures as well as data extraction from a raster based on vector layers are covered in this book. Moreover, we will also learn how spatial interpolation can be carried out in R through examples of interpolating meteorological point measurements to create annual temperature maps of Spain. You will also explore some of the most useful methods for advanced visualization of spatial data in R, using the ggplot2, ggmap, and lattice packages. How the book differs Most currently available books on this subject are focused on advanced applications such as spatial statistics, assuming you have prior knowledge of R and the respective scientific domains. Yet, introductory material on R from the point of view of a spatial data analyst, which is focused on introductory topics such as spatial data handling, computation, and visualization, is scarce. This book aims to fill the gap. Thus, this book is intended for anyone who wants to learn how to efficiently analyze geospatial data with R. No prior experience with R and/or programming is required; only you need to be familiar with basic geographic information concepts (such as spatial coordinates). Required skills To follow through the examples in this book, all you need to do is install R (which is available for free) and download the example datasets from the book's website. Some of the examples also require you to have an Internet connection to download additional datasets and R packages from the R environment. Summary This book is composed of step-by-step tutorials, starting with the language basics before proceeding to cover the main GIS operations and data types. Visualization of spatial data is vital either during the various analysis steps and/or as the final product, and this book shows you how to get the most out of R's visualization capabilities. The book culminates with examples of cutting-edge applications utilizing R's strengths as a statistical and graphical tool. Resources for Article: Further resources on this subject: Data visualization [article] Machine Learning in Bioinformatics [article] Specialized Machine Learning Topics [article]

0
0
2657

article-image-ensuring-five-star-rating-marketplace

Packt

05 May 2015

43 min read

Ensuring Five-star Rating in the MarketPlace

Packt

05 May 2015

43 min read

0
0
1201

Packt

04 May 2015

7 min read

Git Teaches – Great Tools Don't Make Great Craftsmen

Packt

04 May 2015

7 min read

This article is written by Ferdinando Santacroce, author of the book, Git Essentials. (For more resources related to this topic, see here.) Git is a powerful tool. In case you need to retain multiple versions of files—even if you may not be a software developer—Git can perform this task easily. As a Git user, in my humble career, I have never found a dead-end street—a circumstance where I had to give up because of a lack of solutions. Git always offers a wide range of alternatives even when you make a mistake; you can use either git revert to revert your change, or git reset if there is no need to preserve the previous commit. Another key strength of Git is its ability to let your project grow and take different ways when needed. Git branching is a killer feature of this tool. Every versioning system is able to manage branches. However in Git, using this feature is a pleasure; it is super-fast (it does all the work locally), and it does not require a great amount of space. For those who are used to work with other versioning systems such as Subversion, this probably makes a difference. In my career as a developer, I have assisted in situations where developers wouldn't create new branches for new features, because branching was a time-consuming process. Their versioning system, on large repositories, required 5-6 minutes to create a new branch. Git usually doesn't concede alibis. The git branch command and the consecutive git merge operations are fast and very reliable. Even when you commit, git commit doesn't allow you to store a new commit without a message to protect you from our laziness and grow a talking repository with a clear history and not a mute one. However, Git can't perform miracles. So, to get the most out of it, we need a little discipline. This discipline distinguishes an apprentice from a good craftsman. One of the most difficult things in software development is with regard to the sharing of a common code base. Often, programmers are solitary people who love instructions that are typed in their preferred editor, which helps them make working software without any hassles. However, in professional software development, you usually deal with big projects that require more than a single developer at a time; everyone contributes their own code. At this point, if you don't have an effective tool to share code like Git and a little bit of discipline, you can easily screw up. When I talk about discipline, I talk about two main concepts—writing good commits and using the right workflow. Let's start with the first point. What is a good commit? What makes a commit either good or bad? Well, you will come across highly opinionated answers to this question. So here, I will provide mine. First of all, good commits are those commits that do not mix apples and oranges; when you commit something, you have to focus on resolving one problem at a time (fix a bug and implement a new feature or make a clear step forward towards the final target) without modifying anything that is not strictly related to the task you are working on. While writing some code, especially when you have to refactor or modify the existing code, you may too often fall into the temptation to fix here and there some other things. This is just your nature, I know. Developers hate ugly code, even though they often are the ones who wrote it some time ago; they can't leave it there even for a minute. It's a compulsive reaction. So, in a matter of a few minutes, you end up with a ton of modified files with dozens of cross-modifications that are quite difficult to comment in a commit message. They are also hard to merge and quite impossible to cherry-pick, if necessary. So, one of the first things that you have to learn is to make consistent commits. It has to became a habit, and we all know that habits are hard to grow and hard to break. There are some simple tricks that have helped me become a better committer day by day (yes, I'm still far from becoming a good committer). One of the most effective tricks that you can use to make consistent commits is to have a pencil and a paper with you; when you find something wrong with your code that is not related to what you are working on at the moment, pick up the pencil and write down a note on a piece of paper. Don't work on it immediately. However, remind yourself that there is something that you have to fix in the next commit. In the same manner, when you feel that the feature you're going to implement either is too wide for a single commit, or requires more than a bunch of hours to terminate (I tend to avoid long coding sessions), make an effort and try to split the work in two or three parts, writing down these steps on the paper. Thus, you are unconsciously wrapping up your next commits. Another way to avoid a loss of focus is to write the commit message before you start coding. This may sound a little weird, but having the target of your actual work in front of your eyes helps a lot. If you practice Test Driver Development (TDD), or even better, Behavior Drive Development (BDD), you probably already know that they have a huge side-effect despite their main testing purpose—they force you to look at the final results, maintaining the focus on what the code has to do, and not the implementation details. Writing preemptive commit messages is the same thing. When the target of your commit is clear and you can keep an eye on it every time you look at your paper notebook, then you know that you can code peacefully because you will not go off the rails. Now that we have a clear vision of what makes a good commit, let's move your attention to good workflows. Generally speaking, the sharing of a common way to work is the most taken-for-granted advice that you can give. However, it often represents exactly the biggest problem when you look at underperforming firms. Having a versioning workflow that is decided with the help of common agreement is the most important thing about a development team (even for a team of one) because it lets you feel comfortable even in case of emergency. When I talk about emergencies, I talk about common hitches for a software developer—urgently fixing a bug on a specific software version, developing different features in parallel, and building beta or testing versions to let testers and users give you feedback. There are plenty of good Git workflows out there. You can take inspiration from them. You can use a workflow as it is, or you can take some inspiration and adapt it to fit your project peculiarities. However, the important thing is that you have to keep on using it not only to be consistent (don't cheat!), but also to adapt it when premises change. Don't blindly follow a workflow if you don't feel comfortable with it, and don't even try to use the same workflow every time. There are good workflows for web projects where there's usually no need to keep multiple versions of the same software and the ones that fit desktop applications better, where multiple versions are the order of the day. Every kind of project needs its perfectly tailored workflow. The last thing I wish to suggest to the developers interested in Git is to share common sense. Good developers share coding standards, and a good team has to share the same committing policy and the same workflow. Lone cowboys and outlaws represent a problem even in software development, and not just in Spaghetti Western movies. Resources for Article: Further resources on this subject: Configuration [article] Maintaining Your GitLab Instance [article] Searching and Resolving Conflicts [article]

0
0
735

article-image-getting-started-codeception

Packt

04 May 2015

17 min read

Getting started with Codeception

Packt

04 May 2015

17 min read

In this article by Matteo Pescarin, the author of Learning Yii Testing, we will get introduced to Codeception. Not everyone has been exposed to testing. The ones who actually have are aware of the quirks and limitations of the testing tools they've used. Some might be more efficient than others, and in either case, you had to rely on the situation that was presented to you: legacy code, hard to test architectures, no automation, no support whatsoever on the tools, and other setup problems, just to name a few. Only certain companies, because they have either the right skillsets or the budget, invest in testing, but most of them don't have the capacity to see beyond the point that quality assurance is important. Getting the testing infrastructure and tools in place is the immediate step following getting developers to be responsible for their own code and to test it. (For more resources related to this topic, see here.) Even if testing is something not particularly new in the programming world, PHP always had a weak point regarding it. Its history is not the one of a pure-bred programming language done with all the nice little details, and only just recently has PHP found itself in a better position and started to become more appreciated. Because of this, the only and most important tool that came out has been PHPUnit, which was released just 10 years ago, in 2004, thanks to the efforts of Sebastian Bergmann. PHPUnit was and sometimes is still difficult to master and understand. It requires time and dedication, particularly if you are coming from a non-testing experience. PHPUnit simply provided a low-level framework to implement unit tests and, up to a certain point, integration tests, with the ability to create mocks and fakes when needed. Although it still is the quickest way to discover bugs, it didn't cover everything and using it to create large integration tests will end up being an almost impossible task. On top of this, PHPUnit since version 3.7, when it switched to a different autoloading mechanism and moved away from PEAR, caused several headaches rendering most of the installations unusable. Other tools developed since mostly come from other environments and requirements, programming languages, and frameworks. Some of these tools were incredibly strong and well-built, but they came with their own way of declaring tests and interacting with the application, set of rules, and configuration specifics. A modular framework rather than just another tool Clearly, mastering all these tools required a bit of understanding, and the learning curve wasn't promised to be the same among all of them. So, if this is the current panorama, why create another tool if you will end up in the same situation we were in before? Well, one of the most important things to be understood about Codeception is that it's not just a tool, rather a full stack, as noted on the Codeception site, a suite of frameworks, or if you want to go meta, a framework for frameworks. Codeception provides a uniform way to design different types of test by using as much as possible the same semantic and logic, a way to make the whole testing infrastructure more coherent and approachable. Outlining concepts behind Codeception Codeception has been created with the following basic concepts in mind: Easy to read: By using a declarative syntax close to the natural language, tests can be read and interpreted quite easily, making them an ideal candidate to be used as documentation for the application. Any stakeholder and engineer close to the project can ensure that tests are written correctly and cover the required scenarios without knowing any special lingo. It can also generate BDD-style test scenarios from code test cases. Easy to write: As we already underlined, every testing framework uses its own syntax or language to write tests, resulting in some degree of difficulty when switching from one suite to the other, without taking into account the learning curve each one has. Codeception tries to bridge this gap of knowledge by using a common declarative language. Further, abstractions provide a comfortable environment that makes maintenance simple. Easy to debug: Codeception is born with the ability to see what's behind the scenes without messing around with the configuration files or doing random print_r around your code. On top of this all, Codeception has also been written with modularity and extensibility in mind, so that organizing your code is simple while also promoting code reuse throughout your tests. But let's see what's provided by Codeception in more detail. Types of tests As we've seen, Codeception provides three basic types of test: Unit tests Functional tests Acceptance tests Each one of them is self-contained in its own folder where you can find anything needed, from the configuration and the actual tests to any additional piece of information that is valuable, such as the fixtures, database snapshots, or specific data to be fed to your tests. In order to start writing tests, you need to initialize all the required classes that will allow you to run your tests, and you can do this by invoking codecept with the build argument: $ cd tests $ ../vendor/bin/codecept build Building Actor classes for suites: functional, acceptance, unit FunctionalTester includes modules: Filesystem, Yii2 FunctionalTester.php generated successfully. 61 methods added AcceptanceTester includes modules: PhpBrowser AcceptanceTester.php generated successfully. 47 methods added UnitTester includes modules: UnitTester.php generated successfully. 0 methods added $ The codecept build command needs to be run every time you modify any configuration file owned by Codeception when adding or removing any module, in other words, whenever you modify any of the .suite.yml files available in the /tests folder. What you have probably already noticed in the preceding output is the presence of a very peculiar naming system for the test classes. Codeception introduces the Guys that have been renamed in Yii terminology as Testers, and are as follows: AcceptanceTester: This is used for acceptance tests FunctionalTester: This is used for functional tests UnitTester: This is used for unit tests These will become your main interaction points with (most of) the tests and we will see why. By using such nomenclature, Codeception shifts the point of attention from the code itself to the person that is meant to be acting the tests you will be writing. This way we will become more fluent in thinking in a more BDD-like mindset rather than trying to figure out all the possible solutions that could be covered, while losing the focus of what we're trying to achieve. Once again, BDD is an improvement over TDD, because it declares in a more detailed way what needs to be tested and what doesn't. AcceptanceTester AcceptanceTester can be seen as a person who does not have any knowledge of the technologies used and tries to verify the acceptance criteria that have been defined at the beginning. If we want to re-write our previously defined acceptance tests in a more standardized BDD way, we need to remember the structure of a so-called user story. The story should have a clear title, a short introduction that specifies the role that is involved in obtaining a certain result or effect, and the value that this will reflect. Following this, we will then need to specify the various scenarios or acceptance criteria, which are defined by outlining the initial scenario, the trigger event, and the expected outcome in one or more clauses. Let's discuss login using a modal window, which is one of the two features we are going to implement in our application. Story title – successful user login I, as an acceptance tester, want to log in into the application from any page. Scenario 1: Log in from the homepage I am on the homepage. I click on the login link. I enter my username. I enter my password. I press submit. The login link now reads "logout (<username>)" and I'm still on the homepage. Scenario 2: Log in from a secondary page I am on a secondary page. I click on the login link. I enter my username. I enter my password. I press Submit. The login link now reads "logout (<username>)" and I'm still on the secondary page. As you might have noticed I am limiting the preceding example to successful cases. The preceding story can be immediately translated into something along the lines of the following code: // SuccessfulLoginAcceptanceTest.php $I = new AcceptanceTester($scenario); $I->wantTo("login into the application from any page"); // scenario 1 $I->amOnPage("/"); $I->click("login"); $I->fillField("username", $username); $I->fillField("password", $password); $I->click("submit"); $I->canSee("logout (".$username.")"); $I->seeInCurrentUrl("/"); // scenario 2 $I->amOnPage("/"); $I->click("about"); $I->seeLink("login"); $I->click("login"); $I->fillField("username", $username); $I->fillField("password", $password); $I->click("submit"); $I->canSee("logout (".$username.")"); $I->amOnPage("about"); As you can see this is totally straightforward and easy to read, to the point that anyone in the business should be able to write any case scenario (this is an overstatement, but you get the idea). Clearly, the only thing that is needed to understand is what the AcceptanceTester is able to do: The class generated by the codecept build command can be found in tests/codeception/acceptance/AcceptanceTester.php, which contains all the available methods. You might want to skim through it if you need to understand how to assert a particular condition or perform an action on the page. The online documentation available at http://codeception.com/docs/04-AcceptanceTests will also give you a more readable way to get this information. Don't forget that at the end AcceptanceTester is just a name of a class, which is defined in the YAML file for the specific test type: $ grep class tests/codeception/acceptance.suite.yml class_name: AcceptanceTester Acceptance tests are the topmost level of tests, as some sort of high-level user-oriented integration tests. Because of this, acceptance tests end up using an almost real environment, where no mocks or fakes are required. Clearly, we would need some sort of initial state that we can revert to, particularly if we're causing actions that modify the state of the database. As per Codeception documentation, we could have used a snapshot of the database to be loaded at the beginning of each test. Unfortunately, I didn't have much luck in finding this feature working. So later on, we'll be forced to use the fixtures. Everything will then make more sense. When we will write our acceptance tests, we will also explore the various modules that you can also use with it, such as PHPBrowser and Selenium WebDriver and their related configuration options. FunctionalTester As we said earlier, FunctionalTester represents our character when dealing with functional tests. You might think of functional tests as a way to leverage on the correctness of the implementation from a higher standpoint. The way to implement functional tests bears the same structure as that of acceptance tests, to the point that most of the time the code we've written for an acceptance test in Codeception can be easily swapped with that for a functional test, so you might ask yourself: "where are the differences?" It must be noted that the concept of functional tests is something specific to Codeception and can be considered almost the same as that of integration tests for the mid-layer of your application. The most important thing is that functional tests do not require a web server to run, and they're called headless: For this reason, they are not only quicker than acceptance tests, but also less "real" with all the implications of running on a specific environment. And it's not the case that the acceptance tests provided by default by the basic application are, almost, the same as the functional tests. Because of this, we will end up having more functional tests that will cover more use cases for specific parts of our application. FunctionalTester is somehow setting the $_GET, $_POST and $_REQUEST variables and running the application from within a test. For this reason, Codeception ships with modules that let it interact with the underlying framework, be it Symfony2, Laravel4, Zend, or, in our case, Yii 2. In the configuration file, you will notice the module for Yii 2 already enabled: # tests/functional.suite.yml class_name: FunctionalTester modules: enabled: - Filesystem - Yii2 # ... FunctionalTester has got a better understanding of the technologies used although he might not have the faintest idea of how the various features he's going to test have been implemented in detail; he just knows the specifications. This makes a perfect case for the functional tests to be owned or written by the developers or anyone that is close to the knowledge of how the various features have been exposed for general consumption. The base functionality of the REST application, exposed through the API, will also be heavily tested, and in this case, we will have the following scenarios: I can use POST to send correct authentication data and will receive a JSON containing the successful authentication I can use POST to send bad authentication data and will receive a JSON containing the unsuccessful authentication After a correct authentication, I can use GET to retrieve the user data After a correct authentication, I will receive an error when doing a GET for a user stating that it's me I can use POST to send my updated hashed password Without a correct authentication, I cannot perform any of the preceding actions The most important thing to remember is that at the end of each test, it's your responsibility to keep the memory clean: The PHP application will not terminate after processing a request. All requests happening in the same memory container are not isolated. If you see your tests failing for some unknown reason when they shouldn't, try to execute a single test separately. UnitTester I've left UnitTester for the end as it's a very special guy. For all we know, until now, Codeception must have used some other framework to cover unit tests, and we're pretty much sure that PHPUnit is the only candidate to achieve this. If any of you have already worked with PHPUnit, you will remember the learning curve together with the initial problem of understanding its syntax and performing even the simplest of tasks. I found that most developers have a love-and-hate relationship with PHPUnit: either you learn its syntax or you spend half of the time looking at the manual to get to a single point. And I won't blame you. We will see that Codeception will come to our aid once again if we're struggling with tests: remember that these unit tests are the simplest and most atomic part of the work we're going to test. Together with them come the integration tests that cover the interaction of different components, most likely with the use of fake data and fixtures. If you're used to working with PHPUnit, you won't find any particular problems writing tests; otherwise, you can make use of UnitTester and implement the same tests by using the Verify and Specify syntax. UnitTester assumes a deep understanding of the signature and how the infrastructure and framework work, so these tests can be considered the cornerstone of testing. They are super fast to run, compared to any other type of test, and they should also be relatively easy to write. You can start with adequately simple assertions and move to data providers before needing to deal with fixtures. Other features provided by Codeception On top of the types of tests, Codeception provides some more aids to help you organize, modularize, and extend your test code. As we've seen, functional and acceptance tests have a very plain and declarative structure, and all the code and the scenarios related to specific acceptance criteria are kept in the same file at the same level and these are executed linearly. In most of the situations, as it is in our case, this is good enough, but when your code starts growing and the number of components and features become more and more complex, the list of scenarios and steps to perform an acceptance or functional test can be quite lengthy. Further, some tests might end up depending on others, so you might want to start considering writing more compact scenarios and promote code reuse throughout your tests or split your test into two or more tests. If you feel your code needs a better organization and structure, you might want to start generating CEST classes instead of normal tests, which are called CEPT instead. A CEST class groups the scenarios all together as methods as highlighted in the following snippet: <?php // SuccessfulLoginCest.php class SuccessfulLoginCest { public function _before(CodeceptionEventTestEvent $event) {} CodeceptionEventTestEvent $event public function _fail(CodeceptionEventTestEvent $event) {} // tests public function loginIntoTheApplicationTest(AcceptanceTester $I) { $I->wantTo("login into the application from any page"); $I->amOnPage("/"); $I->click("login"); $I->fillField("username", $username); $I->fillField("password", $password); $I->click("submit"); $I->canSee("logout (".$username.")"); $I->seeInCurrentUrl("/"); // ... } } ?> Any method that is not preceded by the underscore is considered a test, and the reserved methods _before and _after are executed at the beginning and at the end of the list of tests contained in the test class, while the _fail method is used as a cleanup method in case of failure. This alone might not be enough, and you can use document annotations to create reusable code to be run before and after the tests with the use of @before <methodName> and @after <methodName>. You can also be stricter and require a specific test to pass before any other by using the document annotation @depends <methodName>. We're going to use some of these document annotations, but before we start installing Codeception, I'd like to highlight two more features: PageObjects and StepObjects. The PageObject is a common pattern amongst test automation engineers. It represents a web page as a class, where its DOM elements are properties of the class, and methods instead provide some basic interactions with the page. The main reason for using PageObjects is to avoid hardcoding CSS and XPATH locators in your tests. Yii provides some example implementation of the PageObjects used in /tests/codeception/_pages. StepObject is another way to promote code reuse in your tests: It will define some common actions that can be used in several tests. Together with PageObjects, StepObjects can become quite powerful. StepObject extends the Tester class and can be used to interact with the PageObject. This way your tests will become less dependent on a specific implementation and will save you the cost of refactoring when the markup and the way to interact with each component in the page changes. For future reference, you can find all of these in the Codeception documentation in the section regarding the advanced use at http://codeception.com/docs/07-AdvancedUsage together with other features, like grouping and an interactive console that you can use to test your scenarios at runtime. Summary In this article, we got hands-on with Codeception and looked at the different types of tests available. Resources for Article: Further resources on this subject: Building a Content Management System [article] Creating an Extension in Yii 2 [article] Database, Active Record, and Model Tricks [article]

0
0
2692

Packt

30 Apr 2015

17 min read

Welcome to the Spring Framework

Packt

30 Apr 2015

17 min read

0
0
4031

article-image-auto-updating-child-records-process-builder

Packt

29 Apr 2015

5 min read

Auto updating child records in Process Builder

Packt

29 Apr 2015

5 min read

In this article by Rakesh Gupta, the author of the book Learning Salesforce Visual Workflow, we will discuss how to auto update child records using Process Builder of Salesforce. There are several business use cases where a customer wants to update child records based on some criteria, for example, auto-updating all related Opportunity to Closed-Lost if an account is updated to Inactive. To achieve these types of business requirements, you can use the Apex trigger. You can also achieve these types of requirements using the following methods: Process Builder A combination of Flow and Process Builder A combination of Flow and Inline Visualforce page on the account detail page (For more resources related to this topic, see here.) We will use Process Builder to solve these types of business requirements. Let's start with a business requirement. Here is a business scenario: Alice Atwood is working as a system administrator in Universal Container. She has received a requirement that once an account gets activated, the account phone must be synced with the related contact asst. phone field. This means whenever an account phone fields gets updated, the same phone number will be copied to the related contacts asst. phone field. Follow these instructions to achieve the preceding requirement using Process Builder: First of all, navigate to Setup | Build | Customize | Accounts | Fields and make sure that the Active picklist is available in your Salesforce organization. If it's not available, create a custom Picklist field with the name as Active, and enter the Yes and No values. To create a Process, navigate to Setup | Build | Create | Workflow & Approvals | Process Builder, click on New Button, and enter the following details: Name: Enter the name of the Process. Enter Update Contacts Asst Phone in Name. This must be within 255 characters. API Name: This will be autopopulated based on the name. Description: Write some meaningful text so that other developers or administrators can easily understand why this Process is created. The properties window will appear as shown in the following screenshot: Once you are done, click on the Save button. It will redirect you to the Process canvas, which allows you to create or modify the Process. After Define Process Properties, the next task is to select the object on which you want to create a Process and define the evaluation criteria. For this, click on the Add Object node. It will open an additional window on the right side of the Process canvas screen, where you have to enter the following details: Object: Start typing and then select the Account object. Start the process: For Start the process, select when a record is created or edited. This means the Process will fire every time, irrespective of record creation or updating. Allow process to evaluate a record multiple times in a single transaction?: Select this checkbox only when you want the Process to evaluate the same record up to five times in a single transaction. It might re-examine the record because a Process, Workflow Rule, or Flow may have updated the record in the same transaction. In this case, leave this unchecked. This window will appear as shown in the following screenshot: Once you are done with adding the Process criteria, click on the Save button. Similar to the Workflow Rule, once you save the panel, it doesn't allow you to change the selected object. After defining the evaluation criteria, the next step is to add the Process criteria. Once the Process criteria are true, only then will the Process execute the associated actions. To define the Process criteria, click on the Add Criteria node. It will open an additional window on the right side of the Process canvas screen, where you have to enter the following details: Criteria Name: Enter a name for the criteria node. Enter Update Contacts in Criteria Name. Criteria for Executing Actions: Select the type of criteria you want to define. You can use either a formula or a filter to define the Process criteria or no criteria. In this case, select Active equals to Yes. This means the Process will fire only when the account is active. This window will appear as shown in the following screenshot: Once you are done with defining the Process criteria, click on the Save button. Once you are done with the Process criteria node, the next step is to add an immediate action to update the related contact's asst. phone field. For this, we will use the Update Records action available under Process. Click on Add Action available under IMMEDIATE ACTIONS. It will open an additional window on the right side of the Process canvas screen, where you have to enter the following details: Action Type: Select the type of action. In this case, select Update Records. Action Name: Enter a name for this action. Enter Update Assts Phone in Action Name. Object: Start typing and then select the [Account].Contacts object. Field: Map the Asst. Phone field with the [Account]. Phone field. To select the fields, you can use field picker. To enter the value, use the text entry field. It will appear as shown in the following screenshot: Once you are done, click on the Save button. Once you are done with the immediate action, the final step is to activate it. To activate a Process, click on the Activate button available on the button bar. From now on, if you try to update an active account, Process will automatically update the related contact's asst. phone with the value available in the account phone field. Summary In this article, we have learned the technique of auto updating records in Process Builder. Resources for Article: Further resources on this subject: Visualforce Development with Apex [Article] Configuration in Salesforce CRM [Article] Introducing Salesforce Chatter [Article]

0
0
7005

Packt

27 Apr 2015

18 min read

Custom Coding with Apex

Packt

27 Apr 2015

18 min read

0
0
6443

Packt

27 Apr 2015

19 min read

Resource Manager on CentOS 6

Packt

27 Apr 2015

19 min read

0
0
2390

How-To Tutorials - Programming

Filtering a sequence

Map/Reduce API

Creating a Spring Application

Practical Dart

Financial Derivative – Options

vROps – Introduction and Architecture

Learning Selenium Testing Tools with Python

Learning R for Geospatial Analysis

Ensuring Five-star Rating in the MarketPlace

Git Teaches – Great Tools Don't Make Great Craftsmen

Trending Topics

Getting started with Codeception

Welcome to the Spring Framework

Auto updating child records in Process Builder

Custom Coding with Apex

Resource Manager on CentOS 6