2020-09-13

elmで和暦パッケージをつくりました

Elm

elmでトイアプリを作っていく上で、西暦を和暦に変換する処理がほしいなとなったんですがパッケージを探しても、ありませんでした。

それであれば自分が作ってみようということでつくってみました。

elm packageの作成手順は以下の記事が参考になります。
The basic steps to publish a package with Elm 0.19 | Korban.net

2020-07-13

集中したいときにおすすめの音楽Youtubeチャンネル

Productivity

ダラダラと作業してしまうことはありませんか？

集中しやすい音楽を流しておくことで、ダラダラせずに集中して作業できるかもしれません。

この記事では、集中しやすい音楽が集まっているYoutubeチャンネルを紹介します。

Greenred Productions - Relaxing Music

www.youtube.com

アンビエント系の音楽が集まっているチャンネルです。

アンビエント系とは？

環境音楽と呼ばれる音楽ジャンルで、リズムが無く、非常にゆったりとしたメロディーが延々と流れるような音楽です。

ノリノリになって音楽に気を取られてしまう、ということがないので集中したい際に非常におすすめの音楽ジャンルです。

Cafe Music BGM channel

www.youtube.com

Monday Jazzなどの様に曜日ごとに用意されたジャズ音楽があります。
ジャズやボサノヴァに特化していて、おしゃれな気分で作業できます。

BGM channel

www.youtube.com

ジャズなどのカフェ系の音楽が集まっているチャンネルです。
朝起きてすぐ、このチャンネルの音楽を流すと非常におしゃれで、
アクティブに活動を始められます！

まとめ

無音の方が集中できる人もいらっしゃると思いますが、
音楽を聞きながら気分を高めることで集中できる人もいらっしゃると思います。

音楽を流して気分を高めるといっても、歌詞がある音楽だとそちらに気を取られてしまいます。

今回は歌詞が無いインストゥルメンタル系の音楽チャンネルを紹介しました。

音楽好きな人にとってBGMは重要なモチベーションにもなるので、気に入っていただければ嬉しいです！

2020-06-20

WebStormのLiveEdit からCORSリクエストできるようにする

Editor

WebStorm の Live Edit で開発している際にクロスオリジンリクエストが以下のエラーで失敗しました。

Request header field x-ijt is not allowed by Access-Control-Allow-Headers in preflight response.

公式フォーラムによると、Allow unsigned requests を有効化すればいい、とのことです。
https://intellij-support.jetbrains.com/hc/en-us/community/posts/115000715304-Problem-with-Chrome-plugin-and-CORS

設定すると問題なく、WebStorm の Live Edit からクロスオリジンリクエストができるようになりました。

2020-05-25

自分の意見を世間と一致させたがる人

Life

自分の意見を世間に合わせている人たちを見ると、何がしたいんだろう？と思います。

炎上したくない？叩かれたくない？

そういう人達って何のために生きてるんでしょう。

自分の意見と世間の意見が食い違えば、自分の過去の言動は無かったことにして、あたかも元々私が考えていたことは世間一般の意見と同じですよ、と言う。

自分が今まで積み重ねてきたことを簡単に投げ出せてすごいと思います。

過去の自分の言動は、日々積み重ねてきた経験や何かしらの理由があって行ったものです。

それを無かったことにして、意見をひっくり返すってことは、自分がしてきたことを否定することに他なりません。

今までの経験を見直して考えを改められることは大切ですが、あまりにも簡単に意見を変える人が多い気がします。

共感が得られて自分が優位になれれば何でもいい、というのにはモヤッとします。

生き方は人それぞれですが、そういう考え方はしたくないなと思います。

2020-04-21

リーダーになるとはどういうことか

Engineering

今月から昇進し、プログラマーチームのリーダーとなりました。
役職付きのリーダーという立場になることは初めてなので、これから意識していくことを書いていきます。

前提

「役職がある = 偉い」訳ではなく、ただの役割であることを意識する。
役職を持っていない人に対して、無条件で指示できるわけではない。

「役職がある = 責任を持つ範囲が増える」ことを意識する。

リーダーに求められること

