はぜにっき

日記です。（毎日更新ではない）

生活リズムを正しい方向に持っていく

雑記

はぜです.

先月微妙に忙しかったり色々あったりで睡眠時間がバラけたり土日昼寝しまくってたりで, なんとかしていきたいという話.

6:50起床  
→  
朝ごはん作ったりシャワー浴びたりコーヒー飲んだり本読んだりインターネットしたり  
→  
準備  
→  
出社(8:30~)


→  
退社  
→  
晩御飯作って食べる  
→  
インターネットか本読む  
→  
22:00に風呂  
→  
音楽とか聞いたり静かに過ごす  
→  
23:00 寝る

こんな感じで生きていきたい. 最近は6時台に自動的に目が覚めてけど8:00ぐらいまで布団から出られない. とてもつらい.

hazediary.hateblo.jp

先日バリスタも買ったことだし, 朝にパン焼いてコーヒー飲みながらゆっくり買った本を読む時間を作りたい. 最近本を読むペースが落ちてきているのをなんとかしたい.
ということでうまく生きていくための方法を考えていきたい

指定の時間に音楽をかける

基本的に家にいるときは音楽をかけっぱなしにしているのだが, 4月に入ってからは寝るときは消すようにしている.
これをスイッチとして, 6時40分〜50分ぐらいから自動で音楽を流すようにすれば起きやすくなるのではないかという考え.

自動で流すのは, iMacを指定時間に自動で起動するように設定して, Automatorで起動時にitunesの音楽を再生するようにした.
PCを落とし忘れた時が最悪だが, 最近は毎日消して寝ているのでなんとかなるだろう.
落とさなくても指定時間に再生する機能があるのなら教えてほしい.

どうでもいいけど, 朝になったら機械が自動で色々動いてくれるの近未来感があって良い. バリスタの起動とか電気周りとか風呂とか全部自動で動いて欲しい.
俺...お金いっぱい稼げるようになったら電気をHueにしたりタイマー付きの良いバリスタ買ったり風呂が指定時間に自動で湧いてくれる家に引っ越すんだ.......

コーヒー / 食パン

買ってからは毎日朝にコーヒーを飲んでいる. 割と良い.
ネスカフェは結構好きで, UCCとか他のその辺に売ってるやつよりは全然うまいと思う. 次点でカルディ.
全然詳しくないので基本的に飲み比べとかはできないし高いコーヒーの味とかわかんないけど気にしない. ネスカフェはブラックでも美味いしこれでええんや.

食パンはかなりの頻度で買い忘れるので気をつける. 今日も買い忘れたのでさっき買ってきた.
健康診断で引っかかって以降, ほとんど米を食べていないけど割と健康. そろそろラーメンを減らさないといけない.

運動

なんてことはないただの運動不足. 先月はほとんど運動もしていなかった. というか秋〜冬の終わりまでは全く運動しなくなる. 良くない.
最近は少しずつ暖かくなってきていて, 運動をするようになってきた.

先週末は少し走ったり自転車で横浜まで行ったりした. あとカラオケ. カラオケは運動.
この調子で毎週1回ペースぐらいでちゃんとした運動をしていきたい.

上記以外にも寝られるように23時超えたらスマホの通知全部消したり とか シャワーじゃなくてちゃんと風呂に入るとかできる範囲でやっていきたい.
目的としては 本を読む時間を増やしたい / 布団にこもる時間をなんとかして減らしたい / 健康になりたい とか.
精神的につらくなってきた時に生活リズムが崩れているとぶっ壊れるので, それをなんとか回避したいというのもある.

がんばっていきていこうな

「LINE Pay APIによる決済機能を実装しよう」勉強会に行った

Enginnering

はぜです. いつもの雑な日記です.

【東京】LINE Pay APIによる決済機能を実装しよう というLINE Payの勉強会に行ってきました.

内容としては,

  • LINE Payの仕組みや概要の説明
  • Web上でLINE Payを実装する
  • Bot上でLINE Payを実装する
  • 懇親会

といった感じでした.
かなり細かい説明してもらいつつ, 参考のQiita記事を眺めながら進められたので特に問題なく実装ができました.

以下は自分用のメモです.

