Review: Core Java for the Impatient

I’ve just finished reading Core Java for the Impatient by Cay S. Horstmann. I also own Scala for the Impatient by the same author, and I really loved that book. Having had previous experience with Scala, I was excited to read up on the newer features introduced in Java 8. Maybe it’s because I’m a C# developer professionally, but I’m really impressed with the new Java 8 features.

Horstmann’s books are excellently written for existing developers to quickly become familiar with newer languages and technologies. This book isn’t meant for a beginning programmer to dive right into software development using Java 8, but if you have C#, Java, Scala, or other C-style experience you’ll be set. The pace is excellent and the book flows really well.

While it’s expected that you’re already a proficient programmer, I didn’t get the feeling that it was expected for the reader to understand functional programming. Java 8 introduces a lot of functional style which I’ve seen existing Java developers complain about. I’ve also seen C# developers complain about Java verbosity. While I can’t help people who dislike functional programming, I can say as a C# developer that Java 8 really helps reduce the verbosity of the language.

Before Java 8 you’d have to construct a whole new class that implemented a single method if you wanted to create a Runnable (I have limited experience with pre-Java 8, so forgive me if that’s incorrect). In Java 8, you can assign a runnable to a lambda expression. The compiled code will still contain a one-off class but you as a developer don’t have to worry about those details. This kind of syntactic sugar really makes for more readable and more maintainable code. This is the first material I’ve read which covers Java 8, so I assume Horstmann has covered everything. I actually don’t think Java could have packed anything else into Java 8 that wasn’t covered in this book. It’s hard to believe so much great content was presented in less than 500 pages.

The book is written to appeal to the applications programmer, so Horstmann offers a lot of material such as functional concepts in the Collections and Streams chapters, annotations support, date/time improvements, and internationalization. He doesn’t walk you through creating a parser or an actor system like he does in Scala for the Impatient, but he does give you the necessary information to create a maintainable application in Java. The fact that you’ll learn how to create and process annotations as well as to perform runtime compilation of classes opens a world of possibilities (these sections obviously only touch the surface).

The book also covers Nashorn, a JavaScript REPL that provides access to Java types. I have node.js experience, so this really interests me. I’ll need to investigate the performance implications of running Java code from within this JavaScript environment, but this also opens a lot to an applications developer. For example, if you want to play around with a type in Java’s core library, you can fire up a REPL and instantiate the type rather than going through the rigamarole of creating a throw away project. As a C# developer, I use LinqPad regularly on Windows and Mono’s `csharp` interactive shell on OSX.

Again, I love how concisely the content is delivered. The code that accompanies the book is well structured, allowing the reader to quickly jump between text and the full implementations of the code in the book.

Another thing I enjoyed about this book is how information with short examples are presented in the chapter’s text and exercises are presented at chapter end to give a more hands-on experience. If you skip over the exercises, you’ll still get all of the important material of the chapter.

I would recommend this book to any non-beginner who wants to learn about Java 8.

Rating: ★★★★★ (5 stars)

Review “Learning 2D Game Development with Unity: A Hands-On Guide to Game Creation”

I’ve just finished reading Learning 2D Game Development with Unity: A Hands-On Guide to Game Creation, and I really enjoyed it despite many issues with the actual text (I’ll try to cover everything here). I’m just starting to learn Unity3D for 2D game development, so I’ve only watched a few of the official videos and followed a few tutorials online (the best so far being from pixelnest.io). After reading this book, I felt way more competent at creating my own game than with tutorials I’ve done elsewhere.

That’s not to say there aren’t some problems with the actual book contents. Quite a few people also have had problems with the book based on the Amazon reviews. I think the greatest comment, and a sentiment I share, is that the book could benefit from a technical edit. I’m a professional software developer, and I struggled to follow what was going on at one point.

This leads me to a major issue I had with the book, dropping a star from my review: Chapter 7 (Setting up Player Physics and Colliders) belongs before Chapter 5 (The Basics of Movement and Player Control). I don’t know how something like this could have been missed, but there’s no excuse for a ‘follow along’ book to be anything but sequential in its content. I’ve self-published a programming book, so I know getting things in the correct order while writing and editing is difficult. I also know that it’s unlikely for an editor or even a technical reviewer to catch this (you literally have to be ‘following along’ to encounter this problem). I toyed with giving the book 4 stars because I loved the content so much, then I thought about how well presented other books I’ve given 4 star reviews are and this book isn’t presented at the same level. If you take my advice and read Chapter 7 before Chapter 5, you’ll have almost no problem with this book. I went through the entire book in about two weeks using Unity 5.