問題を認知できる
問題を解決するために能動的に取り組む
チームへの問題提議・是正を行える ( 教育含めて )
チームの意見を元に方針を決めて、意思決定ができる
自分が意思決定したことに対して責任を持ち、根拠を説明することができる ( 説明責任 )
自分がわからない部分を上位の役職者に対して質問し、チームに説明することができる ( 質問責任 )

問題を認知できる

問題を解決することよりも、認知する方が難しいと言われています。
１を１０にするより、０から１にすることの方が難しいと言われることに似ています。

リーダーは問題を認知し、チームに共有することが求められます。

問題を解決するために能動的に取り組む

問題を認知するだけでは、何も前に進みません。解決するために自ら行動を起こし、チームを動かす必要があります。

チームへの問題提議・是正を行える

チームの仕事への取り組み方・振る舞いに問題があれば指摘し、改善を促す必要があります。

方針を決めて、意思決定ができる

リーダーは、前に立ってチームを引っ張っていく立場です。チームとしてどこに向かっていくのかを決める必要があります。

自分が意思決定したことに対して責任を持ち、根拠を説明することができる ( 説明責任 )

何の根拠もなく向かう方向を決めてはいけません。
これを実現するためにこの方向に進むんだ。
という理由・根拠をチームに説明する必要があります。

自分がわからない部分を上位の役職者に対して質問し、チームに説明することができる ( 質問責任 )

自分にもわからないからといって放置してはいけません。
自分がわからないのであれば、自分よりも上位の人に質問する必要があります。
そして、その回答を自分の中に落とし込み、チームに説明しないといけません。

まとめ

リーダーになるということをシンプルに表すと、

他人のことを考える必要が出てくる

ということに尽きると思います。

ただのプログラマーであれば、
プロダクトの機能を実装に落とし込み、テストをして、ドキュメントを書き、リリースする
というように、大半が自分で完結すると思います。

リーダーという立場になると開発スキルがあることを前提に、
チームの文化づくり、教育、マネジメント、他職種も交えた全体最適への取り組み
など、自分以外の領域のことにも責任を持つ必要があります。

自分が担当しているプログラミングの領域だけではなく、
自分以外の領域にまで責任を持つことで、
さらに経験を積み、成長していけると思います。

今後も、リーダーという立場からのアウトプットなどをしていければと思います。

参考

最軽量のマネジメント(サイボウズ式ブックス)

作者:山田理
発売日: 2019/11/07
メディア: Kindle版

エンジニアリング組織論への招待　～不確実性に向き合う思考と組織のリファクタリング

作者:広木大地
発売日: 2018/02/22
メディア: Kindle版

2020-03-24

Vuexの前に試したいストアパターン

Vue.js

Vue.jsで複数のコンポーネントを作っていると、同じデータを別のコンポーネントで使いたくなることはありませんか？

まさに先日ちょっとした機能を実装している際に調べたので、ご紹介していきます。

Vuex

真っ先に思いついたのは、Vuex です。

Vue.jsの状態管理ライブラリとしてはデファクト的な立ち位置で、とりあえずVuexを入れておけば大丈夫という印象があります。

ですが、今回実装していた機能はSPAではなく、既存ページに部分的にVue.jsを利用するようなモノでした。

複雑な親子コンポーネントもなく、Vuexでは機能が多すぎるので、もっとシンプルな方法は無いかなーと考えていました。

ストアパターン

Vue.jsのドキュメントを読んでいると、ストアパターンという状態管理の実装方法が紹介されていました。

状態管理 — Vue.js

今回は、兄弟コンポーネントに共通して利用しているデータがあり、それぞれのコンポーネントでそのデータの変更をトリガーにして、APIからデータを取得したりするような要件でした。

複雑な状態操作は行っておらず、データを変更すると処理が１つ実行される程度です。

なので、データの状態だけを管理できればよく、データの操作を統一するような実装は不要でした。

公式ドキュメントでも紹介されていた単純なストアパターンでのデータ共有で問題なく実装が完了し、リリースできました。

実装例

簡単な例でストアパターンを使ってみます。以下のような例題があったとして進めていきます。

