簡単にメモを取れる環境を作ってみる

簡単にメモを取るために使ってきたATOK Padが、MacOSをSierraにアップデートしたら全く入力を受けつけなくなってしまった。
実はATOK Padを使っていたときからいろいろ試して来たのだけど、これを気に一新してみることにした。

wri.peに登録する

今回はATOK Padの代わりにwri.peを使ってみることにしました。
サイトの説明にもある通り、シンプルな構成でショートカットキーも備えているのが良い。

wri.pe

GitHubアカウント(Facebookアカウントでも可)でSign inするだけなので楽ちん。

Fluidでアプリにする

次にFluidというアプリを使ってwri.peをアプリにする。

fluidapp.com

サイトからダウンロード・解凍したのちに、アプリケーションの下にでも移動させる。
で、Fluidのアプリを起動するとこんな感じのダイアログが出るので、URLに https://wri.pe/app を、Nameは wri.pe としてCreateする。

f:id:shibukk:20160926152101p:plain:w400

これでアプリケーションの下にwri.peのアプリができます。

アプリの設定を変更する

で、このままだとwri.peを起動してもログイン認証でブラウザに遷移してしまうのでちょっと変更。
wri.peを起動 → メニューにある Preference (⌘ + ,) → Whitelist から Allow browsing to any URL をチェックすればOK。

f:id:shibukk:20160926152115p:plain:w400

これで無事ログインできるはず。

f:id:shibukk:20160926152908p:plain:w600

うめのんさんのブログで書いてあったように、自分にとってwri.peが気持ちを乗せてくれるアプリに感じたので、これでいろいろ書いていきたいと思います。

おまけ

コピペでテキストを貼り付けた場合に、シングルクォートが勝手に変換されてしまうが、
システム環境設定 → キーボード → ユーザー辞書 → スマート引用符とスマートダッシュを使用
のチェックを外しておくと変換されなくなる。
なので気になる人はチェックを外しておくといいです。

NTTフレッツ光の初期設定をMacからWifiでする

表題ですが、NTT東日本「フレッツ 光ネクスト」 でWifiの設定をしようとしたところ、簡単セットアップツールがWindowsしか対応していなかった&MacBook Airしか手元になかったため、かなりハマってしまいました。
どうやって設定すれば良かったか共有として残しておこうと思います。

工事完了の確認

NTT東日本の工事が完了し、ルータにSC-40NE2という無線LANカードアダプターが刺さった状態となっているか確認してください。
無線LANカードアダプターにあるACTとPWRのランプが点いていればOKです。

契約書の確認

NTT東日本と契約をした際、プロバイダ(niftyとかのことです)とも契約をしていたと思いますが、そのプロバイダから封筒が届いていると思います。
まずはそれが手元にちゃんとあるか確認してください。

Wifi接続の設定

Macの場合、「システム環境設定」→「ネットワーク」よりWifi接続の設定ができます。
f:id:shibukk:20160918233236p:plain:w550

Wifiを選択すると「ネットワーク名」を選択できるので、そこからルータのラベルにある「SSID-1」を選んでください。
するとパスワードを聞かれるので、ルータのラベルにある「暗号化キー1」の内容を入力してください。
f:id:shibukk:20160918233253p:plain:w350

これでWifiの設定は終了です。
ブラウザから http://flets-east.jp/ のページにアクセスすると表示されますが、それ以外のサイトは見れない状態になると思います。

ルータパスワードの登録

次に、ルータにパスワードを登録します。
まずブラウザから http://ntt.setup/ にアクセスします。
するとパスワードの登録が求められるので適当なパスワードを登録してください。
これがルータのパスワードになります。忘れないようメモを取っておきましょう。

ルータの接続先設定

NTT東日本のサイト等ではパソコン自体にPPPoEを登録するような記載があったりしますが、新し目のMacBook ProなどではLANケーブル自体が繋げません(Ethernetアダプタが必要)。
なのでルータに設定することにします。

先ほどアクセスした http://ntt.setup/ に再度アクセスします。
すると名前とパスワードが求められるようになります。
f:id:shibukk:20160918235021p:plain:w350

名前には 「user」を、パスワードには先ほど設定したパスワードを入力してOKを押してください。
これでルータの管理画面に入ることができます。

ではルータの管理画面より接続先を設定しましょう。
プロバイダから届いた封筒の中に「接続ユーザー名」と「接続パスワード」が入っていると思います。
これを接続先の設定に登録します。ちなみに接続先名は@niftyとか適当で問題ありません。
f:id:shibukk:20160919000057p:plain:w550

これで設定は全て完了しました。yahooなどにアクセスしてみてちゃんと表示されるか確認してみてください。
以上、お疲れ様でした!

paiza会たのしい

今日は会社のエンジニア何人かで集まって「paiza会」をした。
ルールはこんな感じ。

  • 主催者がpaizaから問題を1問ピックアップ
  • 選択する言語はRuby限定
  • 参加者がRuby経験者ではないことを踏まえ難易度はランクD
  • 一通り出来たらみんなのコードをリーディング

