Tag: featured

  • Time zone conversion in Google Sheets

    Time zone conversion in Google Sheets

    Google Sheets does not have a built in way of converting time zone data but by using the power of Moment.js and Google’s script editor we can add time zone functionality to any sheet.

    First, we need to add the Moment.js code as a library that can be shared between different documents. This is the javascript library that adds date and time zone manipulation support. A good way to do this is to create it from Google Drive so it can be easily edited and shared with all your sheets.

    In Google Drive, go to New > More > Connect more apps and choose Google Apps Script. Now, create a new Google Apps Script document. This will open the Google script editor. Call the project ‘Moment’ and create two files in the project called moment.js and moment-timezone.js using the moment and moment-timezone libraries. Make sure you choose one of the moment-timezone files with time zone data. You should end up with a project something like this:

    To easily use this in multiple sheets we can publish it as a library. Go to File > Manage versions and save a new version. We are nearly finished here but before we move on go to File > Project properties and make a note of the project key, you will need this to refer to your library in your sheets.

    In our test we are going to use our new library to convert times in a local time zone to UTC.

    Create a new Google sheet and enter a date in A1 and a time zone in B1, like this:

    Go to Tools > Script editor and create a project called Functions. In the script editor, go to Resources > Libraries and using the project key you made a note of before add your Moment library and select version 1. I prefer to use a shorter identifier like ‘m’. Click save and your library is now accessible to your sheet’s script. We can create a function to convert to UTC like this:

    function toUtc(dateTime, timeZone) {
      var from = m.moment.tz(dateTime, timeZone);
      return from.tz("Etc/UTC").format('YYYY-MM-DD HH:mm:ss');
    }

    Save your project and you can now use this function in your sheets like this:

    =toUtc(TEXT(A1, "YYYY-MM-DD HH:mm:ss"), B1)
  • A systemd unit file for Play Framework

    A systemd unit file for Play Framework

    New for Ubuntu 16.04 (Xenial Xerus) is systemd which replaces Upstart as the default init system.

    systemd basics

    The basic object that systemd manages is the unit which can be of different types but when it comes to running our Play app we will need to create a service.

    The systemctl command is used to manage systemd services, similar to the old service command. E.g. to start Nginx you now type:

    sudo systemctl start nginx.service

    Custom unit files should go in the /etc/systemd/system directory and you should always run the following command after creating new unit files or modifying existing ones:

    sudo systemctl daemon-reload

    Run levels have been replaced with systemd units called targets. Target unit files end with the .target file extension and they are used to group other units.

    A Play Framework unit file

    Here is a basic Play Framework systemd unit file. It makes use of the EnvironmentFile directive which can be used to set environment variables. It is possible to set environment variables in the unit file directly but using a separate file takes some of the clutter out.


    ADDRESS=127.0.0.1
    PORT=9000
    APPLY_EVOLUTIONS=true
    APPLICATION_SECRET=my_secret

    view raw

    env

    hosted with ❤ by GitHub


    [Unit]
    Description=My play app
    After=network.target
    [Service]
    EnvironmentFile=/path/to/app/conf/env
    PIDFile=/path/to/app/RUNNING_PID
    WorkingDirectory=/path/to/app
    ExecStart=/path/to/app/bin/play -Dhttp.address=${ADDRESS} -Dhttp.port=${PORT} -Dplay.evolutions.db.default.autoApply=${APPLY_EVOLUTIONS} -J-server
    Restart=on-failure
    User=play_user
    Group=play_user
    # See http://serverfault.com/a/695863
    SuccessExitStatus=143
    [Install]
    WantedBy=multi-user.target

    view raw

    play.service

    hosted with ❤ by GitHub

    Deploying the unit file

    • Create the env file in your app’s conf directory and unit file in /etc/systemd/system
    • Set the file permissions
    sudo chmod 664 /etc/systemd/system/play.service
    • Reload systemd
    sudo systemctl daemon-reload

    You can now start and stop your play app using systemctl

    sudo systemctl start play.service
    sudo systemctl stop play.service

     

  • A Kanban and Scrum workflow with JIRA Agile

    A Kanban and Scrum workflow with JIRA Agile

    JIRA Agile has come a long way from the days of the GreenHopper plugin. It’s now pretty well integrated into JIRA and I’ve found it great for running an Agile workflow.

    JIRA Agile supports both Scrum and Kanban boards so you can manage your tickets using whichever methodology you prefer but what if different parts of your team want or need to work in different ways? With JIRA Agile you can have multiple boards so tickets flow through different teams in different ways.

    Maybe your developers are using Scrum with week long sprints. They want a standard Scrum board where they can take tickets from the To Do column, move them into In Progress when work starts and then to Done when complete.

    But perhaps weekly sprints don’t really suit the planning workflow of your product team. They would prefer to use a Kanban approach of managing their work in progress.

    Ideally we want to be able to create tickets on the product team’s board and move them into the developers’ board when they are at a suitable stage of readiness. By mapping statuses you can have a kind of combined Kanban/Scrum process.

    Product Board

    This is a Kanban board with 5 columns: Backlog, Requirements, Ready for development, Test and Ready for release. Each column is mapped to the following respective Statuses: IDEA, REQUIREMENTS, TO DO, RESOLVED and CLOSED. The IN PROGRESS status is left unmapped so tickets in this state will not show up on the board.

    The product team can work on tickets in the Backlog and Requirements phases before moving them to the Ready for development column which will cause them to show up in the Development Scrum board (as we will see).

    Once the developers have completed a ticket it can be moved into the RESOLVED state and it will then reappear on the Product board in the Test column. When the product owner is happy that the requirements have been met it can be moved to the Ready for release column.

    Development Board

    This is a Scrum board with the standard three columns: To Do, In Progress and Done. Some tickets may not need to be sent back to product for review and can be closed directly so the Done column has both RESOLVED and CLOSED statuses.

    Scrum Board
    Scrum development board

    When planning a sprint, the Development board will only show those tickets with a status of TO DO in the backlog. Tickets that are still being prepared by the product team (IDEA and REQUIREMENTS) are left unmapped so won’t show up until they are ready to be scheduled into a sprint. Once a ticket is moved into the RESOLVED state it will reappear on the Product board.

    By combining Scrum and Kanban boards you can create a hybrid workflow that better suits the needs of the people actually working on the tickets. You don’t need to force everyone into a single way of working.