This leads me to another problem which reduced my review by a ½ star: Chapter 14 is incomplete. Chapter 14 covers a then-beta feature of UGUI control layout and interaction. Unfortunately, there is only a single page between adding your first element (a Mask) to the canvas and the end of the book. Had the book just ended there, I would have thought, “OK, that was very high level,” and probably shrugged off the last chapter. The summary of Chapter 14 says “We gave a brief overview of building a simple Options menu with some text elements, buttons, and graphics” and almost none of this was even covered in the chapter (possibly because I’m reading the ebook?). Again, this seems like it would have been caught with a good technical or even a copy edit.

Another 1½ stars get deducted for what others have emphasized as a general feeling of being ‘all over the place’ with the instructions. There are a few times where numbered lists go from selecting a GameObject and doing nothing to modifying some other GameObject and selecting the first GameObject, which then gets modified. I actually found some humor in this, because it reminds me of peer programming with an extremely caffeinated coworker. I couldn’t ignore this in the review, though, because it happened more than once. For another example, the ‘Creating Components’ section of Chapter 2 explains the steps for creating components in what read like commands (but are statements) and the following section defines the actual steps. If someone was to follow the command-like steps (not in list form) of the one section, then the actual command steps (in list form) of the following section, this would become very confusing.

I experienced a general feeling of the book being ‘all over the place’ through Chapter 4. This was where I realized that the end-of-chapter ‘Exercises’ were actually continuations of the chapter content. I’ve literally never read a book where an ‘Exercises’ section wasn’t supplemental content to further your understanding of the material within the chapter. Rather than an ‘Exercises’ section, this book really should have just labeled the section appropriately. DON’T SKIP EXERCISES or you’ll be skipping part of the content.

I will say that other reviewers on Amazon have had unnecessary problems with downloading companion code. The code is very clearly linked on the book’s preface and from the InformIT product page. Even if you were to purchase the book from Amazon or somewhere else, I don’t know where else you’d look for companion content than in the preface.

Please don’t read my review as negative, I’m only trying to point out the issues I’ve found with the book. If you follow all of the exercises, read Chapter 7 before Chapter 5, and pay attention to what you’re reading (some of the examples in the book have incorrect code which have been fixed in the companion content’s project files for the chapter), you’ll really enjoy this book. I enjoyed making the example 2D platformer throughout the book. I didn’t hate or dislike the book, but I also don’t think beginners should have to piece together the contents of a book just to ‘follow along’. All of this stuff could easily be resolved with an updated (and well edited) copy of the book.

One of the things I really enjoyed about this book is how options are explained concisely in a single place. This made me feel way more familiar with the Unity editor and the options for game components. While watching some of the official videos on Unity’s site, I felt like the speaker was moving way too quickly for most people to follow along in the editor while explaining very little about what every option meant. Many tutorials I’ve seen online explain the steps to make a simple game (often lacking sound effects, particle effects, or even most of Physics2D). This book does an excellent job of explaining the basics of everything used to make a 2D platformer game. In fact, if it wasn’t for the editing issues I mentioned earlier, I would have given this book 4.5 or 5 stars. It’s meant for beginners, and I feel like non-programmers and programmers can all easily digest the material.

I made a list of many mistakes I found while reading this book. I’ll be emailing the authors the list, so hopefully the addenda will be updated. I’d love to see the book updated for Unity 5.

Ratings Summary

Overall: ★★★☆☆ (3 stars)