もともとは初めてのRubyを輪読していたのだけど、参加者的にも輪読は向いていない気がしていた。
なのでもくもく会とかに形式を変えてほしい旨をお願いしたところ、paizaの問題を解くというのを考えてくれた。
実際に手を動かすのはすごく楽しいし、みんなのコードを元にシンプルな回答が生まれる過程はとても気持ちがいい。

新しい言語に触れる最初のステップとしてpaiza会はすごくいいと思うし、もっと広まってほしいなぁ。

責任ってなんだろう

今考えていることを残しておいたほうが良い気がしたのでつらつらと書きます。

責任ってなんだろう。
たとえば今の会社では自律型の組織を目指しているんだけど、自分が言い出したことは必ずやり遂げるってことが責任を持つということ?
じゃあ出来なかった場合は責任を持てなかったってことになる。
でも、一生懸命頑張った結果できなかったのだったとしたら、さぼってた訳ではないし責任感はあるよね。
ということは責任を持つ≠責任感がある?とかいろいろ考えてしまって結局よく分からなくなる。

そう考えると責任を持つという言い方が曖昧で目標を持つと言ったほうが良いんじゃないかな。
頑張った結果達成できなかったのなら、「責任感がなかった」ってなるより、「目標に対しての努力の仕方が良くなかった」とか「そもそも目標自体が間違っていた」とかって考えたほうが健全な気がする。

リーダーとして、デザイナーや他職種に対して「俺はその職種じゃないから分からない」って言ってしまうのは本当に最低なんだけど、責任っていう曖昧な言葉があることが原因なんだろう。
メンバーに目標を設定してもらって、それに対して正しく努力しているか、は自分でも出来そうに感じる。
んで、KPTを回していくと。現時点ではそれが良さそうに思っている。

Slackの投稿をLambdaを使ってElasticSearchに流し込もうとした話

はじめに

今年もやるよ!AWS Lambda縛り Advent Calendar 2015 の14日目の記事です。
というか間に合わなかったという記事です。本当にすみません!

やりたかったこと

Slackでナレッジがどんどん流れていってしまうあるある、よくありますよね。
というわけで、Elasticsearchにテキストを投入して、少しでも検索しやすくしてナレッジを拾いやすくしてみたいなとひらめきました。

Elasticsearchを使うメリット

Slackでも日本語検索はできます。
でも、Elasticsearchにテキストを投入すれば、こんなことが出来るようになります。

  • N-グラムの利用
  • kuromojiによる日本語形態素解析
  • 英字の大文字・小文字、半角・全角などの統一

AWSを使うメリット

AWSの無料枠にはAmazon Elasticsearch Serviceが追加されています(t2.microのみ)。
また、デフォルトでkibanaがインストールされていたり、kuromojiをサポートしていたりします。
つまり、無料でかつそんなに苦労せずSlack検索機能をつくれるのでは?ということです。

というわけでさっそく作っていきましょう。

Elasticsearchの設定

クラスメソッドさんの記事をそのままコピるだけでOKです。超簡単!

dev.classmethod.jp

Lambdaの設定

大量の会話データを毎回送信してしまうとLambdaの無料利用枠を超えてしまう可能性があるので、今回はSlackのOutgoing Webhooksは使わずに、LambdaのScheduled Eventを使います。
と、その前にLambdaでfunctionを作りましょう。

Slackの会話データを取得するにはhttps://slack.com/api/channels.historyを、Elasticsearchへのデータ登録は先ほど作成したElasticsearchのURLを使います。

SlackのWebAPIで取得したデータを整形してElasticsearchにhttpでインサートしていきましょう。
bulkインサートにするためにjsonを整形する必要があるので注意してください。

言い訳

ここで気づいたと思うのですが、この記事、画像とかソースとか一切載っていません。 というかKibanaでの確認もできていない有様です。
マジで間に合わないためこんな仕上がりになってしまいました…。
Advent Calendarを書きたかった方もいらっしゃったかと思うと本当にすみませんとしか言えないです。

画像とかソースとか揃ったらQiitaに必ずアップします! f:id:shibukk:20151225231139j:plain 本当にすみませんでした。

Mackerelから見た、サービスの思想と機能について - DevLOVE関西#102

devlove-kansai.doorkeeper.jp

今回もDevLOVE関西主催のイベントに参加してきました。
というわけで、@daiksyさんや@Posauneさんの話を通じて、サービスの思想についての僕なりの気づきを書いておこうと思います。

Mackerelの思想と機能

Mackerelというサービスの説明は、エンジニアをワクワクさせる『直感的サーバ監視サービス』となっています。

今回あったMackerelについての話を振り返ってみると、公式ブログやニュースレターにリリースを毎週欠かさず告知することで、今週はどういう機能が追加されたんだろう?と期待させたり、エンジニア心をくすぐるmackerel-agent-pluginsなどの拡張機能や、監視設定自体をコード化できるといった機能を次々と追加したりと、ワクワクさせる仕掛けがいろいろありました。