決済の流れ

  • 1: 決済予約

    • ユーザが決済手続きを始める動きをした際に行われる
    • サービスプロバイダがLINE Payに決済予約を行うリクエストを送信する
    • そのレスポンスとして, 「トランザクションID」と「決済URL」が返却される
    • トランザクションIDは, その決済手続き一つを表すためのIDで, 決済URLはその決済手続きをユーザが行うためのURL

  • 2: ユーザの決済承認

    • サービスプロバイダがユーザに決済URLを渡し, リダイレクトするとかしてそのページにアクセスをする
    • LINE IDによるアカウント認証を行い, 決済の承認を行う（＝PAY NOWボタンを押す）

  • 3: 決済の実行と通知

    • ユーザによる決済の承認が行われると, LINE Payに承認したことが通知される
    • その際に送られるトランザクションIDを元に, 承認したトランザクションを特定し, サービスプロバイダに決済が行われたことを通知をする

テスト用のアカウント

  • 実際に決済を行うことができるようにするには「加盟店登録」が必要
  • この辺の手続きは飛ばしているのでわからない.
  • テストとして決済を行いたい場合, 開発用の環境が欲しい場合はサンドボックスを用意することになる
  • LINE Pay Developers : Sandbox creation

実装する上での気をつける点

  • nodeのバージョンが古いと動かないことがある
  • （ハンズオンでは）環境変数で設定するCHANNEL ID, SECRET, CONFIRM_URLは当たり前だけど間違えないこと
  • サンドボックス生成時に設定するIPアドレスも間違えると死ぬ. 2桁ずつ入力欄が分かれているためコピペしづらい
  • トランザクションIDは消失すると最悪なので気をつける.

所感/感想

仕組みとしてはかなりシンプルで, 実装が簡単.
LINE上で何か取引をする上では間違いなく最高の選択肢になるかとは思うが, Web上ではどうかはわからない. どうであれ楽に運用できるような仕組みはなっている
実際使う際の加盟店登録がどれだけ面倒臭いか, 登録に当たっての条件や制限事項によって実用性は大きく変わりそう. ひとまずやってみないとわからない

初めてherokuを使ったが, クラウドサーバとサーバレスの中間ぐらいのものでとても良い. 適当にサクッと物を作る時には最高っぽい.
色々ぐぐりながら何ができるかを調べる

LINEはセミナールームが綺麗でよかった.

LINE Community lab なる, 個人orチームで数ヶ月ぐらいでLINEを使ったアプリケーションを作るプロジェクトみたいなものが立ち上がるらしく, 面白そうなので参加しようと思っています.

おわり

フロントエンドの知識が全くなくてつらい

Enginnering

はぜです.

hazediary.hateblo.jp

ちょうど一ヶ月前に

「ホームページを作れるようになろう」と「Javascriptから始めるお手軽プログラミング」を3月末までには終わらせたい.

とか言っていたが全く進んでいない.

Twitterでは言い訳をしている.

今はReal World HTTPを読んでいる. 知らないことが多くて面白い.

haze-page.tokyo haze-page.tokyo を多少それっぽくした.
中学校の頃にFC2ホームページでサーバ（？）借りてHTMLを書いていたのを思い出した. 懐かしい. 削除しといてよかった.

背景写真は近所で咲いていた桜を撮ったもの. その時々で変えたくなったら変えます.
最寄駅が結構花見スポットになっているっぽくて, 家族連れの人たちとかが昼間にわいわいしているのを眺めて平和な気持ちになっていた.

最近仕事でもそれ以外でもJavascriptを書くようになり始めていて, せっかくなのでちゃんと理解しようと思って書籍を買った.

初めてのJavaScript 第3版 ―ES2015以降の最新ウェブ開発

初めてのJavaScript 第3版 ―ES2015以降の最新ウェブ開発

これより以前に出ているJSの本は闇に近いらしく, これだと比較的最近の「嫌いにならないJavaScript」を学べるらしく激推しされた.
実際かなりわかりやすく, 付録のコードの変数名が日本語で書かれているところ以外はとても良いと思う.

非同期処理がデフォルトの言語を触るのが初めてだったことがありそこそこハマったりしたが何とか理解することができた.
async/await がとても良いと思った. 早く全ての環境がES2016対応になってほしいところ.

[追記]

