antonbabenko

'use strict';

const crypto = require('crypto');

exports.handler = (event, context, callback) => {
    const request = event.Records[0].cf.request;
    const headers = request.headers;
    const method = request.method;
    const body = Buffer.from(request.body.data, 'base64').toString();

hermanbanken

This was initially posted in an kubernetes-sigs/kustomize issue.

We are using Kustomize's vars feature. Initially we didn't understand how to use it for our purpose, but it is a 100% fit. One example is our Ingress resource, which looks like this:

# file: base/ingress.yaml
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: services

noto

これは私が支援先に提供した、1 on 1 に関するノウハウや、思いを述べたドキュメントを元にしています。企業の枠を超えて共有したいことが多いので、ここに貼ります。

概要

• 世の中には 1 on 1 の本があるようですが、とりあえずは『1 on 1 で 何を話すのか？ マネージャ/ソフトウェアエンジニアの立場から - サンフランシスコではたらくソフトウェアエンジニア』を読んでもらえればよいと思います (higepon さんに感謝!)。
• 1 on 1 は 1 対 1 で話すミーティングで、基本定期的にやります。上長とメンバーとの間で行うのが基本です。
• グループ/チームでのミーティングを補完するためのものです。
  • みんなの前では話しづらい、込み入った内容を話します。
  • チームとして行っているタスクの進捗確認に 1 on 1 を使うのは避けましょう。それは 1 on 1 の目的に沿っていません。
• 基本、「メンバーの時間」と捉えてください。メンバーが話したいこと、上長に質問したいこと、相談したいことを話す時間です。
• ですので、上長は相手の話をさえぎらず、聞くことに徹してください (話すのが得意な人、好きな人がマネージャになっている可能性が高いというバイアスに注意しましょうｗ)。

mpppk

2020/5/31追記: 自分用のメモに書いていたつもりだったのですが、たくさんのスターを頂けてとても嬉しいです。
と同時に、書きかけで中途半端な状態のドキュメントをご覧いただくことになっており、大変心苦しく思っています。

このドキュメントを完成させるために、今後以下のような更新を予定しています。

• TODO部分を埋める
• 書籍を基にした理論・原則パートと、実装例パートを分割
  • 現在は4層のレイヤそれぞれごとに原則の確認→実装時の課題リスト→実装例という構成ですが、同じリポジトリへの言及箇所がバラバラになってしまう問題がありました。更新後は、実装時の課題リストを全て洗い出した後にまとめて実装を確認する構成とする予定です。

2021/1/22追記:

rmosolgo

# This is a full-blown offset-based pagination system modelled after GraphQL-Ruby's
# built-in connections. It has a few different elements:
#
# - `::Page`, a plain ol' Ruby class for modeling _pages_ of things.
#   This class handles applying pagination arguments to lists (Arrays and AR::Relations)
#   and provides metadata about pagination. (Similar to `will_paginate`.)
# - `Schema::BasePage` is a generic GraphQL-Ruby object type. It's never used directly,
#   but it can generate subclasses which wrap _specific_ object types in the schema.
# - `Schema::BaseObject.page_type` is a convenience method for generating page types
#   from your object types. You could leave this out and make subclasses with plain ol'

1natsu172

{
  "parser": "@typescript-eslint/parser",
  "parserOptions": {
    "project": "./tsconfig.json",
    "tsconfigRootDir": "."
  },
  "env": {
    "browser": true,
    "jest/globals": true
  },

kawasima

アーキテクチャ設計のドキュメンテーション

コンテキスト

アジャイルプロジェクトのアーキテクチャは、別々に記述され定義されなければなりません。すべての意思決定が一度にされるわけでもなく、プロジェクト開始時にすべての意思決定がされてるわけでもありません。

アジャイル手法では、ドキュメンテーションに反対はしませんが、価値のないドキュメンテーションはいけません。チーム自身の助けになるようなドキュメントは価値がありますが、ちゃんと最新化し続けなければなりません。膨大なドキュメントでは、最新化されなくなることでしょう。小さくまとまりのあるドキュメントは少なくとも更新される可能性はありますよね。

また膨大なドキュメントはだれも読みません。たいていの開発者はソースコードサイズの合計よりも(byte的な意味で)大きな仕様書が書かれたプロジェクトを少なくとも1回は経験したことがあるでしょう。開くのにも、読むのにも、更新するのにも、そんなドキュメントは大きすぎます。一口大のピースに分解すれば、すべての関係者にとって消化するのは簡単になりますよね。

プロジェクトが動いている間、追跡するのが難しいことの1つに、ある意思決定の裏に隠された「思い」があります。プロジェクトに新しく参画した人は、それまでに決定されたことに困惑したり、戸惑ったり、喜んだり、怒ったりすることでしょう。理念や因果関係を理解しておかないと、その人は次の2つの選択をすることになります。

swalkinshaw

Moved to Shopify/graphql-design-tutorial

manabuyasuda

Noto Sans JP

Noto Sans JPをWebサイトで使う場合、大きく分けて2つの方法があります。

1. CDNを使う場合
2. サーバーにフォントファイルを置く場合

CDNの場合は、他のサイトを含めて一度でも読み込まれていればブラウザ側でキャッシュを持っているので、読み込み速度が速くなることが期待できます。
サーバーのフォントファイルはサブセット化（不要なデータを削除すること）でファイルサイズを削減できるメリットがあります。

基本的にはCDNを利用して、フォールバックとしてサーバーに置いたフォントファイルとシステムフォントを指定するのがいいでしょう。

theorygeek

# frozen_string_literal: true
class AssociationLoader < GraphQL::Batch::Loader
  attr_reader :klass, :association

  def initialize(klass, association)
    raise ArgumentError, "association to load must be a symbol (got #{association.inspect})" unless association.is_a?(Symbol)
    raise ArgumentError, "cannot load associations for class #{klass.name}" unless klass < ActiveRecord::Base
    raise TypeError, "association #{association} does not exist on #{klass.name}" unless klass.reflect_on_association(association)

    @klass = klass