Editing: ★★★☆☆ (3 stars)
Not ‘poorly’ edited, but very close. A lot of the mistakes could have easily been caught by having any non-technical reader proofread the contents.
Presentation: ★★★☆☆ (3 stars)
I gave three stars for presentation because there are some code snippets in the book that just won’t work. I’m not talking about issues like Unity 5 doesn’t have this.rigidbody2D anymore, so you need to create a private variable and gain a reference in the Start or Awake function. I’m talking about things like the EnemyController’s Flip method flipping the instance and invoking flip on a colliding enemy instance, causing the two operations to cancel out. Then, there’s the issue of at least one image, Physics2D configuration, not matching the text in which the text says Player-Player is unchecked while the image shows Player-Enemy unchecked (using image settings makes your player invincible).
Material: ★★★★☆ (4 stars)
I enjoyed the material. Best of many tutorials I’ve followed. I give 4 stars because the book is very basic (it’s for beginners), yet doesn’t exactly introduce best practices. For example, the basic platformer developed in this game creates a single level in which 1×1 components are used for the scene’s map. There’s no mention of performant alternatives like using Tiled and Tiled2Unity to create a single mesh map. This *could* be because Tiled2Unity wasn’t out at the time of the writing, but I’d expect at least the acknowledgement of the performance limitations.
Enjoyment: ★★★★☆ (4 stars)
I thoroughly enjoyed the book. With my notes about following exercises and reading Chapter 7 before Chapter 5, I would recommend for beginners to read this book. One last caveat: if code in the book doesn’t seem to ‘work right’, try the code on the author’s companion site.

Links

Flattr this!

iTerm2 Toolbelt

I’ve been using iTerm2 for 2 or 3 years now, and I’ve only just now noticed the ‘toolbelt’ option in the window menu. You can also hit ⌘⇧B to bring up the toolbelt.

The toolbelt expands to the left of the terminal window and allows you to quickly and easily show all running jobs and send standard signals to the process. You can also switch between profiles (something I rarely ever do), access clipboard history and save textual notes.

Here’s a short video demonstrating the feature:

Flattr this!

Review: Swift for the Really Impatient

I’ve recently finished reading Swift for the Really Impatient. It was a really good book; I’d give it 4 out of 5 stars.

I had previously read Scala for the Impatient by Cay S. Horstmann. I’d like to note that, despite the similarity in title, Swift for the Really Impatient is not written by Cay S. Horstmann. I found the writing style to be noticeably different, but in neither a good nor a bad way. I just wanted to mention that Swift for the Really Impatient is written by Matt Henderson and Dave Wood, in case you’re a Horstmann devotee.

I’d like to make one thing clear for future readers. This book will not teach you to write your first functional OS X or iOS application; it assumes you’re an experienced Objective-C developer wanting to learn Swift’s syntax quickly. It differs in this way from Horstmann’s books, the style of which the authors have attempted to mimic. For example, after reading Scala for the Impatient the reader will be be able to write parsers, perform file and network functionality, as well as design and implement a minimal (yet powerful) distributed event bus using actors. Swift for the Really Impatient won’t teach you any of these types of things. Again, it’s related to Horstmann’s books only by similarity in title.

The book flows very well and very quickly. I read the entire book in my spare time, spanning only a few days. At only about 140 pages, compared to The Swift Programming Language book written by Apple (~600 pages), Swift for the Really Impatient is by far the easiest and quickest book to digest if you want to gain an understanding of Swift. If you’re familiar with Scala, you’ll breeze through this book.

One thing that kept throwing me off in the book was how it really feels targeted toward developers who were previously familiar with Objective-C. This isn’t a bad thing, considering you’ll need to at least understand Objective-C to really dig into OS X and iOS development using Swift. It’s also not a prerequisite for reading and understanding this book. The reason it threw me off is because the book doesn’t really ever explicitly define the target audience as having prior Objective-C knowledge, so sections explaining that “…the syntax of Swift should look familiar to Objective-C developers…” offer very little to developers without Objective-C backgrounds. It is fair to mention that the description on the Amazon product page for the book does clearly define the target audience as experienced Objective-C developers. If you pick this book up having had no prior experience on Apple’s platform, you’ll probably see some of the Objective-C code and think “what the…?!” Good news, though! You should be able to easily glance over the Objective-C parts and still fully understand the syntax of Swift.

I would actually take the authors’ references to Objective-C and expand them a little. Much of the Swift syntax would be familiar to someone with Java, C#, Groovy, or even JavaScript experience. The only places I think some developers may have a hard time are with the sections on Optionals and pattern matching. I felt like the authors excellently explained these concepts, but I’ve experienced first-hand in Scala how Java developers have struggled with these concepts. If you find yourself struggling one these sections, take your time and maybe reread the section (be less ‘Really Impatient’).

