DEV Community: Gavin Rehkemper

Clean Pull Request Diffs

Gavin Rehkemper — Fri, 27 Jan 2023 14:46:00 +0000

When collaborating on code with others using Git, keeping the overall list of code changes (the "diff") in a pull request as small as possible - not including lots of unnecessary changes like quotes and tabbing - is an important and considerate thing to do.

Why lots of unrelated changes suck

A pull request (aka merge request) represents a request to merge a branch that has multiple outstanding commits, with each of those commits representing a variety of lines of code changes. These code changes are shown on the pull request summary and is one of the main things someone who reviews the pull request reviews.

For those reviewers, it takes time and mental energy to understand what code change you're proposing: what it intends to do, what it actually does, and if there are any obvious bugs. When you have many un-related changed lines in the diff, that forces the reviewer to also analyze which lines are "actual" changed lines and which are unnecessary and can be ignored.

A diff that's hard to see what are the significant changes

It discourages (good) reviews

The review process is already difficult enough. In many situations the reviewer is taking time out of his/her busy schedule to change contexts and review your code. Changing mind contexts then fully understanding the code changes takes a lot of effort, and adding any additional challenge to this process makes it that much harder. If a reviewer sees a large PR with a bunch of unnecessary code changes, it may influence him or her to just skip the review or perform a "low value review."

Avoid it

So, create change requests that contain only the minimum necessary code changes to fix the bug or add the feature that your pull request is trying to do. Any additional lines are detrimental to the software creation process.

Query All Features from a Feature Service

Gavin Rehkemper — Tue, 31 May 2022 19:34:18 +0000

When querying an ArcGIS Feature Service, there is typically a maximum number of features (records) that will be returned from any query – usually set to 1000. If you want to query for all the features in the service, ArcGIS REST JS does not currently do this (see this discussion) - you’ll need to make multiple REST calls to get them all. Use the package query-all-features to do this.

First install the package:

npm install query-all-features

Then use it in your code. It takes as input the same object as the queryFeatures endpoint of ArcGIS REST JS.

import { queryAllFeatures } from "query-all-features";

queryAllFeatures({
    url: "https://sampleserver6.arcgisonline.com/arcgis/rest/services/USA/MapServer/0"
}).then((results) => {
    console.log('results', results);
}, (err) => {
    console.error('err', err);
});

You can also use it in NodeJS, in the browser via ES Modules (via CDN), and in the browser via a script tag. Here's a full code sample in action:

https://codepen.io/gavinr/pen/ExQYegd

Svelte + Vite Web Mapping App in 3 Steps

Gavin Rehkemper — Tue, 14 Sep 2021 14:34:26 +0000

Using the ArcGIS API for JavaScript

Getting started building a web mapping app is quick and easy with Svelte and Vite. Here are the steps:

Run the Vite init workflow choosing the Svelte template:

npm init vite@latest esri-svelte-project --template svelte

or if you prefer TypeScript:

npm init vite@latest esri-svelte-project --template svelte-ts

Then install the dependencies and run:

cd esri-svelte-project
npm install
npm install @arcgis/core --save-dev
npm run dev

Copy contents of App.svelte in this repository into your App.svelte.

The result is a simple, interactive map on the page like this, but you can do a lot more. For example, a full page emergency call mapping application.

More Info

Support Software Developers

Gavin Rehkemper — Tue, 14 Sep 2021 13:44:34 +0000

Support what you use and enjoy. This is true in all aspects of life, including software. Especially open source software.

Here are a few simple ways to do that.

1. "Star" the project on GitHub (FREE)

Giving a project a "star" tells the developer that you appreciate their effort. It costs you nothing, but is quite encouraging to the developer when it appears in the feed.

This encouragement is important because open source projects generally do not get any feedback when the software works well -- the developer only hears about problems and bugs.

2. Send a personal thank you message (FREE)

Find the developer's email address via GitHub or their personal website, and send a quick note of thanks and appreciation. It need not be long or complex. Taking a small amount of time out of your day to do this is very meaningful and really encourages the developer.

This can be done using social media, but I encourage doing it via email because it's more personal and feels more direct. If you're big into social media, do via social media and email!

3. Send money

If you have the means, taking a small portion of your donation budget each year to send it to software developers who work on the software you enjoy is a great way of saying thanks. Sending a donation is easier than ever.

If the software has an Info or About page, it might mention ways to donate there.
If the project has a GitHub page, check the "Sponsor this project" section.
Find a contributor by going to the GitHub repository "Insights > Contributors" page and see if they have a GitHub Sponsors or other sponsorship link on their user page.
Find their personal homepage to see if they accept donations via an alternative method.
If none of these steps led you to a donation page, go back to option two above, and ask if they have a way to donate directly.

Map Stream - Live view of ArcGIS Online Maps

Gavin Rehkemper — Fri, 21 May 2021 02:22:12 +0000

Map Stream is a web app showing a live stream of newly-updated public maps on ArcGIS Online.