背景画像がくそみたいに重かった（Lightroomで編集し終わったやつをそのまんま表示していた）ので品質を落とした.
あと, nginxの設定で include mime.types; を入れておらずCSSが読み込まれない現象が起きて10分ぐらい悩んだ. 無知すぎる. つれえ.

雑記 ( つらみ編 )

雑記

ここ最近良くない方向に考えが行きやすくて困っている........つらい...人生とは.....

ここ最近, 仕事面でもそれ以外の面でもあまり上手く行かないことが多くて凹むことが多い.
だいたい自分の能力不足が原因だったり, 精神的に弱いところが露出しているだけっていうのを自覚してしまうのがつらいところ.
助け舟を出す先がないんだけども, 元々そういう生まれというか, そういう生き方を選んでしてきたのでどうしようもないかなあと.

ひとまず出来ることは, 自分が潰れない程度にやることをやりつつ, 地道に技術を身につけたり知識を増やしたり, 考えをまとめたりして一歩一歩進んで行くということなので.
死にたくならない程度にやっていこうと思います.

雑記 ( 買い物編 )

雑記

ネスカフェゴールドブレンド バリスタ TAMA レッド SPM9633R

ネスカフェゴールドブレンド バリスタ TAMA レッド SPM9633R

天気も良いし, 軽く走るついでに近所のブックオフとかドンキを散策していたら, このバリスタが新品1980円で売っていて思わず買ってしまった.
友達の家で飲んだことがあって, 美味しいし, （カプセルより）コスパ良いからいつか買おうと思っていたのでよかった.
毎朝起きたらこれのスイッチを押してコーヒー飲んでから生活することになりそう. QOLが結構上がる. 嬉しい.

何買うか悩みながらツイートしたら著者の方々から圧力のRTといいねとリプが飛んできて焦った. 今年の前半中に全部買って読みます. たぶん.

とりあえず以下のものを買った

最初に Real World HTTPを読んでいる.
サンプルコードが主にGoで書かれている. Goの本と一緒に買ったのは正解だったっぽくて, これ読み終わってからGoの本を読めば一気に理解ができそう.

この3冊を読み終わったら次はカイゼンジャーニーとSRE本だろうか. どっちも内容が最高に濃いようなので時間を掛けて読みたい（SREは物理的にでかいし文量もとんでもないので大変っぽい）

バリスタ買ったブックオフにMacbook Air Mid 2013 / もりもりタイプが綺麗な状態で4万円台で売っていて即購入.
付属品全て付いて, 充電回数28回！ めっちゃ当たり引いた. あと2年戦える.
外に持ち運ぶ用のMacbookを買うかずっと悩んでいたので歓喜している. それ用のお金置いといてよかった.

シールについての考えは以下の通りです.

普段お世話になっている/興味を持っているツール類を少しずつ貼っていきたい. GCPとか.

「試して理解 Linuxのしくみ」 読んだ

Enginnering

はぜです.

[試して理解]Linuxのしくみ ~実験と図解で学ぶOSとハードウェアの基礎知識

[試して理解]Linuxのしくみ ~実験と図解で学ぶOSとハードウェアの基礎知識

読みました.

自分について

買おうか悩んでいる人向けに参考程度ですが, 自分の情報を書いておくと

という感じです. 所謂「スーパーマン」ではない.
プログラミング自体には長く触れているが, 「がっつり」ではない. ゆるふわエンジニアです.

自宅サーバはこの前破棄しちゃったのでmacで可能な限り試した. 他に動いている処理が結構あるので正確な実験ではないだろうけど, まあ良いでしょう.

以下, 各章ごとの自分用メモと簡単な感想

1章 コンピュータシステムの概要

  • アプリケーション, ミドルウェア, OS, ハードウェアの繋がりの話
  • なぜ「ドライバ」が必要なのか？
  • ユーザモードとカーネルモードの話

大体知ってた. そうだねーっていう感じで軽く読み飛ばし.
文章も図もまとまっていてわかりやすい. 人に説明するときに参考にしたい.

2章 ユーザモードで実現する機能

  • OSの機能とかプロセス発行をしたいときはシステムコールを使ってカーネルモードで処理をするんだよっていう話
  • strace を使ってHello,World!を表示するときにどんなコールが呼ばれているかを確認
  • sar コマンドでユーザモードとカーネルモードのどちらでプロセスを実行しているかを確認する
  • システムコールのラッパー, OSが提供するライブラリとプログラムについて

