https://www.library.chiyoda.tokyo.jp/information/20191010-post_211/

ヒラギノ作者が語るフォントの話。

「本をつくる」は良い本だそうだ。 ライターの人がとても良い仕事をした、と。

立て続けに講演依頼があったが、毎回内容を変えてほしいという依頼。 最終的に同じ話になってしまっている。

読書と文字

• 洛陽からの金印で初めて日本に漢字が伝わった
• 中国文字博物館
  • でかい、広い
  • 洞察力の優れている人は肖像画で目が4つ書かれる
• 瓦当（がとう）博物館
  • 篆書、隷書
• 活字の技術
  • 1行の長さがだいたい揃っている
  • 読み方が漢字で振ってある
• 100年後の人間は想像できない
  • PTA全国大会での話

日本語組版のための文字を作る

• 横組みと縦組み
  • 両方やっている国はもう他にない？
• 4つの文字体型
  • 漢字、ひらがな、カタカナ、アルファベット
• 錯視
  • 横のほうが太く見える
  • 正方形の真ん中だと思ってマークすると、左上に寄ることが多い
• 12文字の書体見本
  • 東、国、三、愛、霊、今、鷹、永、力、袋、酬、鬱
• 字種拡張
  • 書体見本 12種
  • 種字 400種
  • AJ1-3 7000種
  • AJ1-6 15000種
• アルファベットの配置が難しい
• ふところ、太さ、エレメント、重心
  • ヒラギノは若々しいイメージを出すために重心を高めにしている
• かなの大きさが読みやすさには大事
• 漢字は書き順をあまり意識しないが、かなのデザインには書き順やアツなどたくさん考慮する

明朝体、ゴシック体、丸ゴシック体、教科書体、UD書体について

• 明朝体が嫌い（怖い）という人もいる
• ファミリーは単に太さを変えているだけではない
• かなは左上から左下に抜けていく。縦組み向き。
• ゴシックは流れがないから横組み向き
• 小学校の英語義務化に使うフォントは今ひとつだけ
• UDがすべて読みやすいとは限らない
  • 使うときは見比べて。

レタリング実演＆質疑応答

• 「な」
• 「な」のもとの漢字は「奈」なので、右上の点が横線より上に来るのはおかしい
• フォントの著作権
  • ロゴとかで使うときは変形するなどひと手間かけて
  • 使用許諾に沿って
• 「游」は社名から
• 「ヒラギノ」は京都の地名から
• 「JK」も社名から
• 文字作成は自己表現だと思っていない

ビックカメラのポイント20%セールで。ポチったあとにアマゾンで19%オフやってておいおいって思った。

これでクラムシェルとコンバーチブルとタブレットのChromebookが揃って、充電器が足りなくなってきたので（本体付属のはごつすぎる・・）、 もらったポイントで買い足そうかなと。

二日目（最終日）です。

今日もサーバーレス系中心に見ていきたいと思います。

10:00〜10:45 オープンソースコミュニティで加速するサーバーレスの未来

• クラウドの世界の中にいながら、オープンソースコミュニティに参加することの意味と楽しさ
• Lambdaの問題（当時）
  • マネコンにソースを直接アップロードするのでバージョン管理どうする
  • CI/CDどうする
• それを解決できるServerless Frameworkの登場
• Serverless Setp Functions
• OSS活動を継続的に続けるモチベーション
  • スキルのあるプログラマからのレビューを受けられる。スキルアップできる。
  • 遠くの国のあったことのない人から感謝される喜び
  • 自分の書いたコードがたとえ1行だとしても世界中の人に使われて、どこかの誰かの役に立っているかもしれない
• OSS活動を継続させるには
  • 誰からも反応なく飽きてしまう、地味
  • スターが1000以上、関わっている人が複数いる、help-wantedタグがついているissueがあるプロジェクトに継続的にプルリクを送り続ける
  • 先送りにされている問題を潰していく人の存在は重要
  • プルリクを出し続けたプロダクトのプラグインなど付随のOSSを出してみる
