Forem: Stéphane Bisinger

Making a team more effective - by having fun!

Stéphane Bisinger — Sat, 09 Nov 2019 21:41:12 +0000

During the last year I've been involved with the reengineering effort at Homegate. These 15 months have been very intense, full of ups and downs, hard work and awesome colleagues.

I still remember the first days: the team I had in front of me was having a hard time trusting each other and people seemed not very close to each other. While there were some hints of best practices, there was a need for a lead to set the direction and ignite the engine of self-improvement. That's where I decided to make an impact.

A year later here I am collecting advice on how to make your teams more effective and how to introduce new ideas successfully. Transforming teams into the better version of themselves, make people grow professionally and personally is such an inspiring job!

And although I have decided to move on to new challenges outside of Homegate, I want to continue working on improving teams in the future.

Growing the full potential of a team

I came to Homegate after the shutdown of siroop, where I learned that yes, it is possible to apply great engineering practices and build very strong platforms through that. And that it's incredibly fun!

But how could I bring those experiences over to Homegate and get a very different organization to reap the same benefits that I observed before?

Here are some tips that come from my direct experience with this problem.

Listen to the team

The people in the team are the first to know what the pain points are. They might even know the solution to the problem, but not how to push it forward. Or they might need ideas on how to tackle it. Either way, this is the best place to start because you already have buy-in from the team. And once they see the results, they'll trust in your other ideas a little more, even if they look completely crazy.

Create the mechanisms for change in the team

The team itself needs to be in control of their change process. This means that if they're not already in place, it's up to you to try and introduce mechanisms where the team can discuss issues and agree on solutions together.

At Homegate there was already a good retrospective in place, which became the best place to point out things that could be done differently to achieve better results.

Work with the people

Change is never introduced successfully through force. Any practice that is mandated from above will be resisted, no matter how good it is. If you want to bring lasting change, you need to get the people on board. You can give some inputs to push them a little bit out of their comfort zone, ultimately the team has to want to do the experiment and see.

People on the team are your most important asset and you must never lose sight of that: ultimately efficiency of processes doesn't matter if the people are unhappy.

Take little steps

If you are fortunate enough that the team gives you credit it is your responsibility not to abuse it. Stepping out of the comfort zone is necessary to grow and learn, but you can't go too far out. Identify the area you want to improve, challenge some limits in a small but meaningful way, give it time to sink in, rinse and repeat.

Each team and company is unique

It doesn't matter how well something worked in a different team at a different company: you have to adapt everything to your current situation. What worked previously might not work here. To quote Kent Beck:

I can't teach you to be more like Facebook, I can teach you to be like YOU at your best.

For example pair programming worked great at siroop. It also worked at Homegate, although we used it in a different way. What if you find yourself in a remote company with team members distributed acroos time zones? It probably won't work as good: while it is feasible, it loses some of the advantages of pairing and a lot of the advantages of remote work. In that context, you might want to try something else to reach the same goals.

Tackle the big problems first

It's a good idea to spend a little time to identify what are the biggest factors that hold the team back, and then start working on those. Much like performance work in computer programs, the biggest opportunities are behind the biggest problems, and they usually require a limited amount of effort to already improve the situation.

For example when I started I noticed that work tended to stay for weeks on a branch before being merged. So I start to show how you could slice work into smaller chunks, point out opportunities to split the pull requests and generally transmit the benefits of having small, readable pull requests.

After some time the changes started to become smaller and faster to be merged, which dramatically reduced the amount of big merges that caused so many problems and slowdowns. And people were happier about that too!

Keep the bus factor high

When introducing new ideas to the team you might have to lead by example and be the first to do it. This is not enough. Once you have solved a problem, you not only have to show the team the how and why, but you have to ensure they are able to do it too.

Be patient

Changing people's habits takes time. I spent 6 months before we reached Continuous Delivery without any manual step. It took close to a year to get people to try not having code reviews when code was developed by a pair.