strace コマンド初めて知った. すごい. よくわからない
無限ループでシステムコールを使う処理を回した時の実験は, 思ったよりuser率高いなーという感想.

3章 プロセス管理

  • fork()について

    • 子プロセス用のメモリ領域を作る
    • 親プロセスのメモリ領域を子プロセスのメモリ領域にコピー
    • 親と子が別々の処理として動く

  • execve()について

    • 実行ファイルを読んで, その内容を実行中のプロセスに上書き
    • 実行
    • プロセス数は増えない.
    • readelf でコマンドの開始アドレスを見る

  • 実行時に生成されたプロセスのメモリ情報（マップ）は /proc/[pid]/maps に書き出される

  • プログラムを終了するには _exit() システムコールが使われる

いわゆる fork と exec の話.
forkはすぐイメージできるけど, execは別プロセス化して動くっていうのがなんとなくイメージ付きづらいところがある.

4章 プロセススケジューラ

  • taskset ... 指定したプログラムを指定したCPU上でのみ動作させるコマンド

  • 複数のプロセスを1CPUで同時に実行させた時の進捗度合いを実験する

    • 一定時間ごとにプロセスが順番に切り替わっていく（コンテキストスイッチが発生する）ことを確認
    • 実行が完了する時間はプロセスが増える分に比例して増えていくことを確認

  • 実行状態, 実行待ち状態, スリープ状態,　ゾンビ状態について

  • アイドルプロセス: 何もしないことでCPUを休止状態にし, 消費電量を抑えた状態にするプロセス

  • スループットとレイテンシについて

    • スループット: 実行完了プロセス数/経過時間
    • レイテンシ: 実行完了時間 - 実行開始時間

  • 複数CPUでの複数プロセス同時実行　

  • nice(): 優先順位
    • 優先順位を下げることは誰でもできるが, あげるのはroot権限持ちユーザのみ

プロセスの実行順序と掛かる時間についてのお話.
頭の中では理解しているが, 実際にグラフを見ると面白い. 実際こんな綺麗に結果が出てくるものなんだなーと思った.
macの上にvagrant/virtualboxでCentOSを立ち上げてやってみると, 書籍に書いてあるほど綺麗ではないがそれっぽい挙動を見ることができた.

5章 メモリ管理

  • free コマンドでメモリの状態を見る
  • OOM Killer 「君はたぶんいらない子」

  • 仮想記憶の仕組みを用いない単純なメモリ割り当ての問題点

    • メモリの断片化
    • 割り当てられた領域以外の領域へのアクセス可
    • メモリの断片化によるプロセスのメモリ配置ができなくなる問題

  • 仮想記憶について

    • プロセスから見えるアドレスを仮想アドレス, 自裁のアドレスを物理アドレスと呼ぶ
    • ユーザが物理アドレスを確認する方法はない: 見れたら他の領域へのアクセスが可能になるかもしれないので
    • カーネルが使うメモリ領域の中にある「ページテーブル」で管理する
    • もらった領域の外にアクセスしようとするとSIGSEGV（ページフォールト）が発生してプロセスは強制終了される
    • 追加割り当てはプロセスが要求(mmap)すれば, 対応するページテーブルを作成して仮想アドレスをもらえる

  • ファイルマップ

  • デマントページング

    • 領域を確保したが, ユーザに使われなかった領域が出た場合に他のプロセスにその領域を割り当てる機能

  • 仮想メモリ, 物理メモリの枯渇

  • forkの高速化

    • forkシステムコール実行時には親プロセスのメモリを全てコピーするのではなく, ページテーブルのみをコピーする
    • どちらかがメモリ上への書き込みを行おうとした場合にはページフォールトが発生し, 新しく物理ページが用意され書き換えられる
    • コピーオンライト(CoW)と言う

  • スワップ

  • ヒュージページ

    • ページテーブルの中身が増えてくるとforkシステムコールが遅くなる
    • ページテーブルを階層化して一度で見なければならない範囲を減らすことで高速化する
    • トランスペアレントヒュージページという, 仮想アドレス空間内の連続する4KBのページを良い感じにヒュージページにしてくれる機能があるけど使わない様にもできる