The interesting thing about watching everything stream by is the variety: topic, location, age, popularity. Just about anything can pop up.

Built with Svelte, the source code is public: github.com/gavinr/map-stream.

Check it out: map-stream.gavinr.com

Find the Coordinates for a Location

Gavin Rehkemper — Mon, 08 Mar 2021 05:51:49 +0000

Finding the latitude and longitude coordinates of a particular location is not as easy as it should be. You can get it from Google Maps, but it requires 3 or 4 clicks. There are also a bunch of sites devoted to the task - most with ads and invasive spyware slowing down the page.

We need something better - that's why I created Latitude Longitude Locate. Latitude Longitude Locate is a simple mapping app designed for geo developers. Click on a location where you want to get the coordinates, and click the "copy" icon. Those coordinates are now on your clipboard - two clicks.

There are also a few more features, like the ability to swap the order of latitude/longitude.

It's meant to be simple and quick. I hope it helps you out. Let me know if you have any ideas or suggestions to make it even better.

LatLonLocate.com

Export or Import Issues from GitHub

Gavin Rehkemper — Wed, 29 Apr 2020 04:34:02 +0000

GitHub CSV Tools now supports exporting issues!

Choose what columns you want in the exported CSV with --exportAttributes.
Export all the comments per issue with --exportComments

Importing issues via a CSV is also possible, just pass a CSV file like githubCsvTools myFile.csv.

To get started, just run npm install -g github-csv-tools and then export with the command githubCsvTools.

Enjoy!

gavinr / github-csv-tools

Import and export GitHub issues via CSV

Usage

Prerequisite: Install Node.js, then run this to install:

npm install -g github-csv-tools

After install, githubCsvTools --help for info on how to use, or see below.

Instructions for exporting or importing:

To Import Issues

Currently imports title, body, labels, status (closed or open) and milestones. See the test folder for example input formats.

githubCsvTools myFile.csv

To Export Issues

githubCsvTools

Option	Default	Notes
-f, --exportFileName	YYYY-MM-DD-hh-mm-ss-issues.csv	The name of the CSV you'd like to export to.
-a, --exportAttributes	number, title, labels, state, assignees, milestone, comments, created_at, updated_at, closed_at, body	Comma-separated list of attributes (columns) in the export**.
-c, --exportComments	n/a	Include comments in the export. If using in combination with `--exportAttributes`, `id` must be included.
-e, --exportAll	n/a	Export all possible values from the GitHub API. If not included, a subset of attributes (see `--exportAttributes` above) that are known to be compatible

…

View on GitHub

How to open a GTFS Bus Feed in the Browser

Gavin Rehkemper — Sun, 05 Apr 2020 20:57:27 +0000

The GTFS Real-time feed is a data specification for sharing real-time transit data. In other words, many transit systems share a public feed in this format for developers to use to build apps, websites, and more.

The most basic way to get going with this type of feed is to show the current locations on a map in a browser. This is not too tough, but there are a few things you need to get correct.

Decoding the PBF Feed

The GTFS Specification says that the data feed will be encoded using Protocol Buffers (aka protobuf or PBF). There are a few JavaScript libraries for decoding protobufs - I used the pbf library.

The thing about protobuf is that the "schema" of the data is not sent when the data is sent - your client that reads the data must "already know" the schema. Luckily, we know our feed is in the GTFS scheme and they even provide the schema file (protobuf schema files, when published, are usually named ___.proto).

We must convert that .proto file into something our JavaScript library (pbf) can use. The library provides a command-line interface to do this, but I've already done that for you and published the files onto npm so we can use them via a CDN. In other words, the first step is to import these JS files into your file:

https://unpkg.com/pbf@3.0.5/dist/pbf.js
https://unpkg.com/gtfs-realtime-pbf-js-module@1.0.0/gtfs-realtime.browser.proto.js

Then we must write some code to actually get the data feed and decode it. That will look like this:

const url =
  "https://my-transit-agency.org/path/to/feed.pb?cacheBust=" +
  new Date().getTime();
let response = await fetch(url);
if (response.ok) {
  // if HTTP-status is 200-299
  // get the response body (the method explained below)
  const bufferRes = await response.arrayBuffer();
  const pbf = new Pbf(new Uint8Array(bufferRes));
  const obj = FeedMessage.read(pbf);

  console.log("the data!", obj.entity);
} else {
  console.error("error:", response.status);
}

The keys to the above code:

We're using the fetch API, but you could use plain XMLHttpRequest or any other request library just as easily, as long as you do the following:
We grab the data as an arrayBuffer (await response.arrayBuffer())
.. then put the data into a Uit8Array (new Uint8Array(bufferRes))
The new Pbf(...) and FeedMessage.read(...) are functions provided in the pbf package.

You then just use obj.entity to loop through your data and do what you want with it. In our case, add it to a Leaflet GeoJSON layer and map it!

Mapping the Data

To convert the GTFS feed data to GeoJSON to map it, loop through the array of data and return back a GeoJSON feature for each item:

const gtfsArrayToGeojsonFeatures = (gtfsArray) => {
  return gtfsArray.map((gtfsObject) => {
    // console.log("gtfsObject", gtfsObject);
    return {
      type: "Feature",
      properties: {
        // Depending on your data source, the properties available on "gtfsObject" may be different:
        route: gtfsObject.vehicle.trip.route_id,
        route_start: gtfsObject.vehicle.trip.start_time,
        vehicle_label: gtfsObject.vehicle.vehicle.label
      },
      geometry: {
        type: "Point",
        coordinates: [
          gtfsObject.vehicle.position.longitude,
          gtfsObject.vehicle.position.latitude
        ]
      }
    };
  });
};

Place those features into a Leaflet GeoJSON layer, add it to a map, and you've got your mapped locations!

Full Code

Putting it all together, here's what the code would look like:

CORS

Your GTFS feed must have a CORS header to allow your webpage to access the feed. If it doesn't, you may be able to use a proxy to add that header, or talk to the data owner asking them to add the CORS header to allow easier usage.

Links

What public GTFS feeds are you using, and how are you using them? Let me know in the comments! Thanks!

How to use GitHub Actions to Automatically deploy a Sapper PWA to GitHub Pages

Gavin Rehkemper — Wed, 26 Feb 2020 04:34:10 +0000

Sapper is a framework for building web applications, where every page is a Svelte component.

You may want to setup your GitHub repository to use GitHub Actions to automatically build and deploy your site to GitHub Pages website hosting every time you check in your code. This is great because the build/deploy step happens automatically for you - no need to manually do it yourself! Here's how to set that up:

Create a new GitHub Repository and copy the Sapper template files to it.
Ensure gh-pages is enabled by going to the repository setting tab and enabling it.
To enable Sapper to live at a subdirectory (yourname.github.io/repo-name), modify the export task in package.json to include --basepath repo-name (replacing repo-name with the name of your GitHub repository). It should look like this:
```
"export": "sapper export  --basepath repo-name --legacy",
                          ^^^^^ add this ^^^^^
```

In src/server.js, right after polka().use(, add a string as the first parameter with the repository name, so it will look like this:

polka() 
.use(
  'repo-name', // Add this line
  compression({ threshold: 0 }),
  sirv('static', { dev }),
  sapper.middleware()
)
.listen(PORT, err => {
  if (err) console.log('error', err);
});

Create a GitHub Access Token by going to github.com/settings/tokens (scopes: repo access)
Place that GitHub Access Token into the repository "Secrets" by going to the repository settings tab, then clicking the Secrets page. I named mine github_pat (used below)

Create a new file, .github/workflows/main.yml, with the contents below. Replace secrets.github_pat with the name you gave to your GitHub Token in step 5. Replace FOLDER: __sapper__/export/repo-name with the name of your repository (used above in step 3 and 4).

name: Build and Deploy
on:
  push:
    branches:
      - master
jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
    - name: Checkout
      uses: actions/checkout@v2
      with:
        persist-credentials: false

    - name: Use Node.js '12.x'
      uses: actions/setup-node@v1
      with:
        node-version: '12.x'
    - run: npm install
    - run: npm run export
    - name: Build and Deploy
      uses: JamesIves/github-pages-deploy-action@releases/v3
      with:
        ACCESS_TOKEN: ${{ secrets.github_pat }}
        BRANCH: gh-pages
        FOLDER: __sapper__/export/repo-name

After this is all setup, any time you commit to the master branch (or whichever branch you configured), the code will get built and deployed to GitHub Pages website hosting. Here is an example repository where you can see this in action. Enjoy!

Originally posted on gavinr.com

Publish a Svelte Web App with GitLab Pages

Gavin Rehkemper — Sat, 15 Feb 2020 19:35:20 +0000

If you've built a Svelte web application and would like to host it, you can do so easily using GitLab Pages.

Create and clone a new GitLab repository.
Download and extract the Svelte Starter Template into the repository.
Since your URL will be at a subdirectory (https://username.gitlab.io/repository-name), make the references to the JS and CSS files in your public/index.html file relative. In other words, remove the leading / from the /global.css, /build/bundle.css, and /build/bundle.js URLs.
Create a .gitlab-ci.yml file at the top-level of the repository, with the following contents:

   image: node:latest
    pages:
      stage: deploy
      script:
        - npm install
        - npm run build
      artifacts:
        paths:
          - public
      only:
        - master

This says, when there's a new commit on master (last line), use the node:latest docker image to check-out the code and run npm install and npm run build commands.

Your site will now be live - find the URL under GitLab Settings > Pages. Check the CI/CD status page of your GitLab repository to see the status of the build process if you ever have issues with that. Unlike GitHub, the site is not public by default. To make it publicly accessible, go into GitLab Settings > General > Visibility, project features, permissions and set Pages to Everyone. Your site is now available!

Thanks to https://dev.to/bryce/how-to-automatically-deploy-to-gitlab-pages-w-ci-4iko for help on this process.

Originally posted on gavinr.com