Be patient, give everyone the appropriate time to get used to new concepts, and keep doing small steps whenever the time is ripe. Slow but steady always wins.

How do high performing teams look like?

One year later, how can we tell if the efforts paid off?

There are many metrics that one could look at, but all of them are imperfect. So instead of trying to find the perfect measures, I'll point out the aspects that make me particularly proud to be part of the team and to have helped to get there.

Everybody understands most of the project Even though there are varying levels of expertise among the people which tends to naturally make more experienced people as the knowledge holders, most of the team understands the pieces that make up the project, what tools or processes we have in place and why.
Deployments are non-events We deploy multiple times a day straight to production and we never have to worry about introducing big errors. Our testing strategy, our delivery pipeline and our monitoring systems are realiable and have saved us from trouble numerous times before. Therefore the team trusts its system and will proactively work to improve it in case something unexpected passes the checks.
Decisions are a shared responsibility by the team The team decides its own fate and takes care of all the decisions that are needed. This also means that everybody is aware of the ongoing discussion points and what might come next. Nobody needs to "shield" the team from external pressure because the team is mature enough to handle it.
The infrastructure supports other teams too The infrastructure built by the team allows other teams to get started quicker and build on top of what was done. The benefits go beyond the single team, but spread into the whole organization.
The reported bugs are minor Most of the reported bugs are either missing features, edge cases or minor problems. The number of critical problems that require immediate intervention are stuck at _ zero _.
No overtime required - ever! Our system is designed so that errors are unlikely and recovery is quick and painless. This means that nobody has to do overtime to solve an unexpected bug in production, because the easiest fix is to revert and have a look at it the following day.
People are better at what they do The growth in the single people is definitely noticeable. Not just on the technical side, but also in the way of collaboration with others.

This is a team I am proud to be a member of.

Additional Reading

If you found this article interesting you might want to check out the following resources:

Breaking the "Senior engineer" ceiling by Yan Cui
Accelerate: Building and Scaling High Performing Technology Organizations by Nicole Forsgren, PhD, Jez Humble and Gene Kim
Deploys: It's not actually about Fridays by Charity Majors

What Is MapReduce?

Stéphane Bisinger — Thu, 28 Jun 2018 09:02:03 +0000

Originally posted on my blog

In this era of Big Data and the rise of a new species called Data Scientist, us "mere" Software Developers might have heard of a thing called MapReduce, but what is it really? And why has it been a game-changing tool in the last decade? This is my attempt to explain the concept in simple terms.

To illustrate the concepts I will use Python, one of the most popular languages especially when it comes to data science, and LISP (in particular Clojure) to honor the language that introduced the concepts used for MapReduce.

So what is MapReduce? It is an approach to solve some problems that allow us to process huge amounts of data in a very simple way. It was described in a Google whitepaper in 2004, and it has been the basis for tools like Apache Hadoop, among others.

The old reliable way

But let's not lose ourselves with abstract descriptions and let us start from the very beginning - with a simple loop:

def powers(numbers):
  results = []
  for number in numbers:
    results.append(number * number)
  return results

Ok that's not very idiomatic, is it? Here is a better version:

def powers(numbers):
  return [number * number for number in numbers]

I'm sure everyone who can write the above code understands what is going on here: we have an array of some sorts and we cycle through the elements. For each of those elements we calculate the power of 2 and place that result in a new array.

It is not hard to see how this will work at a lower level, in the machine itself: the array is an area of memory, we start by pointing at the beginning this memory area, read the first value into the CPU register, multiply it by itself and store that value in another memory area that corresponds to the new array. Then proceed to the next element until the end of the array.

Since we are telling exactly what the computer should do, we call this way of writing programs imperative programming.

The other old reliable way

How would the same thing be written in LISP? It's not that complicated:

(defn powers [numbers] (map (fn [number] (* number number)) numbers))

Whoa! What's up with all the parentheses? Okay, let's break it down in easy-to-digest pieces, shall we?

(defn powers [numbers] ...)

Here we define a function named powers that takes an argument, numbers.