普通に知らないことが多くて良い. デマントページングとか初めて聞いた.
OOM Killerとかswapとかは仕事でサーバ削減をしていたときに結構気を付けていたので知ってはいたが, ぼんやりした理解だったので確認.
ちゃんと理解して使えるようになりたいと思う反面, この辺を真面目に意識してプログラムを書く機会ってそんな無いよなあ と思ってしまう.
メモリを極力使わないようなコードを書くとか, メモリ領域に合わせて使う分を考えてとかはやると思うけど. 忘れないようにしたい.

6章 記憶階層

  • レジスタ
  • メモリキャッシュ
  • メモリ

  • ストレージデバイス

    • の速度の話

  • キャッシュメモリの話, 階層型の話

  • 参照の局所性

    • 時間的局所性: アクセスされたデータは近いうちに再びアクセスされる可能性が高い
    • 空間的局所性: 次にアクセスされるデータは, 前回アクセスされたデータの近くにある可能性が高い

  • Translation Lookaside Buffer

    • ページテーブルを参照して, 仮想アドレスを物理アドレスに変換する処理を高速化するための領域
    • 詳細はぐぐる

  • ページキャッシュ

    • ストレージ上のファイルデータをメモリにキャッシュする.
    • ダーティページの説明
    • open()でファイルを開くときにO_SYNCフラグを立てると可能な限り同期書き込みをする
    • vm.dirty_writeback_centisecs パラメータでダーティページのライトバックを行うタイミングを変更できる
    • /proc/sys/vm/drop_caches
    • ハイパースレッド

プログラムの高速化, ISUCONでよく考える系の話. fujiwaraさんの資料がとてもわかりやすくて良い.
http://isucon.net/archives/50648750.html

Translation Lookaside Bufferとハイパースレッドがよくわかってないので調べてまとめたい
/proc/sys/vm/drop_cache は仕事でお世話になった.

7章 ファイルシステム

  • 雑に言えばファイル名/場所/サイズ のリレーションを保管しておいてくれるもの
  • ユーザモードで ファイル名, ファイルのオフセット, サイズ を指定しシステムコールを発行すると, カーネルモードでストレージに行って読み出してくれる

  • Linuxはファイル名の部分をディレクトリを使ったツリー構造で保管

  • データ: 文書, 画像, プログラムなど

  • メタデータ: ファイルの名前とかストレージ上の位置, サイズなどの補助情報

    • df コマンドで表示されるストレージ使用率はデータ＋メタデータの総量

  • クォータ: 用途ごとにファイルシステムの使用料を制限する機能

    • ユーザクォータ: ユーザごとに容量を制限する. ext4とXFSで利用可
    • ディレクトリクォータ: ディレクトリごとに容量を制限する
    • サブボリュームクォータ: ファイルシステム内のサブボリューム単位ごとに容量を制限する. Btrfsで利用可

  • mvコマンドによるファイル移動の流れ

    • mv /bar /foo
    • foo -> bar リンクを貼る
    • / -> bar リンクを削除
    • 〜完〜

  • リンクを貼り終わった瞬間に電源が強制的に切られた場合, 二箇所からリンクが貼られた不整合な状態となる

    • マウントで検出したらマウントができなくなる, アクセス中に検出すると読み出し専用モードでの再マウントorパニック

  • シャーナリング

    • ファイルシステム内に, ユーザに認識できないジャーナル領域というものを用意する
    • 更新処理の一覧を書き出す（ジャーナルログ）
    • その内容に基づいてファイルシステムを更新する
    • 更新が完了したらジャーナルログを削除する

  • 更新中に強制断が発生した場合, ジャーナルログを最初から再生することで処理を完了させることができる.

  • コピーオンライト

    • コピーオンライト型のファイルシステムとそうでないものがあり, コピーオンライト型のものは Btrfs など.
    • ファイルを更新するごとに別の場所にデータを書き込むというもの. ext4やXFSは同じ場所に書き込む
    • 更新処理は, 更新された後のデータを別の場所に全て書き込んでから, リンクを張り替える処理となるため, 途中で死んでも作りかけのものを削除すれば大丈夫

  • 不整合で死んだとき: バックアップを戻す or fsck で直す

    • fsckは復旧のためにファイルシステムを全て見るので, システムが大きいとめっちゃ時間かかる
    • 失敗する確率もそこそこある
    • 望んだ通りに復旧する可能性がそんなに高くない（あくまで不整合を直すだけなので）

  • デバイスファイルについて

    • Linuxは大体のデバイスをファイルとして認識している（ネットワークアダプタは例外）
    • デバイスファイルは, 以下の二つに分類される
      • キャラクタデバイス: 読み/書き ができるもの. マウス, キーボード, ウィンドウなど
      • ブロックデバイス: 読み書きに加え, ランダムアクセスが可能なもの. HDD, SSDなど

  • tmpfs

  • ネットワークファイルシステム

    • いわゆるnfs.

  • 仮想ファイルシステム

    • procfs: プロセスの情報を得るためのもの. /proc以下. maps, cmdline, stat など
    • sysfs: カーネルのプロセスに関係しない情報を置くためのもの. /sys以下. devices, fsなど
    • cgroupfs: cgroupの情報が置かれている. rootのみ使用可

  • Btrfsについて

    • ext4, XFSと異なる部分の紹介
    • マルチボリューム, スナップショット, RAID, データ破損検知と修復機能などがある