I loved how well the authors explained closures. If you have a JavaScript background, the section on closures will make a lot of sense. A book I previously read on Swift application development using Cocoa did a comparatively terrible job explaining closures, so it was refreshing to see the subject clearly and concisely presented in Swift for the Really Impatient.

The book definitely delivers the material you need to quickly understand the capabilities and syntax of Swift. The reason I’ve given it 4 stars instead of 5 is because it doesn’t explain how to execute Swift code. There’s no mention that XCode 6 is required to build and compile Swift. XCode is mentioned only on one page, less than 20 pages from the end of the book. The section mentioned XCode explains how to bridge Swift and Objective-C code which took me a couple of tries to figure out when I attempted this while following Apple’s official documentation. I’d imagine that a truly ‘Really Impatient’ developer would get frustrated with the short explanation of the process.

Swift for the Really Impatient should absolutely be the starting point for any developer hoping to code for Apple products. It is quick, concise, and (most importantly) accurate. I may even go so far as to suggest the book to any engineers who are interested in learning the syntax of different languages.

Flattr this!

Create configurable Angular services using providers

With Angular 2 on its way, it seems like a lot of developers are now afraid of Angular 1.x. I have nothing bad to say about Angular. Sure, some things could be made easier but that’s why Angular 2 is on its way. I’ve played with Angular 2 a bit, and it only works in Chrome. I’m fairly confident Angular 1.x will be around for quite a while.

In that light, let’s talk about creating configurable services. One reason why AngularJS is so popular is because you can easily create modular, reusable code. This code can encapsulate logic, directives, extensible services and factories (via decorators), as well as configurability. I’ll talk about creating directives and decorators in future articles.

This example will be a simple URL constructor for placekitten.com. Any AngularJS service can be written to be configurable (if there’s reason to configure the service, of course).

First of all, let’s see how this service will be used.

.controller('View1Ctrl', ['$scope', 'kittyService', function ($scope, kittyService) {
    $scope.kittycat = kittyService.getUrl();
}])
  <p>How about a kitty cat?</p>
  <p><img ng-src="{{kittycat}}"/></p>

Pretty simple. We’ll call kittyService.getUrl() and use the string returned from the service as the src for an image.

To create a configurable service, we’ll use an angular provider instead of a service or factory. The structure I use for a provider is this:

(function () {
    'use strict';
    var module = angular.module('myApp.services', []);

    module.provider('serviceName', function ServiceName() {
        // use `this` for configurable properties or functions

        this.$get = [function () {
            var service = {};
            // This can be any valid return that you'd normally use
            // with module.service or module.factory
            return service;
        }];
    });
})();

This structure is only a little different from a service or factory. Rather than return an object or constructor function, you use this.$get to create your reusable code. What you assign to this property is the array injector for your service definition. You’ll feel comfortable with this syntax if you define your services using the array-based dependency injection:

angular.module('myApp')
.service('serviceName', [function (){
            var service = {};
            // This can be any valid return that you'd normally use
            // with module.service or module.factory
            return service;
}]);

You can use instance properties and methods on the provider definition to configure your service, then use the private context of your provider to share the configuration with the service. Here’s the full code for the kittyService:

(function () {
    'use strict';
    var module = angular.module('myApp.services', []);

    module.provider('kittyService', function KittyServiceProvider() {
        var height = 100,
            width = 100;

        this.setHeight = function (h) {
            height = h;
        };
        this.setWidth = function (w) {
            width = w;
        };

        this.$get = [function () {
            var service = {};

            service.getUrl = function () {
                return 'http://placekitten.com/g/' + width + '/' + height;
            };

            // This can be any valid return that you'd normally use
            // with module.service or module.factory
            return service;
        }];
    });
})();

The provider has two private variables: height and width. The two methods on the provider object allow you to update these values, but only during the config phase. After your application’s config function has completed, your provider’s functions are no longer accessible.

One problem with this service is that placekitten.com shows the same image for a given combination of height and width. In the config phase of our application, the service’s height and width can be configured randomly:

.config(['kittyServiceProvider', function (kittyServiceProvider) {
    var widths = [200,300,400,500,600];
    var heights = [300,400,500,600,700];
    kittyServiceProvider.setHeight(heights[Math.floor(Math.random()*heights.length)]);
    kittyServiceProvider.setWidth(widths[Math.floor(Math.random()*widths.length)]);
}]);

The name injected into the config phase is kittyServiceProvider and not kittyService. This is important. AngularJS knows that when you request kittyServiceProvider in the config phase, you want the object containing your service definition (the KittyServiceProvider function in the example above). Once the config phase completes, the $injector service will prepare your service from the this.$get definition of your service.

If you load the example code, refresh the page a few times and you’ll receive a new kitty image.

NOTE: The heights and widths may not always combine in a way that retrieves an image. Just refresh for another example.

Why not do this in a service?

True, you could do this directly in the service if this was just your code. The benefit here is when you want to share a service with other developers, perhaps on a different project within your company or publicly on GitHub. What if your team wants a 200×300 kitty and HR wants a 500×500 kitty? In these situations you can’t just modify the code with your hard-coded values. True, in this example you could use constants or values instead but then your service would have a dependency on the consumer (this is bad).

A service that dumps a string for displaying a cat image is probably not that useful in the real world. Consider other possibilities. I’ve used providers for creating a reusable notification display which allows you to define whether a notification will automatically close and how long notifications will be displayed if they auto-close. Suppose your application often receives 40x errors when users leave their browsers unattended long enough for an authenticated session to time out; you could create a provider which caches failed requests and retries up to X (configurable) times before giving up. Or, you could create a configurable service which caches those failed requests, displays a login dialog, then automatically retries the failed requests X (configurable) milliseconds after logging in successfully. Those examples would require the use of an http interceptor, and would have been quite a bit more complex than a kitty image linker.

Code

Sample code for this blog post is available on github at jimschubert/blogs.

Further Reading

If you really want to dig into the guts of Providers (versus services, factories, constants, or values), check out Adrian Castillo’s blog post, AngularJS Providers under the hood.

For reference to each recipe, check out AngularJS Provider Recipes on the official docs.

Flattr this!

Review: Microsoft .NET – Architecting Applications for the Enterprise, 2nd Edition

I’ve recently finished reading Microsoft .NET – Architecting Applications for the Enterprise, 2nd Edition by Dino Esposito and Andrea Saltarello. This book caught my attention for two reasons. First, I really enjoy software architecture. Second, I’ve read lots of work by Dino and always found them enjoyable.

The book gives examples of a few architectural patterns like Domain Driven Design (DDD), Command Query Responsibility Segregation (CQRS), and Event Sourcing. It starts with a pretty heavy focus on DDD and seems to assume that you’ve read *The* Domain Driven Design book by Eric Evans. I’ve only skimmed through that book, but it was enough to get many of the references. This book does cover the high level definitions of DDD in a way that the reader can jump right in. The accompanying source code even provides the same example in DDD and CQRS (the two main architectures being discussed).

There were two major things I liked about this book. I really enjoyed how the book isn’t presented as ‘this is the best software architecture, so you should use it.’ Things are presented in a way that clearly states the authors’ position on each architecture. For example, DDD is discussed as a the typical go-to architecture for enterprise systems. It’s a proven pattern that ‘just works’ in many cases. The discussion of CQRS clearly identifies some weaknesses in DDD and supplies an alternative with the explicit caveat that a CQRS-based architecture will change how you think about data.

The other main point I liked about the book is how real-world the discussions are. I usually get that feeling from Microsoft Press books. Early on the authors say, “To design a system that solves a problem, you must fully understand the problem and its domain.” In one of my previous positions, one of the first things I asked when joining the team was, “How have you documented what we’re trying to build?” I received a weird non-answer from the team’s senior developer. I went to the team’s manager and asked the same thing so I could understand the requirements gathering and technical design analysis that went into the product. He said, “We don’t have any of that — we’re Agile.” I thought he was joking, but he wasn’t. Obviously it would strike a chord with me when the authors said, “Agile architecture is sometimes presented as an oxymoron, like saying that if you’re agile you don’t do any architecture analysis, you just start coding…” Elsewhere they described the businessman-developer disconnect that occurs when requirements are incomplete, which is exactly what happened on the previous team I mentioned. It’s like I always say, “If you don’t know where you’re going, how will you get there?”