(fn [number] ...)

This creates an anonymous function that takes an argument number. In python you would accomplish the same with lambda number: ....

(* number number)

This looks a bit weird at first, but it just means that we multiply number by itself!

Now for the juicy part:

(map (fn [number] (* number number)) numbers)

Meet our new friend map! What this function does is simple: return a list of values that are the result of the function passed in as the first argument applied to every item of the list passed in as the second argument.

Or to put it differently, map will loop through every value in numbers, apply our function to each value, and return the result of this function in a new list. It is the equivalent of our for loop!

But let's reflect for a second on what happens at a lower level: from the code we see we actually can't know how this will play out! Will we walk through the memory in the same order as with the for loop? Or in reverse order? Or with some random order? We can't be sure because the detail of how to produce the result is not in our hands, but it is taken care by the implementation of our programming language.

This is what is called functional programming, which is a form of declarative programming: we state what we want, not how to produce our result. But why is this important? Is it just a matter of style and personal taste?

Thinking Big Data

Our example is small enough that the way we loop through the data doesn't matter. But what if instead we had a very big list of numbers, greater than what can be held in memory? What if instead of multiplying we had to perform a more CPU-intensive function? How would this play out?

This is a scenario where you might want to introduce some form of parallelism, to use all of your CPU cores. How would that look with our Python example?¹

# To use Threads, we would use ThreadPoolExecutor
with concurrent.futures.ProcessPoolExecutor(max_workers=NUM_WORKERS) as executor:
  futures = [executor.submit(expensive_function, number) for number in numbers]
  concurrent.futures.wait(futures)
  results = [future.result() for future in futures]

The complexity went definitely up! And this is taking advantage of the concurrent.futures module, which simplifies already a lot of details.²

What about LISP?

Here it is:

(pmap expensive-function numbers)

The only relevant change is that we use pmap instead of map, and the only reason we have to change function at all is because it might not always be desirable to run the function in separate threads. That's not just a matter of programming styles or syntactic sugar, this is actually a very big deal!

Now let's extend the reasoning even further: what if we have so much data to process, maybe from a file of a few gigabytes or even terabytes, and we can't possibly process all of that on one computer. We have to distribute the load over hundreds or thousands of servers! How can we do that?

Distributing work

How could we split our work across various servers, instead of having it in separate threads or processes? This is where it starts to get hairy. We have to manage somehow our cluster of servers, ensure they are reachable, distribute the work, handle failures and retries, and ideally also scale them automatically. Seems complicated? Well it is, and since we are talking about a distributed system there are many ways things can fail and countless pitfalls to avoid. Distributed systems are hard to implement correctly.

So how would our code look like in Python? Honestly, I don't even want to start with it. It would be an immense effort to accomplish this and it would certainly not fit in this blog post. A possible idea could be to use Celery to enqueue the slices of computations and use that to distribute the load across different hosts.

How would it look in LISP? Theoretically, it doesn't need to change: we could have a dmap function that distributes work across multiple nodes. In practice it is a bit more complicated than that just because we would need to setup our cluster and control its behaviour.

I don't want to leave you without an example, though, so here is one written in Python, using a library called
Scoop:

from scoop import futures

list(futures.map(expensive_function, numbers))

Can you tell from the code that this might actually run on multiple machines?

But what about reduce?

We talked at length about the map operation, but we haven't mentioned the reduce yet. What is it about?

I'm sure you encountered this operation quite a few times before, just look at this imperative approach to implement the operation:

def sum_nums(numbers):
    count = 0
    for number in numbers:
        count += number
    return count

You've done this or a variation of this a hundred times, I'm sure. It is often useful to turn an array into an hash map of some sort, for example this:

def group_by_id(customers):
    customers_map = {}
    for customer in customers:
        customers_map[customer.id] = customer
    return customers_map

How would this look in the functional world? Here it is:

(defn sum_nums [numbers]
  (reduce + 0 numbers))

Again the details are hidden and we only provide a combining operation (the + in our case), an initial value (0 which could be omitted in this particular case) and the collection.