• オープンソースの未来とサーバーレス
  • Cloud2.0
    • 究極のサバーレスアプリケーションには全くコードがない
    • サーバーレスの狙いはよりコードを少なくクラウドのサービスをできる限り使うこと
    • フルマネージドサービスをうまく利用することで責務の多くをクラウドに任せ、ビジネスバリューを出すための仕事に集中すること
  • Cloud2.0の時代でも、コードを書くということが本質的になくなっていくことはない
  • 新しいものが出るということは新たな問題も発生するということ。問題とはチャンスであるということ。

11:00〜11:45 Chaos Engineering ～入門と実例～

Chaos Engineering の進化と今

• 障害を避ける最も良い方法は継続的に障害を起こさせること（Netflix TechBlog 2010.12.16）
  • Chaos Monkey: インスタンスをランダムに停止
• Failure Injection Testiong(2014.10)
• Chaos Monkey, Simian Arm
  • 影響範囲の限定が難しい
• Chaos Kong(2015.9)
• PRINCIPLES OF CHAOS ENGINEEERING
  • カオスエンジニアリングとは、「対象とするシステムが本願環境における不安定な状況を耐えることができる」という自信を構築するために当該システムにおいて実施する
• ChAP: CHaos Automation Platform(2017.7)
• Aitomaiong chaos experiments in production(2019.5)
• Gremlin Inc
  • 仕組みやツールを提供する企業
• ChaosTOolkit
  • OSS
• Chaos Testに取り組むなら、最低限の可用性設計はできていることが望ましい。

後半

• Chaosconf振り返り
• Our 4 Setp Aproach
  • 定常状態
  • 仮説設定
  • 故障発生
  • 仮説反証
• Our Next Aproach
  • 影響の最小化

12:00〜12:45 よくある課題を一気に解説　御社の技術レベルがアップする 2019 秋期講習

• コンテナのCI/CDちゃんとしたい

  Read more

今年も来ました。

去年は目黒のAWSオフィスで3日間でしたが、今年は神田明神ホールで2日間になっています。

https://aws.amazon.com/jp/about-aws/events/2019/devday/

• AWSグローバルで開催する開発者のためのトレーニングイベント
• 最新のテクノロジー、開発手法などを集中的に学ぶことができる場
• セッション公募を行い、11件採択された

10:00～11:40 ゼネラルセッション

＠岡嵜 禎

• AWSではBuilderという言葉を大事にしている
  • 開発者
• amazon go 北米ではすでに10店舗以上展開
  • 多数センサーからのリアルタイムデータをリアルタイムで処理できている
• Prime Air
  • 5万モデル検証、1万機作成して検証
• Project Kuiper
• 様々な場面と用途で使われる機械学習
  • AIサービス、MLサービス、フレームワーク＆インフラストラクチャのレイヤ
    • 利用者のレベルによって使い分けられる
• Well-Architected Framework
  • ホワイトペーパーとツールを提供
  • ツールは9月に日本語版リリース
• On Builders and Dreamers
  • ジェフベゾスの言葉

＠まつもと ゆきひろ

• プロ・プログラミング技術者
• 20世紀の言語
  • インターネットとともに
  • Ruby, JS,
• 2000年代
  • 手軽、柔軟、生産的、楽しい
• 2010年代
  • 関数型、手堅い
  • ブロック、型推論、少ないお約束
  • 企業によるスポンサー
    • Go, Swift, Rust, TypeScript
• どの言語を選ぶか？
  • 評価基準を持つこと
  • 生産性（効率、コスト）
  • 唯一の解はない
    • 背景によって異なる
  • 判断を人に任せない
  • 風をおこし、強める

＠倉貫 義人

• SIerの受託開発の中でアジャイルをやるのは難しい
• そもそもアジャイルがマッチする案件なのか（制約条件）
• 納品のない受託開発
  • 月額定額
  • 見積り、要件定義（ビジネス上の制約）しない
  • クラウド、OSSのおかげで一人でできることが増えた