AさんとBさんはとても仲良しで、いつも同じ色の服をおそろいで着ています。
３種類の色の中から、どれを選んでもAさんとBさんが同じ色の服を着ているようにしてください。

イメージとしては、こんな感じです。

ストアパターンを導入する前は、このようなコードでした。

<body>
  <main>
   <section id="a">
     <h2>Aさん</h2>
     <ul>
       <li v-for="c in colors">
         <label>
           <input type="radio" name="color-a" v-model="color" v-bind:value="c">
           {{ c }}
         </label>
       </li>
     </ul>
   </section>
   <section id="b">
     <h2>Bさん</h2>
     <ul>
       <li v-for="c in colors">
         <label>
           <input type="radio" name="color-b" v-model="color" v-bind:value="c">
           {{ c }}
         </label>
       </li>
     </ul>
   </section>
  </main>
 <script>
   new Vue({
     el: '#a',
     data: {
       color: '',
       colors: [
         'オレンジ',
         'ピンク',
         'ホワイト',
       ],
     },
   });
   new Vue({
     el: '#b',
     data: {
       color: '',
       colors: [
         'オレンジ',
         'ピンク',
         'ホワイト',
       ],
     },
   });
 </script>
</body>

AさんコンポーネントとBさんコンポーネントがあり、それぞれに色の状態を持っています。

Vue.jsでは兄弟コンポーネント間でのデータ共有はサポートされていないため、Vuexやストアパターンを利用する必要があります。

ストアパターン実装後のコードです。 HTMLに変更は無いのでJavaScriptだけを載せています。

<script>
  // 状態を管理するためのオブジェクト
  const store = {
    color: '',
    colors: [
      'オレンジ',
      'ピンク',
      'ホワイト',
    ],
  };
  new Vue({
    el: '#a',
    // AさんとBさんで同じオブジェクトを利用する
    data: store,
  });
  new Vue({
    el: '#b',
    // AさんとBさんで同じオブジェクトを利用する
    data: store,
  });
</script>

store というオブジェクトを2つのコンポーネントで使うようにすることで、コンポーネント間で状態を共有できます。

まとめ

単純にデータを共有したいだけであれば今回紹介したストアパターンで十分ではないでしょうか？

ストアパターンで実装した後に複雑になってきた場合に、やっと Vuex を導入するか検討する、という流れでもいいのではないかと思います。

とりあえずライブラリを導入するのではなく、必要最小限の機能を実装し、必要になってからライブラリの導入を検討する方が、実装スキルも身につくのではないでしょうか。

2020-03-18

説明する際には相手の前提知識を意識する

Life

相手に何かを説明するときには、相手がどのような知識を持っているかを意識する必要があります。

説明するということに意識が集中して、

相手に理解してもらう

という部分が抜け落ちてしまい、五月雨に説明してしまっていることをよく見かけます。

説明することが目的ではなく、理解してもらうことが目的です。

それを意識することで、相手の反応を見つつ理解してもらえてないようであれば、ここまで説明した内容を理解できていますか？
などと相手の状況を確認でき、補足などをすることができます。

説明するのは大変ですが、自分が説明することを理解してもらうことが目的であり、相手の前提知識を意識できれば、自分本位ではなく相手の立場で考えられるので、説明力がつくと思います。

2020-03-01

AWS CLIでのEC2 起動時のUnauthorizedOperationエラー

AWS

AWS CLI で aws ec2 run-instances コマンドを実行した際の UnauthorizedOperation エラーの解決方法です。

実行したコマンド

$ aws ec2 run-instances

エラー内容

An error occurred (UnauthorizedOperation) when calling the RunInstances operation: You are not authorized to perform this operation.

エラーメッセージ全体