What will happen is that it will take an element from the collection combine it with our accumulator (that is the initial 0), use this combination as the new accumulator and proceed with the next element in our collection.

If we combine it with the map operation we can do some pretty powerful stuff:

(defn sum_squares [numbers]
  (reduce + (map * numbers)))

The imperative equivalent is this:

def sum_squares(numbers):
    final_sum = 0
    for number in numbers:
        final_sum += number * number
    return final_sum

MapReduce at last

Now that we clarified the building blocks and the concepts behind them, it is easy to understand what MapReduce is all about. Let's take the example straight from Google's Whitepaper, which will count the occurrences of the words in a text:

    map(String key, String value):
      // key: document name
      // value: document contents
      for each word w in value:
        EmitIntermediate(w, "1");

    reduce(String key, Iterator values):
      // key: a word
      // values: a list of counts
      int result = 0;
      for each v in values:
        result += ParseInt(v);
      Emit(AsString(result));

We first define a map operation, that for each document it receives, it will split it into words and for each word emit a key/value pair, where the key is the word itself an the value is 1 .

The reduce function will then receive the key and the list of values that correspond to that key. In our case for each word we would receive a list of ones, one for each repetition of the word.

We then take all of those ones and we sum them together. This is then the value that we emit.

All of this actually happens in a distributed manner, but the code doesn't really need to know. How cool is that?

Is this the end?

Is that all there is to it? Mostly, yes. Of course there is much more to know, but the basic idea is that simple. From this idea other cool things were built, to the point that No one at Google uses MapReduce anymore!

I hope that this will allow you to understand better what the concepts are behind MapReduce and to have a general feeling about what it allows you to do. Between this and actually using it there are many more steps to make, but maybe now it looks less intimidating.

Was this helpful? Let me know in the comments!

Due to the Global Interpreter Lock, we are actually spawning multiple processes here. Python threads are useless for CPU-intensive operations. ↩
With the executors you can use executor.map, which is a approach to the problem. This highlights how powerful this really is. ↩

Time for Growth

Stéphane Bisinger — Mon, 28 May 2018 15:02:19 +0000

In my last post I listed the technologies I'm curious about, but I also listed some of the technologies I'm not so enthusiastic about. That triggered some reactions and someone pointed out to me that my knowledge about C# and Java is outdated.

This has been the beginning of a soul-searching process on my part.

A problem of arrogance?

Rather than seeking to find out more through questions and learning (actions viewed by them as showing vulnerability), arrogant people tend to generalize from their limited, narrow life experiences and try to impose their small worldview on others.
— How to Detect Arrogant People

I stumbled upon the previous quote and, while I find it a little harsh, it doesn't paint a pretty picture. Am I confining myself to the small enclosure of my own comfort zone, forgetting to question it from time to time?

Since I've always made it a point to keep my open mindedness as wide as possible, I decided to do something about it in order to improve. The time has come to let go of some stiff ideas that get in the way, challenge my beliefs and grow up as a person.

Conquering the mountain of my ego

A journey of a thousand miles begins with a single step, says ancient Chinese lore, so I started to take some baby steps in that direction. I found some very inspiring insights in the videos by Jayme Edwards, who shares what he has learned over the years as a software developer in order to lead more healthy professional lives.

His approach really inspired me and made me realize that it's more important to me to be helpful on a project or organization rather than being an ass about technological choices: while I have my preferences and ideas, I can't let these things get in the way of making a positive impact.

I also decided that an update in popular technologies outside my usual picks is overdue, so I went ahead and invested some time there.

New discoveries

The first thing I wanted to find out was how it would look like if I wanted to
start a project in .NET, for example a simple API. I didn't want to install .NET Core on my machine, so I opted for docker images. I created a small F# project and I was surprised! There are relatively few obstacles to get started and while it still requires some configuration files, the available documentation is excellent and all the basics are already covered. Kudos!