この章が一番知らないことが多かった.
journal ってそういう意味のものなのね... というのがこの本読んでの一番の驚きだった. プロセス死んでるときに見るためのログとしか理解していなかった.
普段あんまり意識していないなーという気持ちで読んでいた. 各ファイルシステムのこと(ext4とかXFSとかBtrfs)もある程度は理解しておくべきなんだろうなあ

第8章 ストレージデバイス

  • HDDのセクタ
  • I/O スケジューラについて
    • ブロックデバイスへのアクセス要求をある程度溜めてからアクセスする仕組み
    • 連続するセクタへのアクセスを一つにまとめる, 不連続なセクタへの要求を番号順に並べることで性能を高める

  • 先読みについて

    • ストレージデバイス内のどこかにアクセスした際, 同時にその周りの領域を先に読んでおく機能
    • 空間的局所性
    • 読んでおいたところにアクセスが来なかったら捨てる

  • HDDとSSDの違い

    • SSD: アームもないし回転もしない
    • 比較的高い
    • ランダムアクセスだと差は顕著

基本情報技術者の午前試験思い出した. 懐かしい
HDDはどう動いていて, SSDはどう動いているのかを大雑把にでも理解しておくと, I/Oを考えるときに良いと思う.

数日で, 多少実験しながら読んだ.
覚えるというよりも, 正しく理解するための書籍で, 実験も面白くて良い.
学生のときに読みたかったな. 4月に入ってくる新人の人に貸してあげたりとか, プログラム書いたことあるけどインフラ系触ったことないような人に勧めてみても良い本なんじゃないかなーと思った.

一年半で17kg太ったら案の定健康診断に引っかかったので生活習慣を改めていく

雑記

雑記です. タイトル通り.

新卒で東京に来てから, 飲み潰れないのを良いことにひたすら酒を飲み続けたり, つけ麺750gとかラーメン大盛りとかを頻繁に食べていたらめっちゃ太りました.
元がやせ細っていたので17kg太っても標準体重 (BMI21.2) なのが逆に恐ろしいところですが.

まあ特に冬場の間はずっと引きこもりつつ, 毎食1~1.5合の米を食べ続けていたので引っかかって当然です.
酒は今年に入ってからはかなり減って, 自炊もしているので米は多いけど野菜は食べている.

引っかかったのは「HDLコレステロール」と「中性脂肪」です. 両方 脂質代謝 の欄.
善玉コレステロールが基準値をギリギリ下回っていて, 中性脂肪は大幅に基準値を超えていてかなりよろしくない感じになっています.

脂質代謝以外はほぼ全て基準値ど真ん中なので, 生活習慣さえ改めれば健康そのものに戻れると思う. がんばる.
暖かくなってきたしロードバイクで都内ふらふらするのも再開できそうだし, 米を食べたくなるのを我慢して野菜を食べまくっていこうと思います.

雑にdeployツールを作った

Enginnering

https://haze-page.tokyo/ のデザインをいじって遊ぼうかと思っていたんですが, 直接htmlいじったりscpとかrsyncを毎回するのも面倒だなーってことで,
Goの勉強ついでにデプロイツールを自作してみた.