An error occurred (UnauthorizedOperation) when calling the RunInstances operation: You are not authorized to perform this operation. Encoded authorization failure message: tpNG4Ag3__Co44EMHx-vIkiZHCEGsJXC5WKyizyBzLUqbeLeeTRqDOPoOKB7hkdIpQSxBf2TBSfDgWKLUB5Ra7XAlq1e5ctNRyxcLkvA7kDs4b1CxVah5Yo3IxafEU5KQAD2uN5sHeCwZe2sd4IJUZkOiSNv_w_dSUfOUihgQ80_CJtpb1_lB6vxKRbd7XWAmsLspeun1Q7L3rJJCS8Y0BTVKlKXPDMOIhpjc--cYLsB1MZ0ZCq178BNgFKzv747Ky4NgN4VRUywI1MYiLy9uWzeKc_wGgLM2mJ6JJB8hBvAHprbKQin_J1tuuINAnF85gvFkY6-ieBZ5slajmW69m6WbzqF3ylx50YF9bj_JMDHJtMBVFvT9jgXJz9UDJJVok_D_Lh1oH8A-dC123n9_dDAJrQmo7QZ4oTAQJmP8MBSFvjHRhAEu7Ed4GpKXZyFZPk-IFORkRACNB1a-Wdm3CaYr4-wA8Icu-0g4Vw4BTvnVPlK8Z3MXE4nuIXJivrUh6LvMgftJRqzYWAPaZnL9uM5oLmhlG4OxYQI6e01UYUqf9kanyDQtrVQipEXGnDZQA

原因

起動する EC2 にインスタンスプロファイルを設定していたが、iam:PassRole 権限が無かった。

解決方法

AWS CLIを実行するIAMユーザーのポリシーに iam:PassRole の権限を付与します。

補足

エラーメッセージの Encoded authorization failure message: 以降に出力されている文字列はエンコードされているので、
aws sts decode-authorization-message コマンドでデコードする必要があります。

参考

2020-02-26

GitHub OrganizationsでGitHub Actionsを利用しようとした際のPermission Error

GitHub Organizations で GitHub Actions を利用しようとした際に発生する
Only actions in "hoge-organization" are allowed for this repository
の解決方法です。

エラー内容

Only actions in "hoge-organization" are allowed for this repository

原因

GitHubの該当リポジトリのページ > Settings > Actions > Actions Permissions を確認してください。

Enable local Actions only for this repository が選択されている場合、 3rd PartyのGitHub Actions は利用できません。

対応

以下のどちらかで対応可能です。

GitHub Actions 内の 3rd Party の Action定義を削除する
- GitHub Actions 初期テンプレートなら actions/checkout@v2 の部分
Actions Permissions を Enable local and third party Actions for this repository に変更する

2020-02-25

PHPのincludeとrequireの違いについて

PHP

PHPで外部モジュールを読み込む際に利用する
include と require の違いを解説します。

include と require の使い分けまとめ

指定したモジュールが存在しない場合の挙動が異なります。

include の場合、Warning になりスルーされる。
require の場合、Fatal error となり処理が終了する。

外部モジュールを読み込んだ後の処理が、外部モジュールに依存しているかどうかによって使い分けましょう。

依存していない場合は include、依存している場合は require です。基本的にはrequireでいいかと思います。

include と require の実際の挙動を検証してみる

以下のコードを実行して、実際の挙動を確認してみます。

<?php

include('foo');
require('bar');
echo 'Hello';

$ php index.php
Warning: include(foo): failed to open stream: No such file or directory in /Users/shootacean/github.com/shootacean/sandbox/php/include-require/index.php on line 3

Warning: include(): Failed opening 'foo' for inclusion (include_path='.:') in /Users/shootacean/github.com/shootacean/sandbox/php/include-require/index.php on line 3

Warning: require(bar): failed to open stream: No such file or directory in /Users/shootacean/github.com/shootacean/sandbox/php/include-require/index.php on line 5

Fatal error: require(): Failed opening required 'bar' (include_path='.:') in /Users/shootacean/github.com/shootacean/sandbox/php/include-require/index.php on line 5

includeでは、Warning となりますが、次の処理へ進むのでrequireが実行されます。
requireでは、Fatal error となり処理が終了するので、echo 'Hello';は実行されません。

ビジネスロジックのコアな部分の外部モジュールを利用する際などには、
requireを利用することでモジュール読み込み時点で致命的なエラーに気づくことができます。

ビュー層などの致命的な問題にならない箇所では include でいいかと思います。

以上、PHPの include と require の挙動の違いについてでした。