• Software is eaticg the world
• ソフトウェア開発の本質 　- 大量生産、ルーチンワーク、製造業ではない
  • デザイン、問題解決。ナレッジワークであt
  • プログラミングを手段に、問題解決する仕事
• これから求められる仕事とは
  • 人類の文明の進化は不自由を置き換えてきた
  • 自由な発送が求められる、好きで楽しめるか
  • クリエイティブな仕事、人数のいらない仕事
• この先のエンジニアの生き方
  • ソフトウェア開発の仕事は、減ることはない
  • 腕を磨き続ければ、自分の価値を高められる
    • 人がいなければ、企業は成り立たない
  • あなたの仕事は、難しいからこそ価値がある

トークセッション

• 令和の時代。更に輝くエンジニアになるために必要なこととは
• これまでのキャリアはどのようにして築いてきましたか？
  • まつもと）東京は嫌だったので浜松に就職した。会社が傾いて閑職に置かれてRubyを作り始めた。
  • 倉貫）社内SNSを作ったところから。JavaではなくRoRを選んだ。
• AIがプログラムを書いてくれる時代になったときのプログラマーの存在価値はどうなるか？それでも必要とされるプログラマーとなるために求められることは？
  • まつもと）問題の定義
  • 倉貫）プログラムのデザイン自体クリエイティブな部分、AIが出てきても書けば良い。
• どんな人と一緒に働きたいか
  • まつもと・倉貫）主体性のあるプログラマ
• 自分のスキルアップ
  • まつもと）海外のブログとか見る、得意なところから周辺に広げていく、自分の中にインデックスを作る
  • 倉貫）得意があるメンバーでチームを組む

12:00～12:45 第1回 AWS Fargate かんたんデプロイ選手権

• Fargateとは
  • AWSマネージド
  • コンテナネイティブ
  • AWSサービスとの連携
• ECS on EC2の運用
  • OSやエージェント類へのパッチあて、更新
  • インスタンスのスケーリング
  • コンテナとホスト2重に対応
• Fargate CLI
  • サービスを削除するときはスケールインしてからデストロイ
  • ターナー社がforkしたものもある。インタフェースが異なる。
  • pros
    • vervose オプションで自動生成されるリソースの勉強ができる
    • とにかく簡単
  • cons
    • 本番環境で使うにはちょっとアドホック
      • Fargate CLIのバージョンアップで変わるところがあるかも
    • CI/CDと合わせて構築するには考えないと
• nathanpeck/awesome-ecs
• なぜこんなにたくさんあるのか
  • サービスリリース時には最小限（MVP）なもの
  • リリース後にユーザーからのフィードバックで成長させる
  • 利用者がそれぞれ作るので多くなる

13:00～13:45 マルチテナント時代におけるテスト・ベストプラクティス

場所どり失敗してスクリーン見えなかったのでログなし。

https://www.gitpod.io/

GitHubのブラウザ版で、ブランチ切ったら編集できなくなったので、他にブラウザで使えるエディタないかなと検索して出てきたのがこれです。 GitHub連携するだけで使えるかと思ったらそうではなく、Gitpodにもアカウント作る必要があります。とはいえチェックボックス2つだけなのですぐ終わります。

コンテナの起動に少し時間がかかりました。 起動すると見慣れた画面がブラウザで表示される。VSCodeやんけ・・

https://gcpug-tokyo.connpass.com/event/143453/

• GCPのCloud Buildサービスに関する話。
• AWSだと、CodePipelineとCodeBuildとCodeDeployに相当するもの。

19:30 ~ 20:00 マルチアーキテクチャイメージの作成（仮） @ymotongpoo

• イベントベースでビルドのトリガー（GitHubのpushとか）
• テストの実行とアーティファクトのビルド
• 雑に言うとDocker on Docker
• ビルド実行時間にる対する課金
• Artifact management
  • プライベートコンテナレジストリに自動push＆脆弱性スキャン
• 70以上のビルダーイメージ
• Cloud Console UIで実行状況・結果の確認ができる
• セキュア情報はKMSと連携して暗号化可能
• Dockerが入っていればローカルで試すことができる
• STEPの並行実行ができる
  • 依存関係も定義できる（waitFor）

