My series of posts on C# 6.0 has been on a long hiatus due to changes in the language feature set announced last year. Now with spring just around the corner in the northern hemisphere, Visual Studio 2015 reaching a 5th CTP status, and features hopefully stabilizing, it might be time to start up again.
As of C# version 5, there are many techniques you can use to avoid null reference exceptions (NREs). You can use brute force if else checks, the Null Object design pattern, or even extension methods, since extension method invocations will work on a null reference.
The conditional access operator, ?., adds one more option to the list for v6 of the language.
Imagine you are writing a method to log the execution of some code represented by an Action delegate. You aren’t sure if the caller will pass you a proper delegate, or if that delegate will have a method and a name.
The following code uses conditional access to retrieve the method name of an action, or “no name” if the code encounters a null value along the line.
public async Task LogOperation(Action operation)
{
var name = operation?.Method?.Name ?? "no name";
operation();
await _logWriter.WriteAsync(name + " executed");
// ... exception handling to come soon ...
}
By dotting into the operation parameter using ?., you’ll be able to avoid NREs. ?. will only dereference a pointer if the pointer is non null. Otherwise, the operator will yield a null value.
By combining ?. with the null coalescing operator ??, you can easily specify defaults and write code that must be read using uptalk!
Next up in the series: await and exceptions.
There isn’t much insight into the execution of a map reduce script in MongoDB, but I’ve found three techniques to help. Of course the preferred technique for map reduce is to use declarative aggregation operators, but there are some problems that naturally lend themselves to copious amounts of imperative code. That’s the kind of debugging i needed to do recently.
In a Mongo script you can use print and printjson to send strings and objects into standard output. During a map reduce these functions don’t produce output on stdout, unfortunately, but the output will appear in the log file if the verbosity is set high enough. Starting mongod with a –vvvv flag works for me.
Log file output can be useful in some situations, but in general, digging through a log file created in high verbosity mode is difficult.
The best way I’ve found to debug map reduce scripts running inside Mongo is to attach logging data directly to the output of the map and reduce functions.
To debug map functions, this means you’ll emit an object that might have an array attached, like the following.
{
"name": "Scott",
"total" : 15,
"events" : [
"Step A worked",
"Flag B is false",
"More debugging here"
]
}
Inside the map function you can push debugging strings and objects into the events array. Of course the reduce function will have to preserve this debugging information, possibly by aggregating the arrays. However, if you are debugging the map function I’d suggest simplifying the process by not reducing and simply letting emitted objects pass through to the output collection. Another technique to do this is to emit using a key of new ObjectId, so each emitted object is in its own bucket.
As an aside, my favorite tool for poking around in Mongo data is Robomongo (works on OSX and Windows). Robomongo is shell oriented, so you can use all the Mongo commands you already know and love.
Robomongo’s one shortcoming is in trying to edit system stored JavaScript. For that task I use MongoVue (Windows only, requires a license to unlock some features).
By far the best debugging experience is to move a map or reduce function, along with some data, into a browser. The browser has extremely capable debugging tools where you can step through code and inspect variables, but there are a few things you’ll need to do in preparation.
1. Define any globals that the map function needs. At a minimum, this would be an emit function, which might be as simple as the following.
var result = null;
window.emit = function(id, value) {
result = value;
};
2. Have a plan to manage ObjectId types on the client. With the C# driver I use the following ActionResult derived class to get raw documents to the browser with custom JSON settings to transform ObjectId fields into legal JSON.
public class BsonResult : ActionResult
{
private readonly BsonDocument _document;
public BsonResult(BsonDocument document)
{
_document = document;
}
public override void ExecuteResult(ControllerContext context)
{
var settings = new JsonWriterSettings();
settings.OutputMode = JsonOutputMode.Strict;
var response = context.HttpContext.Response;
response.ContentType = "application/json";
response.Write(_document.ToJson(settings));
}
}
Note that using JsonOutputMode.Strict will give you a string that a browser can parse using JSON.parse, but it will change fields of type ObjectId into full fledged objects ({ “$oid”: “5fac…ffff”}). This behavior will create a problem if the map script ever tries to compare ObjectId fields by value (object1.id === object2.id will always be false). If the ObjectId creates a problem, the best plan, I think, is to walk through the document using reflection in the browser and change the fields into simple strings with the value of the ID.
Hope that helps!
In a previous post on using the PageObject pattern with Protractor, Martin asked how much time is wasted writing tests, and who pays for the wasted time?
To answer that question I want to think about the costs and benefits of end to end testing. I believe the cost benefit for true end to end testing looks like the following.
There are two significant slopes in the graph. First is the “getting started” slope, which ramps up positively, but slowly. Yes, there are some technical challenges in e2e testing, like learning how to write and debug tests with a new tool or framework. But, what typically slows the benefit growth is organizational. Unlike unit tests, which a developer might write on her own, e2e tests requires coordination and planning across teams both technical and non-technical. You need to plan the provisioning and automation of test environments, and have people create databases with data representative of production data, but scrubbed of protected personal data. Business involvement is crucial, too, as you need to make sure the testing effort is testing the right acceptance criteria for stakeholders.
All of the coordination and work required for e2e testing on a real application is a bit of a hurdle and is sure to build resistance to the effort in many projects. However, the sweet spot at the top of the graph, where the benefit reaches a maximum, is a nice place to be. The tests give everyone confidence that the application is working correctly, and allows teams to create features and deploy at a faster pace. There is a positive return in the investment made in e2e tests. Sure, the test suite might take one hour to run, but it can run any time of the day or night, and every run might save 40 hours of human drudgery.
There is also the ugly side to e2e testing where the benefit starts to slope downward. Although the slope might not always be negative, I do believe the law of diminishing returns is always in play. e2e tests can be amazingly brittle and fail with the slightest change in the system or environment. The failures lead to frustration and it is easy for a test suite to become the villain that everyone despises. I’ve seen this scenario play out when the test strategy is driven with mindless metrics, like when there is a goal to reach 90% code coverage.
In short, every application needs testing before release, and automated e2e tests can speed the process. Making a good test suite that doesn't become a detriment to the project is difficult, unfortunately, due to the complex nature of both software and the human mind. I encourage everyone to write high value tests for the riskier pieces of the application so the tests can catch real errors and build confidence.
Imagine you are building an abstraction for a classroom, and one responsibility of a classroom object is to encapsulate the names of the students in the classroom. You might build a class like the following.
class Classroom {
constructor() {
this.students = ["Tim", "Joy", "Sue"];
}
}
On occasion, the outside world needs to know the names of the students inside the classroom. Perhaps the names will be shown on the screen, or saved in a database. In either case, how should a classroom object give the student names to a caller? One option is to return a reference to the students array, in which case the caller might change the array by adding or removing items. This option isn’t the best option if the classroom want to protect the array and validate the addition or removal of a student.
Another option is to make a copy of the array. Then, even if someone changes the copy, the original student array remains safe. However, copy operations can be expensive.
With ES6 and iterators we now have the ability to provide access to a collection without giving someone access to a mutable array. All we need is to make the classroom iterable by adding a Symbol.iterator method.
First, let’s make the classroom iterable by building our own iterator objects. This is the hard way to solve the problem.
class Classroom {
constructor() {
this.students = ["Tim", "Joy", "Sue"];
}
[Symbol.iterator]() {
var index = 0;
return {
next: () => {
if(index < this.students.length){
index += 1;
return {done: false, value: this.students[index-1]};
}
return { value: undefined, done: true };
}
}
}
}
The above code adds the iterator method to the class. Notice how Symbol.iterator needs square brackets to surround the method “name”. Inside the method is the code to return objects with a next method, which in turn returns objects with done and value properties. A classroom should now behave just like an array and allow developers to use for of loops.
let scienceClass = new Classroom();
let result = [];
for(let name of scienceClass) {
result.push(name);
}
expect(result).toEqual(["Tim", "Joy", "Sue"]);
One might notice that the code inside the classroom iterator method is the type of code that works with any array. Let’s extract the code into a new class.
class ArrayIterator {
constructor(array) {
this.array = array;
this.index = 0;
}
next() {
let result = { value: undefined, done: true};
if(this.index < this.array.length) {
result.value = this.array[this.index];
result.done = false;
this.index += 1;
}
return result;
}
}
Now we can reuse ArrayIterator from several places in an application.
class Classroom {
constructor() {
this.students = ["Tim", "Joy", "Sue"];
}
[Symbol.iterator]() {
return new ArrayIterator(this.students);
}
}
Even though the ArrayIterator class is helpful, we will see an even easier implementation of the iterator method when we get to generators.
In previous posts, we looked at classes in ES6, but I never gave an example using the static keyword.
A class may contain one or more methods defined with the keyword static.
class Employee {
constructor(name) {
this._name = name;
}
static convert(thing) {
if(thing.name) {
return new Employee(thing.name);
}
}
}
Like other languages with static class members, the static keyword will create a method associated with the class, and not with an instance of the class. In other words, you can only reach a static method using the name of the class.
expect(Employee.convert).toBeDefined(); expect(new Employee().convert).toBeUndefined();
Static methods have no access to the fields, properties, and methods defined on an instance of the class using this. For example, the convert method would not be able to use this._name to get to the _name field of an Employee object, as the this pointer inside of convert will never reference an Employee object. However, static methods are often useful and can play the roles of factory methods, conversion methods, or general class helper methods.
let person = { name: "Scott" };
let newHire = Employee.convert(person);
expect(newHire.name).toBe("Scott");
The behavior of static methods is explained by what happens behind the scenes. A static method of a class is associated with the constructor function and not the prototype object like the instance members we saw in the last section.
var Employee = function(name) {
// ...
};
Employee.convert = function(thing) {
// ...
};
In a previous post we looked at the for of loop in ES6, but left an open question. What magic allows for of to find an iterator? Alternatively, what makes an object iterable? To answer either question requires some knowledge of symbols.
A symbol is a new, primitive data type in ES6. There are two key points to understand about symbols.
To understand the implications of these two statements, and how they relate to iterable objects, let’s start by creating a new symbol. Creating a new symbol is as easy as invoking Symbol as a function.
let s = Symbol();
expect(typeof s).toBe("symbol");
Note that you do not use the new operator when creating a symbol, you only invoke the function. Otherwise, the runtime will raise an exception.
let makeSymbol = () => new Symbol(); expect(makeSymbol).toThrow();
What’s important to remember is that each symbol you create is unique and unalterable.
let s1 = Symbol(); let s2 = Symbol(); expect(s1).toEqual(s1); expect(s1).not.toEqual(s2);
When you create a symbol, you can add a description by passing a string to the Symbol function, but symbols created with the same description will be unique (even if the stringified versions look the same).
let s1 = Symbol("some description");
let s2 = Symbol("some description");
expect(s1).toEqual(s1);
expect(s1).not.toEqual(s2);
expect(s1.toString()).toBe("Symbol(some description)");
expect(s2.toString()).toBe("Symbol(some description)");
You can use symbols as keys into an object. In the following code we create one property using a string ("lastName"), and one with a symbol (the firstName symbol).
let firstName = Symbol();
let person = {
lastName: "Allen",
[firstName]: "Scott",
};
expect(person.lastName).toBe("Allen");
expect(person[firstName]).toBe("Scott");
Using symbols as keys is where symbols become interesting. Because symbols are unique, a symbol can create a unique property inside an object. You never have to worry about conflicting with existing methods, or being accidently overwritten. ES5 libraries would use timestamps or random numbers to achieve this same effect, but symbols are provided for this exact purpose.
Members of an object created using a symbol will not appear as part of the object when using a for in loop.
let firstName = Symbol();
let person = {
lastName: "Allen",
[firstName]: "Scott",
};
let names = [];
for(var p in person) {
names.push(p);
}
expect(names.length).toBe(1);
expect(names[0]).toBe("lastName");
Symbols also won’t appear when using Object.getOwnPropertyNames.
expect(Object.getOwnPropertyNames(person)).toEqual(["lastName"]);
Nor will they appear when serializing an object to JSON.
expect(JSON.stringify(person)).toBe('{"lastName":"Allen"}');
For these reasons, you might think symbols are useful for hiding information in an object. Although using symbols to hide information is useful, there is a new object method named getOwnPropertySymbols that will allow programmers to reflect into symbol properties that are otherwise hidden.
expect(Object.getOwnPropertySymbols(person)).toEqual([firstName]);
let symbol0 = Object.getOwnPropertySymbols(person)[0];
expect(person[symbol0]).toBe("Scott");
Back to the question at hand. How do symbols relate to iterators and iterable objects?
The JavaScript specification defines special methods to use in specific circumstances. The @@iterator method is one such example. If an object has an @@iterator method (which will return an iterator object), the object is iterable and will work as the source object in a for of loop.
How do we know if an object has an @@iterator method?
By checking to see if an object has a member at Symbol.iterator.
The iterator property attached to the Symbol function is what’s called a well-known symbol. The following code will check to see if strings, arrays, and numbers are iterable by looking for this well-known iterator method.
let site = "OdeToCode.com"; let values = [1,2,3,4]; let number = 45; expect(site[Symbol.iterator]).toBeDefined(); expect(values[Symbol.iterator]).toBeDefined(); expect(number[Symbol.iterator]).toBeUndefined();
The tests will show that strings and arrays are iterable, but numbers are not.
Now that we understand symbols, and the well-known iterator method, we can rewrite the following code.
let sum = 0;
let numbers = [1,2,3,4];
for(let n of numbers) {
sum += n;
}
expect(sum).toBe(10);
We will rewrite the code to represent what is really happening behind the scenes.
let sum = 0;
let numbers = [1,2,3,4];
let iterator = numbers[Symbol.iterator]();
let next = iterator.next();
while(!next.done) {
sum += next.value;
next = iterator.next();
}
expect(sum).toBe(10);
Using your knowledge of symbols to write low-level iterator code probably won’t be the most exciting application of ES6 symbols, but using symbols to make new iterable objects is exciting, and the topic for a future post.
In a previous post we looked at using iterators directly. Working with iterators at a low level will sometimes be useful, as we’ll see in future posts, but ES6 also provides a new looping syntax to work with iterators at a higher level – the for of loop.
let sum = 0;
let numbers = [1,2,3,4];
for(let n of numbers) {
sum += n;
}
expect(sum).toBe(10);
There are a couple observations to make about the above code.
First, the new for of loop looks much like the for in loop, which has always been around, but the two are subtly different. The for in loop works with the enumerable properties of any object, thus when working with an array, for in will iterate over the available indexes of the array, not the available values. To compute the same sum as the above code with for in, we’d need to index into the array with each iteration:
let sum = 0;
let numbers = [1,2,3,4];
for(let i in numbers) {
sum += numbers[i]; // notice the indexer
}
expect(sum).toBe(10);
The for of loop uses an iterator to visit the values in an array, not the available keys.
for(let n of numbers) {
sum += n;
}
This brings up the second subtle difference with for of, the for of loop exists not to work with just any type of object, but with iterable objects. Iterable objects are objects with a special method returning an iterator. We’ll look at the special method in a future post, but notice how the above code doesn’t need to use the values method of the array like the low level iterator code we wrote in the last post. The for of loop uses the numbers array directly.
There are many objects in the world of ES6 that will be iterable objects, and we will see more in future posts. For now, we’ve already seen how arrays are iterable. Strings are also iterable (you can iterate over the sequence of characters inside).
let result = "";
let message = "Hello";
for(let c of message) {
result += c;
}
expect(result).toBe("Hello");
How does does for of retrieve an iterator? And what makes an object iterable? To answer these questions we have to take a brief detour into another new feature of ES6 – the Symbol.
OdeToCode by K. Scott Allen
Subscribe
Twitter
Search
About
Learn C#