github.com

README.mdに書いてある通りなんですが, 使い方.

  1. デプロイしたいリポジトリに移動する
    f:id:hazeblog:20180310170944p:plain

  2. コマンドを叩いて y を押す f:id:hazeblog:20180310171150p:plain

おわり.

初めてcloneするリポジトリ( = 指定したディレクトリにファイルが存在しない) は, ディレクトリ無いけどcloneするか聞いてくれる. f:id:hazeblog:20180310171550p:plain

ただ, 初めてGitHub等にアクセスする場合に聞かれる, The authenticity of host 'HOSTNAME(***.***.***.***)' cant' be established. は突破できない. 作るのはすぐできるけど確認めんどくさい
他にもいくつか制限事項みたいなところはあって, 詳しくはREADMEを読んでください. 使いたい人そんないないと思うけど.

そのうちテストコードを書きたい. 書き方を調べたけどめんどくさそうだったのでやめてしまった. 良くない...

SIerからWebへ転職するということ / 日記

雑記

はぜです. ちょっとお酒を飲みながらブログを書いています. 氷結って美味しいよね. STRONGじゃない方.

自分は去年, SIerからWeb系に転職していて, 何となく気持ちはわかるのでコメントした.
SIerに居る時にWeb系の人にちゃんと評価されるようなアウトプットを出すことはかなり難しい.
理由は色々あって, 致命的なところを言うと

  • アウトプットと言うと, 「誰かに使ってもらえるレベル」「顧客に納品できるレベル」のものを想像してしまう

  • プログラミング(実装)軽視の考え方の人間が周りに多く居て, 相談できる相手が居なかったり, やっていることを否定されることが多い

  • アウトプットを出したとしても転職しなければ仕事に活かされることがない

全員がこれに当てはまるわけではないけれども, 「SIerに居てWeb系にぼんやり憧れを抱いている」人はだいたいこの辺で詰まっていると思う.
どれも厄介なんだけど, 一番最後が正直最悪で, "転職をするためにアウトプットを出す" という感覚になりがち.
で, 自分の満足した条件で転職するのであればそれなりにちゃんとしたアウトプットを出さないといけない...と思って, 年数を重ねるごとに要求レベルが勝手に上がっていって出られなくなる.

こういうパターンで転職を諦めた30代が沢山居て, そういう人たちをちゃんと反面教師にできれば良いんだけど, 成功例は近くに居ないからモチベーションが続きにくい.

だいたいこんな感じでずるずるとSIerに残り続ける人が多いんじゃないかな, と思っている.

正直なところ, この状態で30代に突入したとしたらかなり絶望的, 転職して新卒の頃と同じぐらいの給料で...ってなっちゃって転職せずにコンプレックスを抱いて精神をやられるような人も居る.
自分がこの人に対して掛けられることはコメントに書いたことぐらいしかないし, ハードルを極限にまで下げてとりあえず動くしかないと思っている.
「年収下げてでもやりたいことじゃないってわかってよかったね」っていう人も居るけど, このコンプレックスはそんな軽いものじゃない. SIerで仕事をしている というある種の劣等感が消えることは基本的にない.

...
まあここまで書いておいてあれだけど, ブコメ返しに書かれている経験を見る限り多分普通に自分のアピールが苦手なんだと思う. 転職してガクッと下がるようなレベルの仕事しかしていないようには見えないし.
全くのゼロ評価になってしまっている というのは, 単純に自分のやってきたことが伝わっていないだけなんだろう. 難しいもんだ.

最近今まで触ったことのない技術に触ることが多くて, 頭が追いつかない感じもありつつ, 楽しいなーって日々を過ごしています.

「これはできるようになりたいなー」って思っているが順調に増えてきていて, 頭がパンク気味. つらい. プライベートの時間は毎週意識的に取るようにはしているんだけど, 多少自分の頭のコントロールができなくなってきているような気がするので, ちょっと落ち着きたい.

Twitterを見ていて, 全く知らない技術とか, 理解できていない用語が流れるたびに多少焦りが出てくることが昔からあって, その感覚が少しずつ強くなってきている.
こういう時はだいたい現状に満足できていなくて, 自分を責める方向に行きがちな性格なので無理して動いちゃう. よくない.