そして、それらの機能が直感的に導入できるよう、コピペするだけで動くように作られていると。
実際に導入デモをやっていましたが、5分くらいで動いていました(!!)。

つまり、Mackerelの全ての機能は説明にある一言に沿っているかどうかを基準に実装されているようです。
ちなみに、ユーザーの要望を取り入れるかどうかは、その機能がワクワクするかどうかを基準に考えるみたいなことを、質疑応答の時間で@daiksyさんが言っていたような気がします(自信ない)。

思想を一言で表す

こうやってサービスの思想を一言で言い表すことで、チームが目指すべきユーザーに与えたい価値がはっきりするし、その価値に共感するユーザーが集まる構図になりますよね。 また、サービスの思想に対してある程度の市場規模があるかどうかをあらかじめ調べておくことで、そのサービスがスケールするかどうかも見えるんじゃないかなーと思いました。

以上、DevLove関西運営のみなさん、今回もめっちゃいいイベントありがとうございました。

「レビュー」をもっとうまくやってみる - DevLOVE関西#93

devlove-kansai.doorkeeper.jp

DevLOVE関西主催の勉強会にまたまた参加してみました。というわけで遅くなりましたが書き起こしを。
個人的なメモかつだいぶ忘れてしまっている内容なので変なところも多々あると思いますがご了承ください。

シナリオレビューの紹介

登壇者:森崎修司(@smorisaki)
名古屋大学 大学院情報科学研究科 准教授

レビューの効果

テストのタイミングで確認して修正するとなると遅い
なのでレビューのタイミングで確認したほうがもちろんいいよね

ただし…
テストの工数が削減できるという観点のレビューでないと意味ない

じゃあどういうレビュー内容がテストの工数を削減できるのか?

レビューのアンチパターン

  • 一部だけしか見ない
    インデントはスペース4つで統一してください。とか
  • 人格攻撃
    こんなのもわからないなんてエンジニアとしてどうなんですか?とか
  • 説明会とか進行がおかしい
    ではこれから説明会レビュー会を始めます。お手元の資料を…とか

ではどうしたらいいか

レビューの準備

レビューの準備に必要なことは、レビュー前に適切な目的を設定し合意しておくということ
具体的には「問題種別の抽出する」と「検出シナリオを決めておく」(後述)
これらをみんなで合意することが一番大事!

レビューによる問題の検出

事前に設定した問題種別に沿って検出する
→どこをどうチェックしたかは予めチェックリストを作ることで明らかにしておく

レビュー技法

Defect-based reading Perspective-based reading

Defect-based readingとは

漏れ・曖昧・誤りの3つの観点でレビューを実施する技法
ちなみに漏れ(一番難しい)

  • 漏れ
    検討漏れ
    →そもそも検討ができていない場合がある
    あなたにとっての「常識」とは?
    →使う人にとっての常識を定義する
    ドキュメントを読んでしまうと先入観が入ってしまう
    →ドキュメントを読む前にソフトウェアのあるべき姿を想像して望む

  • 曖昧
    読み手にとって複数の解釈ができてしまうものは、読み手の想定や定義が必要となる

  • 誤り
    外部や内部で定義されたドキュメントやコードの不整合が原因であることが多い

Perspective-based reading

そもそもテスターはテストを実施できるのか?
のようににテスター・発注者・利用部門・プログラマそれぞれの立場で考えてレビューを実施する技法

シナリオレビュー

レビューの目的を共通認識として持つ
レビューの効果に応じて濃淡をつける
指摘は網羅性を確認する
(この辺駆け足だったのでメモできず…)

ワークショップ

その1
http://www.miyazaki-ac.jp/?action=cabinet_action_main_download&block_id=100&room_id=1&cabinet_id=1&file_id=1140&upload_id=3180
これをレビューして問題になりそうな箇所を5つ挙げて下さい。

問題種別の設定方法

トップダウンの例

「グローバルで使われる案件ワークフローシステム」について考えてみる
→どこが一番価値のある品質か
 →システムが停止しては困る
 →大容量ファイルを処理できる
 →日次処理に影響が出ないようにする

システムの停止の際に原因が分かるようにするとか
大容量ファイルは処理時間がどれくらい掛かるかとか複数アクセスされた場合どうなるかとか

つまりレビューで何を見るべきか、また何が大事かはそのシステムにとっての価値で決める
それを決めるのがシナリオである

ワークショップ

その2
http://www.city.matsusaka.mie.jp/www/contents/1340350276686/files/120188-3.pdf
このシステムにとっての価値を順位が高いものから5つ挙げて下さい。

まとめ

ワークショップは3人1組でやったのですが、その1ではレビューの観点がバラバラだったのが、その2では価値順位も含め、かなり近しい観点にまとまりました。
その価値順位に対してお互いが合意してからレビューをすれば、かなりいいレビューとなりそうです。

あとレビュー本すごく良さそうでした。