20:00 ~ 20:25 Cloud Build out of steps @apstndb

• CI/CDにおけるコンテナ間の通信
• K8s IN Docker(KIND)
  • DOckerの中で本物のK8sクラスタを構築するツール
  • 現在アルファ版
  • CircleCI, TravisCI, GitHub Actionで動いた報告あり
• STEP内でdocker buildが使える→docer runも使える→何でもできる
• 他のCI/CDサービスとは異なるアプローチ
• dockerize
  • 他のコンテナの起動を待つ用途で使っている
  • https://github.com/jwilder/dockerize
• Cloud BuildでKINDするには
  • STEPから外れる必要がある
  • Docker Networkが使えないのでhostネットワークを使う＝STEPと直接通信できない
• デモは時間切れ。。

20:25 ~ 20:35 休憩

20:35 ~ 20:50 Cloud Buildを気軽なコンテナ実行環境として利用する @chidakiyo

• 注意点
  • gcloud builds submitした際に指定したディレクトリは以下のファイルが送られる。
  • 巨大なファイルがあると大変。
  • .gcloudignoreで除外指定可能。
  • 無料枠は請求先アカウント単位なので複数プロジェクトでやるとすぐ尽きる
• 事例
  • Dataflowを使っていた処理のCloud build化
  • gcloudコマンドさえ入っていればローカルに諸々インストールする必要がない

20:50 ~ 21:10 LT

yukinagae

• Berglas（ばーぐらす）
  • Cloud KMSとCloud Storageで暗号化できる
• デモは時間切れ。。

SouMatsuda

• Cloud Build x Terraform
• 通常、ローカルで実行する init, plan, apply をCloud Buildで実施する
• インフラの設定変更が頻繁に起きる場合は工数削減に効く
• それなりに学習コストはかかる

kumagai

• Cloud Build で docker-compose と ansible
• 用途
  • 自動テスト用ベースイメージとして
  • 開発者にGCEのテンプレートとともに渡す
  • 社内デモ環境としてGKEで起動

感想

• Cloud Build使ってみたくなった。
• ちょうどblogのCI作ろうとしていたから、これでやってみようかな。

• 他人にものを伝える技術を筆者の経験から書かれている。
• 書いて伝える、話して伝える、に加えて伝えられる側の心構えも。
• どれも興味深い内容だったが、とくに印象的だったのはプレゼンの準備にかける時間のところ。
• そのうち社内で勉強会とかもしたいと思っているので、参考になった。

文書書くときにもCI回そうぜ、って内容。 たしかにしょうもないtypoとかあると記事自体の信頼性に関わるし。

3種類のチェックツールが使用例とともに紹介されている。

Re:VIEWとの併用が前提で書かれているので、このblogに応用するにはMarkdown用に設定変更が必要になりそう。

CircleCI使ったことなかったのであとで試してみよう。 プルリクはCircleCIで拾って、masterマージしたらAzure Pipelineでhugoビルドするようにすれば良いのかな。

https://golangtokyo.connpass.com/event/147175/

• 今回はスマートホームとGoの話です

19:30 ~ 20:00 Go in Nature（仮） by songmu

• Nature Remoの裏側
• gocredits オススメ
  • 依存ライブラリのLICENSEを同梱してくれる
• ecsched気になる
• Websocketでクラウドに接続しっぱなしにしている
• 外部のデバイスからはクラウドに司令を出す
• 常時接続の管理が大変
• ECS上でうごかしている
• Nginxとポート数の問題
  • 接続数が少ないところにつなぎに行く
  • ALBに直接つなぎに行けるようにしたい
• deploy時に接続を切るので、その後一斉に再接続が来る
• Migration
  • goose から schemalex に乗り換えたい
• Dependabot 導入
  • Go対応はちょっと微妙

20:00 ~ 20:30 Nature Remo用のGo API Clientを作った話（仮） by tenntenn