Next I decided to find out what has been happening in the Java world since 2012. And to my great surprise the introduction of lambda expressions is a bigger deal that I thought! Coupled with the new Stream API, the power of Java has been greatly extended.

For example, to loop through an array we can turn this:

List<Integer> numbers = Arrays.<Integer>asList(1, 2, 3, 4);
for(int number : numbers) {
  System.out.println(number);
}

into this:

List<Integer> numbers = Arrays.<Integer>asList(1, 2, 3, 4);
numbers.stream()
  .forEach((number) -> System.out.println(number));

While there are still a lot of limitations due to the way object orientation was implemented in the language, this is already a great improvement!

Conclusions

I am glad to make this effort to widen my horizons. I might never be an actual fan of some technologies, but I decided to stop treating this as a deal-breaker. Instead I'll give more importance to the people involved in a project and the potential positive impact that I can have.

Truth is, horrible code can come from any language, but it is also true that with (almost) any language you can build awesome stuff. And regardless, at the end of the day I am going to work with people, not programming languages, and if the people are cool and I can be of help, what more could I wish for?

My Tech Wishlist

Stéphane Bisinger — Mon, 16 Apr 2018 19:55:56 +0000

Due to some big changes involving the company I'm currently working at, I will soon move on to a new challenge.

But what are the challenges I'd like to work on in the next months?
Here is my list with things that excite me and things that don't.

Job Utopia?

Finding a job that would match all the following criteria is impossible. As
with any wishlist, this is just a listing of what currently interests me: some
things are negotiable, some are not. The objective is to collect my thoughts in
one place, so that I have a reference to compare potential job offers with. It
can also help potential employers understand more what kind of person I am.

Company values

One of the most important points for me when looking for a new job is to verify the company values.

Must haves

A clear purpose: I recently read Start with Why from Simon Sinek and it struck me for its simplicity. A company should be able to answer to a very simple question: Why should it exist?
A positive impact: Choose a job you love, and you will never have to work a day in your life. If what you do improves people's lives, I'd love to hear from you.
Good working conditions: This means european levels of social benefits and working conditions that help taking care of a family. A successful company should know better ways to track productivity than using a clock. Quality over quantity!
Influence: I am enthusiastic and opinionated; I love challenges and I want my work to be impactful. I want the company I work for to be successful, but to do that I must be able to influence it.

Architecture

After 15 years spent in web development, I long for bigger challenges. Making an application perform and scaling it to handle big volumes of traffic is not an easy feat!

Kubernetes: Containerization has changed the way we deploy our software, but other things haven't changed: vendor lock-ins versus free software. Platforms like AWS are amazing, but I always ask myself if it's wise to be locked to a specific platform. Kubernetes allows you to choose from a wide array of hosting options, and you still have the door open to migrate somewhere else if you ever need to.
Data streaming: I've worked with DynamoDB and Lambdas to process data in streams, but I found the artificial limitations really bothersome. I want to go a step forward and explore other options like Apache Kafka, Apache Flink or others.

Programming languages

Over my career I've worked with a plethora of different programming languages and while all can accomplish great things I obviously have my preferences. There are interesting newcomers on the scene and I'd love to try out some of them!

Would love to use