Another aspect of the book that I think can get buried in reading is the point about developing for a task-based user experience. Too often do developers start coding at the database and work their ways up to the user interface. Without a clean architecture, this can lead to situations where a column in your relational database has to change all the way to the UI. That’s silly. With a good architecture that clearly identifies boundaries in code, you inherently create more reusable and more maintainable code. I think this should be everyone’s main goal while writing code.

I also thought it was cool how the book and accompanying example code demonstrate using a NoSQL database (RavenDB) for an event sourcing application. While I don’t know where I’d ever use Event Sourcing over a more common architecture (mainly because I have to account for the expertise of other developers), I really like the Event Sourcing pattern. Now that Akka.NET is gaining traction, I wonder if Event Sourcing will become the way of the future.

One minor issue I had with the companion content was that it didn’t run as-is. There was a problem with the NuGet packages and MVC5 for which I found a solution at https://naa4e.codeplex.com/workitem/1.

I would definitely recommend this book for senior developers and engineers. It provides concrete examples and guidance from experienced architects toward more solid enterprise application design.

You can download the companion code for the book at https://naa4e.codeplex.com/

Flattr this!

Tips for debugging a WiX MSI

WiX is an excellent technology that simplifies the creation of MSI files using an XML abstraction on top of the Windows Installer APIs. WiX doesn’t change the underlying MSI architecture and it can be a huge pain in the ass sometimes. I thought I would share some tips for debugging what’s going on with an MSI. These tips aren’t specific to WiX, that’s just the technology I’m familiar with.

Logging

The first thing you should try is to add the log switch when you run your installer. To do this, open a command prompt in the directory where your MSI file is located and run it with the following parameters:

msiexec yourinstaller.msi /L*v install.log

The /L*v says to log verbose messages to a file.

For a full list of msiexec switches, check out MSDN’s documentation for msiexec.

Re-cache MSI

If you think your package was somehow corrupted or you’ve made a simple such as changing a file’s guid or a feature condition, you can re-cache the package with the following command:

msiexec /fv yourinstaller.msi

This is generally used when you install a product and then thing “oops, I forgot something…”. You don’t want to create a whole new release, so you can update the installed/cached MSI.

Be careful to read the documentation. With the /f parameter, you can’t pass properties on the command line.

Increased Debug Messages

You can actually increase the amount of messages exposed to MSI logs by setting a machine policy for Windows Installer.

Open regedit and go to HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer (you may need to create this key). Add a DWORD key called Debug with a value of 7.

The value of 7 will write all common debugging messages to the log as well as command line information. If you’re passing sensitive data to the installer on the command line, be warned that this information gets dumped via the OutputDebugString function. This means that anyone with physical access to the machine or access to the machine via TCP/IP may be able to read these messages. The documentation for the policy settings warns that this setting is for debugging purposes only and may not exist in future versions of Windows Installer.

For a full list of available settings, check out Microsoft’s Windows Installer Machine Policies.

System Debugging

Passing the logging switch and log file name to an MSI every time you run an MSI can be annoying. You can set the Logging machine policy to have Windows Installer write a log to a temp file, but then you have to track down the temp file.

Instead, you can run Sysinternals’ DebugView. This utility allows you to catch debugging information exposed by the Win32 OutputDebugString function on local and remote machines. This doesn’t just gather information from MSIs. For example, you can open a TFS query editor in Visual Studio 2013 and inspect the queries made via TFS.

Orca

Lastly, the Windows SDK contains a file called Orca.msi. Orca is a tool to inspect the contents of an MSI. An MSI is essentially just a database of tables and fields with values. You can open an existing MSI, edit a condition, and save it. This can make investigation a little easier. For instance, if you’re trying to figure out why a condition on a custom action doesn’t seem to be passing, you can edit the MSI and modify the condition instead of rebuilding the MSI. It’s also helpful if you’re trying to figure out how another MSI implements some logic.

I’m sure there are plenty of other techniques for debugging MSI files.

Flattr this!