• 完全に対応したGoクライアントが存在していなかったので作った
• swagger見ながら作った
• Dialogflowも使いたい

20:30 ~ 21:00 休憩

• と言う名の懇親タイム

21:10 ~ 21:20 LT1 Raspberry Pi + Go で IoT した話 (仮) by yaegashi

• エッジデバイスでの活用
• クロスコンパイルが簡単
• シングルバイナリ
• 並列処理のサポート
• GPIOの制御
  • pigpioが便利
  • 遅延、CPU負荷が弱点
  • periph.ioもオススメ

21:20 ~ 21:30 LT2 Goを使ったセンサーデータ収集基盤のお話(仮 by takeshinoda

• IoTでGoは便利
  • クロスコンパイル、非同期データ通信制御、デプロイの容易さ
  • 非同期処理と同期処理の混在もOK
• nodeとGo、Goのほうが安心感がある

21:30 ~ 21:40 LT3 Build real world data collecting architecture with goroutine & channel by banana_umai

• pipeline pattern
  • channelで並列にデータ受け渡しをしていくパターン
  • データの順序性、即時性を保ちたい
• debouncing, buffering
  • ネットワークの不安定さに対応できる

Serverless Meetup Tokyo #14 https://serverless.connpass.com/event/143446/

19:10-19:15 Opening Talk 堀家 隆宏 (Serverless Operations LLC. CEO)

• Serverless Daysやるよ

19:15-19:20 会場案内、告知 株式会社Speee

• Good Coffee -> Good COde

19:20-19:40 機械学習MVPにServerless Frameworkがオススメな理由 池田 雄太郎（株式会社 KaizenPlatform）

• 短期的・長期的ダイナミクス
• 短期的：一時的に大量なリソースが必要
• 長期的：やってみないとわからないやつ
• ー＞リソースのスケールが必要
  • ー＞そこでserverless
• Serverlessの悩み
  • ベンダー、性能、セキュリティ、設定・デプロイ
• 使うBaaSが多くなりがち
  • 管理が大変
• DevOps環境の構築が大変
• そこでServerless Framework
  • リソース情報を一括管理できる
  • yaml の custom で定義
  • CFnも書く必要がある？

19:40-20:05 今Serverlessが面白いわけ（v19.09） 川崎 庸市（Microsoft Corporation）

• Serverless != サーバーがない
• Serverless = サーバーを管理する必要がない
• Serverlessの定義
  • スケーリング
  • 管理不要
  • 本質的な作業に集中
• 人類の問題解決
• FaaSはインフラ進化の賜物
  • コンテナ
  • 実行単位が分離されている→セキュリティ有利
  • CGI-Bin？
  • データストアの進化
    • 水平スケール大事
    • NoSQLがマッチしている
  • 進化の方向性
    • 自動化、抽象化、標準化
• 標準化が課題
  • ベンダーロックインの懸念
  • CNCF Serverless WGで進められている
  • Cloud Events
    • イベントスキーマ標準化のための共通仕様
  • 複雑性の抽象化
    • Terraform, plumi
• マルチクラウド化対応
  • K8sベースのServerless環境
  • K8sがインフラを抽象化
  • Knative, KEDA
  • クラスタレス
    • バッチ処理とか
  • Virtual Kubelet
    • クラウドのリソースをK8sから管理

20:15-20:35 AWSで開発するサーバレスAPIバックエンド 三宅 暁（フリーランス）

• AppSync,DynamoDB,Cognito でGraphQLなAPIを作る
• GraphQL
  • スキーマファースト
• Amplify->AWSにロックイン
• Serverless FWにAppsyncのプラグインがある
• VTL＝Apache Velocity Template Language？
• ノンコーディング

20:35-20:40 今日飲み物持ち込んでるエフセキュアのサーバーレス向けセキュリティ 河野 真一郎（エフセキュア株式会社）

• AWS,GCP,Azure向けがまだない。

感想

• Serverless Framework 使ってみよう
• Knative も触ってみよう
• Serverless Days 申し込もう