Elixir/Erlang, Elm, Clojure, Haskell, Scala: Functional programming is very hot right now and I find very interesting how some of the concepts helped to solve modern problems (I'm looking at you, state management!). I'd love to work professionally with one of those, also to explore their shortcomings and become a better programmer in the process.
Rust, Go: Those are relatively new kids on the block! Using modern programming languages to write (relatively) low-level programs must be fun, right?
Python, Ruby: The old reliables. Yes, I've worked with them already, and yes, they still excite me! I know their limitations, but I also know how to overcome them when necessary.

Not so eager

Java: I find Java extremely boring. I think Java might be the main reason I'm not a fan of statically typed languages! I mean to this day you need XML (yuck!) and an IDE to generate code for you if you want to keep your sanity. Its love for abstractions really clashes with my minimalist approach.
C#: Although I've never been a fan of Microsoft, I must admit that in the last years they changed their approach completely. Nonetheless, C# is still very close to Java and I'm not sold on developing on Windows. The vendor lock-in concern is still present with the .NET platform. Maybe I could be swayed with F#, if the project is really interesting.
PHP: I've started my career with ASP and PHP, I've worked numerous times with PHP and... I can't take it anymore! It just doesn't excite me at all, it is bothersome for me to write (why -> instead of .??) and I think the type hinting is actually making the language worse! If I see PHP on a job ad it is very likely to be a deal breaker for me.

Final thoughts

Quite a list, isn't it? If you are a fellow developer, what is your list of dream requisites for a new job? Let me know in the comments!

Are you on the lookout for developers? Do you think I would be a good match for your team, either remotely or in Zurich? Then get in touch!

Hi, I'm Stéphane Bisinger

Stéphane Bisinger — Sun, 11 Jun 2017 10:15:58 +0000

I have been coding for around 17 years.

You can find me on GitHub as Kjir

I live in the beautiful city of Zürich, Switzerland.

I work for Renuo, a small Ruby-based Web Agency.

I mostly program in Ruby and Javascript.

I am currently learning more about Elixir and Functional Programming, also applied to React and Javascript.

Nice to meet you.

A modular Gruntfile

Stéphane Bisinger — Sun, 14 Feb 2016 21:02:00 +0000

Grunt is a very powerful task runner and if you are developing in Javascript chances are you are probably using it. It’s configuration file defines all the tasks available and what they should do, but have you ever felt that even for mid-sized projects it easily becomes too big and hard to manage?

Well I felt that way, so that’s when I decided to split it into many smaller configuration files with the help of load-grunt-config. By following the excellent advice given by Paul Bakaus on his article on html5rocks, I came up with a cleaner and much more manageable setup.

Here I’ll try to build upon his article to add some more details about useful tricks I used in my setup.

The brevity of YAML

Being at heart a Python developer, I love terse syntax. Why bother with unnecessary brackets, commas or quotes which clutter your files making them harder to read for the human eye? Hence a move from a Javascript syntax to a YAML syntax for a configuration file is a big relief for me!

load-grunt-config supports many different kinds of syntax files, which can be mixed, allowing me to greatly reduce the noise in my configuration. If I initially had a Gruntfile like this:

module.exports = function (grunt) {
  var pkg = grunt.file.readJSON('package.json');

  grunt.initConfig({
    ngconstant: {
      options: {
        name: 'config',
        dest: 'app/config/config.js',
        constants: {
          ENV: {
            apiLocation: '',
            appName: 'MyApp',
            appVersion: pkg.version
          }
        }
      },
      development: {
        constants: {
          ENV: {
            apiLocation: 'http://localhost:3000/api'
          }
        }
      },
      staging: {
        constants: {
          ENV: {
            apiLocation: 'https://staging.example.com/api'
          }
        }
      },
      production: {
        constants: {
          ENV: {
            apiLocation: 'https://api.example.com'
          }
        }
      }
    }
  });
}

I would now have this as a Gruntfile:

module.exports = function (grunt) {
  require('load-grunt-config')(grunt);
};

And I would create a YAML configuration file in grunt/ngconstant.yaml:

options:
  name: 'config'
  dest: 'app/config/config.js'
  constants:
    ENV:
      apiLocation: ''
      appID: 'MyApp'
      appVersion: '<%= package.version %>'
  development:
    constants:
      ENV:
        apiLocation: 'http://localhost:3000/api'
  staging:
    constants:
      ENV:
        apiLocation: 'https://staging.example.com/api'
  production:
    constants:
      ENV:
        apiLocation: 'https://api.example.com'

Isn’t this cleaner? And it’s shorter, too!

Also notice how I did not have to manually parse my package.json to access its values? This is another nice feature of load-grunt-config’s which comes in handy. All you need to do is to read your values using a grunt template like'<%=package.version%>'.

Sharing values between tasks

In my project I used to have some variables holding some values shared by many different tasks. Lets take for instance the files list, which can be used byconcat, but also by uglify or copy or whatever. So I had something like this:

module.exports = function (grunt) {

  var files = [

    // Application files
    'app/**/*.module.js',
    'app/module/**/*.js',
    'app/component/**/*.js',
    'app/service/**/*.js',
    'app/app.js',

    // Do not include tests in application build
    '!app/**/*.test.js',
    '!app/**/*_test.js'
  ];

  grunt.initConfig({
    jshint: {
      options: {
        jshintrc: true
      },
      all: {
        src: [files]
      }
    },
    uglify: {
      production: {
        src: files,
        dest: 'dist/app/js/<%= package.name %>.min.js',
        sourceMap: true
      }
    }
  });
};

How can I do to share these values across tasks now that they each live in their own file? Well first I created a grunt/project.yaml file holding these values:

files:
  # Application files
  - 'app/**/*.module.js'
  - 'app/module/**/*.js'
  - 'app/component/**/*.js'
  - 'app/service/**/*.js'
  - 'app/app.js'
    # Do not include tests in application build
  - '!app/**/*.test.js'
  - '!app/**/*_test.js'

And here’s the magic in the grunt/jshint.yaml file:

options:
  jshintrc: true
all:
  src:
    - '<%= project.files %>'

And the same goes for grunt/uglify.yaml:

production:
  src: '<%= project.files %>'
  dest: 'dist/app/js/<%= package.name %>.min.js'
  sourceMap: true

That was easy!

Separating configuration files by environment

As you could see, in my project I use grunt-ng-constant to create an appropriate configuration file according to the environment. I also use grunt-env in combination with grunt-preprocess to configure my index.html file differently according to the environment. I wanted to have a single file with all the configuration for a single environment so that it would be easier to verify and change them, and once again load-grunt-config came to the rescue!

I used config grouping to do that:

# File: development-tasks.yaml
ngconstant:
  constants:
    ENV:
      appVersion: '<%= package.version %>-dev'
    apiLocation: 'https://devel.example.com/api'
env:
  ENV: 'DEVELOPMENT'
  THEME_CSS: 'css/mytheme.devel.css'

Using this configuration I can now have a separate file for each environment. The grunt/ngconstant.yaml and grunt/env.yaml files become like this:

# File: grunt/ngconstant.yaml
options:
  name: 'config'
  dest: 'app/config/config.js'
  constants:
    # These are all default values
    ENV:
      appName: 'MyApp'
      appVersion: '<%= package.version %>'
    apiLocation: 'https://api.example.com/api/v1'

# File: grunt/env.yaml
options:
  add:
    THEME_CSS: 'css/mytheme.css'

As you can see, there are only the default options there and no environment specific configuration.

I also wanted to separate the environment-specific configuration files from the standard task configurations, so that the context would be clear. So I put them all in a config directory, which I created, and modified our Gruntfile.js:

module.exports = function (grunt) {

  var path = require('path');

  require('load-grunt-config')(grunt, {
    configPath: [
      path.join(process.cwd(), 'grunt'), // Task settings here
      path.join(process.cwd(), 'config') // Environment specific settings here
    ],

    /*
     * If you want to change your setting locally without changing what is on
     * the repo, you can define your configuration overrides in config/override
     */
    overridePath: [
      path.join(process.cwd(), 'config', 'override')
    ],

  });

};

load-grunt-config also supports overrides, which is another nice feature: as I set it up, you can create a configuration file in config/override which will override any previously set configuration option. This is very useful to accomodate the needs of every developer which might be a little different, without having them modify the files which are under versioning. Pretty neat!

Conclusion

load-grunt-config is a very nice grunt plugin which really improves the quality of your Gruntfile by splitting it into many smaller files. Not only that: it adds a lot of useful features that will make you wonder why bother writing plain Gruntfiles anymore!

Do you use load-grunt-config in your project? Is there some other great feature I missed? Please leave a comment below!