なんというか, まとまりの無い話しかしてないけどいいや.

Actions on Googleハンズオン参加した

Enginnering

gdg-tokyo.connpass.com

はぜです. Google Japanいってきた.

...

Google Home

日本での発売後すぐに購入したGoogle Homeくんですが,
- ChromecastにYoutubeの動画を飛ばしてもらう
- Google Play Musicで音楽を流す
- 声でエアコンを付けてもらう/消してもらう

といった感じで使っていた.
アシスタントの活用は正直あんまりやっていなくて, なんか使い道ないかを探ろうとしたところハンズオンがあったので行った感じ.

内容は
- Actions on Google / Google Asisstantについての説明
- Dialogflowについての説明
- ハンズオン
- Forkwell(懇親会のスポンサ)の宣伝
- 懇親会
だった.

内容を後にまとめる.

Actions on Googleについて

資料

Google Assistant

  • Android, Google Home その他諸々に入っている「アプリケーション」

  • 使命は "声, 文字列, 写真(Lens), 他 を認識して, 文字列に変換すること". およびその逆.

  • これがあることで, 関連アプリの開発者は 受け取った文字列をどう処理して, どう出力するか だけに集中することができる

Actions on Google

  • Actions on Google = Google Assistantと直にJSONを投げ合うことでアシスタントを拡張する仕組み全体のことを指す

  • AlexaだとSkillをデバイスに追加することで拡張機能が使えるようになるが, そういうのは特に必要がない. Google Homeを買ってきたばかりの人でも他人が作った拡張機能をすぐ使える. 便利

Dialogflow

  • Google Assistant等からもらった文字列に対して, どんなレスポンスを返すかを GUIで作れるGoogleのサービス ( GCP ).

  • 文章の解析やってくれる, 文字の揺らぎもある程度は認識してくれる, 学習させたりもできる. すごい

  • 外と通信して, 別サーバから文字列データを引っ張ってきたりもできる.

ハンズオン

 Google Assistant
       |
 DIalogflow
       |
 Cloud Functionsで作った, [https://blockchain.info] に飛ぶやつ
       |
 blockchain.info

Google Assistantに良い感じに話しかけると, ビットコインの価格とか数とかを教えてくれるアプリケーションを作った.
node.js は初めて触ったが普通になんとかなった. めっちゃ読みやすくて驚いた.

皆がハマっていた ハマりそうだったポイント

  • exports.[関数名] = (req, res) => { ... }

    • 関数名はデプロイ時に同一でないとエラーで死ぬ.
    • gcloud beta functions deploy [関数名] -source [ソースがあるディレクトリ] --trigger-http
    • エラーで code=3 っていうのが目に付いちゃうのがあんまり良くない気がしないでもない. なんやこれ ってなる
    • Not Found Function: [デプロイしようとした関数名] ぐらい直球に書いて赤文字にしてくれたりすると嬉しい

  • Dialogflowの Action 欄の名前とコード上の名前を間違えると死ぬ

    • さっきと同様, 大文字小文字問題
    • ハンズオンだからハマるだけで, 実際自分で名前付けてたらそう間違えることないような気がしないでもない

  • app.tell(msg)

    • tell() だと一回一回アプリが閉じる. 毎回アプリを開いてくれってお願いしないといけなくなる
    • ask() を使うと会話してくれる. 他にもあるんだろうか. ドキュメントを探す.
    • 教えてくださった方ありがとうございました

こんな感じでした.
すぐにスマホのGoogle Assistantアプリで実際に使えるっていうのが作った感が出て良いですね.
使い方色々, 発想次第で便利なものをサクサク作れそうで良い仕組みだなーと思いました.
Dialogflowは特に, Assistant以外とも連携ができる. Slackと連携してチャットで色々できるようにしたい. 時間が空いたら作ってみよう.

懇親会も色んな人と話が出来てとても楽しかったです. ピザ一枚も食べれなくて帰り道死にそうだった.

あと, 六本木ヒルズには数回来たことあるんだけど毎回迷う. 森ビル自体の入り口も何個かあるし, 方向間違えたらショッピングモールに入って出られなくなる. 矢印ついた看板が欲しいです. よろしくお願いします.