Your IDE’s font matters: Fantasque Sans Mono

A good development environment is crucial to your productivity, there’s no question about it. The phrase ‘good development environment’ is subjective. For example, I’m pretty efficient using WebStorm and VisualStudio. I use vim pretty often but I’m nowhere near ‘efficient’. Matias Niemelä, on the other hand can easily manipulate text in vim.

A year or two ago, I read a blog post somewhere that suggested a font is just as important as your tool of choice. I thought, “yeah, right!”, but downloaded the font anyway. After a day of using the font, I realized how much more quickly I could read through code and how much easier it was to visually identify code blocks. I know that sentence sounds trivial, but after two years of using what I consider a better font I definitely notice a difference when I’m not using the font.

My font of choice these days is called Fantasque Sans Mono.

Here’s a screenshot comparison of Arial and Fantasque Sans Mono, both at 14pt.

Atom: arial 14pt
Atom: arial 14pt
Atom: fantasque sans mono 14pt
Atom: fantasque sans mono 14pt

The first thing to notice is how uncluttered letters are in Fantasque. On line 17, the word ‘function’ feels like it runs together in Arial but the letters clearly stand out in Fantasque. Also notice how the letter ‘g’ is unmistakable on line 18. On line 21, the kerning between parentheses, braces, brackets, and vertical pipes all make the line of code slightly easier to read. On line 23, the zero in Arial and many other fonts often resembles the capital letter ‘O’. For literals, this is obviously a number but it can be an easy typo to overlook within a string. In Fantasque, a zero has a line through it to clearly differentiate the number from the letter. Line 25 is easily consumed in the Arial screenshot mostly because the Atom editor clearly distinguishes between patterns and operations in the regex literal. Take a look at the difference without JavaScript syntax highlighting:

Atom: arial 14pt plain text
Atom: arial 14pt plain text
Atom: fantasque sans mono 14pt
Atom: fantasque sans mono 14pt

The actual code tends to be wider than other fonts. In the Arial screenshot, the image stops at the 80 character vertical indicator, which can easily be seen in the Fantasque screenshot. I actually like to use a 12pt or 13pt font size with Fantasque, which gives me a little more code on screen.

Although these points may seem trivial, I challenge you to at least give a few different fonts a try. You’ll be as surprised as I was to find that subtle differences in your font can improve productivity.

Download Fantasque Sans Mono from OpenFontLibrary.

Flattr this!

Review: From Mathematics to Generic Programming

 

(This is a repost of my Amazon review) I’ve been out of college for a while. I did well in math classes in high school and college, but I’ve been recently feeling rusty. I wanted to read this book to combine something I love (generic programming) with something I feel is missing in my daily life (mathematics). I wasn’t at all disappointed.

The book covers a lot of interesting historical stories of advancements, discoveries, and progressions in mathematics. It starts with the cravings of the Greeks to learn and how the study of the world around them incorporated arithmetic, geometry, astrology and other teachings. The book presents many different abstractions via axioms, theories, and proofs. These are then seamlessly related to generic programming.

Although the programming pieces of the book don’t stress this enough, the examples are a guidance toward functional programming concepts. Stepanov covers monoids, groups, semigroups, rings, etc. I was surprised by the amount of ground covered in this book. He even discusses how mathematics can be applied to social networks to do something like find friends of friends of friends (graphs).

The code examples in the book are written in C++. This may be intimidating for some developers. Don’t worry, the code isn’t overly advanced. If you’ve worked with another language that has generics, traits, mixins, or macros, you should be fine. These are the level of abstractions you’ll encounter in this book. There’s an appendix to introduce the C++ concepts, if needed.

There are plenty of exercises in the book. These are actually the only the only negative thing I have to say about the book. There are no solutions, no hints, and no companion code for the book’s exercises. Maybe when the book has been around for a while, you may be able to find a github repo where someone has worked through the tasks. I was sad to see nothing like this existed.

I would highly recommend this book to anyone with an interest in mathematics and an interest in generic programming. I felt like the book was a little heavier on mathematics than generic programming. However, I also feel like most developers I’ve met don’t feel comfortable with the application of mathematics concepts.

Flattr this!

Developer James Schubert shares his code and his thoughts.