渡り鳥の旅路

元半導体系エンジニア、今Webエンジニアの雑記

WEBエンジニア勉強会 #06に参加してきた

勉強会 Web

勉強会に参加してきたので復習用メモです。

web-engineer-meetup.connpass.com

WEBエンジニア勉強会の特徴

  • 若手エンジニア向けに役立つ内容
  • 言語に偏らない汎用的な技術について学べる
  • 発表初心者でも登壇しやすい雰囲気

ハッシュタグはこちら↓

#WEBエンジニア勉強会06 hashtag on Twitter

またこの勉強会の主催者がどんな思いで勉強会を始めたのか、しがないラジオのsp.6a, bで聞くことができます。

shiganai.org

今回の会場は渋谷にあるココラブルさんのオフィスです。 勉強会はまるで秘密基地のようなかっこいい部屋で行われました。

アイスブレイクは会場を提供して頂いた@ariarijpさん

@ariarijpさんはRedashのコミッター兼Redash Meetupの運営者でもあり、 この勉強会の事前アンケート結果もRedashで表示して見せてくれました。

発表とメモ

CSVと戦うためのPandas by @ariarijpさん

一発目の発表は引き続き@ariarijpさん

「Redashで扱うDB用データの前処理をPandasでやってみたよ」というお話でした

PandasはCSVなどのデータソースをデータフレームにして使う

->行や列の抽出、各要素への関数適用など、Pandasを使うとデータ分析に必要な前処理などが簡単にできる。

今AidemyでPandasを触ってるんですが、前職でエクセルで前処理していたのを思い出すと泣きそうになるくらい便利です　笑

はじめてのサーバーレス関数 by @engineer_oscaさん

サーバーレスとは？

作成したアプリをデプロイすると、サーバーの存在を意識せずにいい感じに動かしてくれる

  • サーバーを管理する労力を削減できる
  • 負荷に応じていい感じにスケーリングしてくれる
  • アクセス量だけのミリ秒レベルの課金
サーバーレス"関数”とは？

サーバーレスの仕組みの上で動かす、入力と出力が明確な小さな機能のこと。APIやトリガーなどに利用

サービス例
  • Azure -> Azure functions
  • AWS -> Lambda
  • GCP -> Cloud functions
特徴

　ものにより使用言語、課金単位、時間制限が異なる

　時間制限があることから、バッチ処理は想定していない

どんなときに使う？
  • HTTPリクエスト
  • タイマー起動
  • DBの更新トリガー
  • ファイルストレージの更新トリガー
  • GitHub webhook

OSCAさんの個人プロジェクト：WEBクローラ関数の実装

->指定したURLのサマリを取得する関数をデプロイ

　->個人ニュースサイト製作に利用

デプロイツールはApache Mavenを利用

メリット

無料枠が大きい、越えてもやすい、コード書くだけ

注意点

PCが動いた分だけ課金される。間隔を開けるとPCの起動時間が必要になり、初動に時間がかかる

まとめ

クラウド移行のファーストステップとしてどうでしょう？

API仕様管理フレームワーク「Swagger」 by @ykaganoさん

speakerdeck.com

SwaggerをREST APIのお仕事が楽になるよ、というお話でした

使い方
  • Swagger editorを利用
  • yaml形式でAPIの仕様を書く
swagger yamlにかけること
  1. メタデータとサーバー情報の記述
  2. エンドポイントの記述
  3. モデル定義の記述

.

  • APIのモックをオンラインで作るのはセキュリティ的に不安

　->オフライン版があるよ

  • レスポンスを変えるには？

　->yamlを編集 or serviceフォルダのjsを編集

さらに

REST APIのソースコードにアノテーションを記述して ソース=ドキュメントを作ったりできるが、yamlでそこまでやると運用コストがでかいので状況とご相談

WEBエンジニアのための転職術 〜転職と採用の経験から〜 by @yuhei_kondoさん

３０歳まで未経験からIT業界のキャリアをスタートして色々経験した上で思ったこと、というお話でした。

採用者目線での話もあり、転職活動する上でこういうこと気を付けるべき注意点が参考になりました。

  • 自走して技術を身に着ける
  • 一つの現場に依存しすぎない
  • 受ける会社からみて自分に価値があることを示せるか

ゼロから始めるPWA入門 by @__syumaiさん

speakerdeck.com

PWAを使って色々やってみたよ、というお話でした。遊び心があるデモ付きで、聞いてて楽しい発表でした^^

PWAとは？
  • ウェブの良いところ

　手軽、更新が楽、データが軽い

  • アプリの利点

　オフライン可能、プッシュ通知、動作が軽い

　　->PWAならアプリの利点をウェブで実現できる

事例

Twitter lite, Instagram(画像のフィルターをすべてJSで作っている！)

PWAの構成要素
  • Service worker (一番大事)
  • Cache Storage
  • Web App Manifest
開発ツールについて
  • Chrome Dev Toolが最強

　Youtubeに詳しい動画がある！（Google社員がアップ） 　Totally Tooling Tips with Addy Osmani & Matt Gaunt - YouTube

  • Lighthouse(Chrome拡張)

表も裏もTypeScriptでWebサイトをリニューアルした話(タイトル変更) by @zuckey_17さん

しがないラジオパーソナリティずっきーさんの発表でした。

SPAで作っていたしがないラジオWebページをサーバサイド/フロントともにTypeScriptで書き直したときの経験をシェア、というお話

なぜやったの？
  • OGPタグのみSSR
  • 音声マネージド・サービスからの脱却

参考ブログ↓

note.mu

  • watch_severもwatch_clientで変更を検知

  • type.d.ts：型定義を共通化

　->実はサーバサイドとフロントで使いたい型が違い、結局分けた

全リソースぶっ壊し回避のためのterraform構成 by @3s_hvさん

speakerdeck.com

しがないラジオsp.17aに出演されていたWeb系インフラエンジニアのVTRyoさんの発表

この一年Terraformを触ってきて感じた便利な点や大変だったことのお話でした。

Terraformとは？

AWSなどのリソースをコード管理できるツール

コード化されたインフラのメリット
  • 人為的ミス回避
  • 工数削減
  • インスタンス落とし忘れ回避
大変だったところ
  • 書ける人が少ない

　インフラ寄りの人はあまりコードを書かない

  • リソースが再作成

　tfstateファイルの管理ミス。。

　　->terraform.tfstateファイルは重要！

  • 元々管理しづらいディレクトリ構成になっていた

　メンテしやすくしたよ！

まだテーブル定義書をエクセルで書いて消耗してるの？ by @nabedgeさん

タイトルは煽り系ですが、最終的にはイイ話に収束していました　笑

テーブル定義書を自動生成して運用コストを下げたよ、というお話 （Dockerはイイぞ、というお話も）

  • DBフルートを利用（JavaのORM）
変わるものと変わらないものを見極めてツールをチョイスしよう
  • RDBSはあまりかわらない
  • ”CREATE TABLE HOGEGOGE”は変わらない
  • ツールは変わる
テーブル定義書はある方がいい
  • インデックスと外部キー制約、ユニーク制約の存在までわかるやつ
  • ER図もあるほうがいいけど、なくてもいい

　->ShemaSpyっていうER図作成ツールもあるけど。。

Docker / docker-composeは覚えておくと良い
  • 異なる言語環境を必要とするツールをどう扱うか？
  • すべてdockerコマンドで動かせるようにしておけば、どこでも動く
  • ローカル環境としての利用
  • 使いたいものに合わせて公式イメージを探そう

OSCAさんコメント： 最初はエクセルでDB定義するが、 運用になったら実DBをマスターとして管理をするなどフェーズにより使い分けた方が良い

打ち上げ

近くの飯屋にて。コミュニティ運営の話とか色々

次回

5/18 (金) Yahoo! Lodgeにて

lodge.yahoo.co.jp

【初参加】We Are JavaScripters! @17th【初心者歓迎LT大会】に参加してきた

勉強会 JavaScript

最近仕事でJSを触り始めた＆前から気になっていた勉強会だったので参加してきました。

今回初参加だったのですが、お題目の通り経験浅めの方が発表しやすい雰囲気を保ちつつ、ベテランの方が初心者向けにかみ砕いた発表をしていたのが印象的でした。

こういう勉強会だと独学だけでは自分のアンテナに引っかからないテーマや、次に手をつけるのにハードルが高すぎないテーマが見つけられるのでありがたいです。

wajs.connpass.com

ハッシュタグはこちら

#wejs hashtag on Twitter

LTとメモ

LT0: メルカリスポンサーLT

会場スポンサーのメルカリさんのLTがあったそうなのですが、僕は遅れて行ったため聞くことができませんでした。

LT1: チームをCQRS @boiyaaさん

speakerdeck.com

このLTの途中から会場入りしました。

元々のエンジニアの職務として、

  • フロントエンド：UI作る
  • バックエンド：データ操作

という分け方をしていたが、 フロントエンドがクライアント寄りのサーバサイドを触るなど仕事の幅が拡張している。

そこらへんの定義を再考して見た方が良いよね、といった話でした。

LT2: 【ビギナー枠】フロント未経験者のReactプロダクト改善 @shikicheeさん

speakerdeck.com

Ubieが提供する病院の受付サービスについて

MBAでサービスデプロイしてから軌道に乗る手前で、 サービス拡大のためにどうプロダクトを改善していくかという内容でした。

  • 元々はブラウザ対応だったが、ブラウザ環境ならではの課題が見つかる

　（例）ボタンの押し間違えやすさなど

  • 技術的負債の解消

　- ESlint, prettierの導入

　- 業界標準をきちんと選定しつつ

　- 今後入ってくるであろうデザイナーが関わりやすいようなツールの選定

  • 得られた知見

　- Webでネイティブアプリっぽい動きをさせるのは大変。うまく行きそうだったら、すぐにPWAやアプリに置き換えよう

  • 技術の移り変わりが速いので参考記事は一年以内のものを選ぼう

LT3: new version of context in React 16.3 @sottarさん

speakerdeck.com

react v16.3 本日リリース

Reactのこと知らな過ぎてよくわからなかったのですが、 New context APIの話でした　笑

参考記事

medium.com

動画もあった

What's New in React 16.3.0 - YouTube

LT4: What is necessary for developer friendly UI? @kuwahara_jsriさん

speakerdeck.com

APIコールを利用した連鎖的UIのバッドサンプルのお話でした。

Riotのことはよくわからなかったので、ReactやVueと比較しつつ調べてみようと思います。

LT5: ForkwellスポンサーLT

できるエンジニアになるために、 社内評価と市場評価のギャップをどう埋めていくかが大事だよねというお話

  • 社内評価 > 市場評価：技術をつける=>勉強会等で発信していく
  • 社内評価 < 市場評価：コミュニケーションとって自分ができることを見える化

時間がないあなたにスカウトサービスあるよ！で締め。

LT6: 【ビギナー枠】Vuetifyで学んだVueのコンポーネントあれこれ @10tomok0さん

  • Vuetify：海外ではVueのOSSフレームワークで一番使われている

  • スライドアップされてないけど、今回の内容は技術書典4で頒布予定とのこと

  • チュートリアルややってみた系の記事だけでは実戦投入するまで至らない=>フレームワーク自体のソースを読む

  • PWA Beginners 勉強会 #3 - connpass

LT7: HyperappでMarkdownエディタを作って薄い本を書きたい @atsucoさん

speakerdeck.com

  • JS製超軽量ライブラリのHyperappでmdエディタを作ったお話

  • 開発環境はWebpack

  • Hyperappの良い点=>シンプル、JSXが使えるので見通しが良い、etc.

  • 詳しくは技術書典4で！まだ書けてないけど！

LT8: Osushiに見るフロントエンドのセキュリティ（仮）@shibe97さん

speakerdeck.com

先日のOsushi炎上=>復活までのお話でした。

めちゃくちゃつらい体験をしたはずなのに、笑いを交えつつその経験をシェアできる強さやそれを受け入れるWeb業界の文化が良いなぁと思ったり。

セキュリティの話もそうなんですが、一度炎上を経験した後の選択の仕方や復活させるまでのストーリーの作り方が参考になりました。

React本をだしたが事情により宣伝できず。。

  • 攻撃の数を減らす

Devtoolハック

  • 攻撃を防ぐ

セキュリティ系ヘッダー

　- X-frame-options

　　Iframeでサイト丸ごと表示させて、攻撃側の誤クリックを誘発する

　- X-xss-protection

　- X-content-type-options

関連記事 devcentral.f5.com

  • 被害を最小限に抑える

　- そもそも取られるものをなくす

　　=>可能な限り個人情報をAPIで返さない

LT9: 【ビギナー枠】継続的 npm update のために実践していること @codenote_netさん

speakerdeck.com

  • Tokyo otaku mode：スタックが全てJS

  • 毎日npm updateしてる？

　- npmローカルモジュールを活用：azuさんの記事が参考になる

　- ローカルモジュールを使えば新旧バージョンを共存させることができる

　- ライブラリ自動アップデートサービスの例：Greenkeeper.io, Dependabot

LT10: WASMとES modulesの話 @chikoskiさん

資料はアップされてないので関係ありそうなツイートをてきとうに貼る　笑

  • Web Assemblyはバイナリ製のモジュール

　C, Rust, 裏にLLVMを持っているkotolin などで作れる

  • モジュールとは？

　- 表、すなわち名前と値でできている

　- スコープもモジュールの一種とも言える

  • WASMはESと違って手動でインスタンス化しないといけない

　- Webpackで楽をする->頑張って開発中

　- ブラウザでインポートできるようにしようよ！と言い出した（少し先のお話）

次回

次回は4/24にリクルートにて

まとめ

完全に自分用勉強リストになっている。。

「コンピュータはなぜ動くのか」を読んだ

学習メモ

きっかけ

先日rebuild.fmの#127/#128を聴いていて、連続でパフォーマンスチューニングの話題が上がっていました。

rebuild.fm rebuild.fm

最近それなりにコード書くのも慣れてきたし、そろそろパフォーマンスのことも考えられるようになりたいなと考えていたところにこの話題。

show noteにおススメの書籍として「コンピュータの構成と設計」があがっていたので出版社のページをみたところ中々分厚い感じでヒヨる。。

ec.nikkeibp.co.jp （電子書籍なら上下合本番があるのでそちらがお得です！）

というわけで、ウォーミングアップとしてまず「コンピュータはなぜ動くのか」から読んでみました。

ec.nikkeibp.co.jp

目次

第1章　コンピュータの3大原則とは

第2章　コンピュータを作ってみよう

第3章　一度は体験してほしいハンド・アセンブル

第4章　川の流れのようにプログラムは流れる

第5章　アルゴリズムと仲良くなる7つのポイント

第6章　データ構造と仲良くなる7つのポイント

第7章　オブジェクト指向プログラミングを語れるようになろう

第8章　作ればわかるデータベース

第9章　簡単な実験7つでTCP/IPネットワークを理解する

第10章　データを暗号化してみよう

第11章　そもそもXMLって何だっけ

第12章　SEはコンピュータ・システム構築の現場監督

こんな人向け

この本は学生の時に情報系じゃないけどIT系の仕事に就いた人向けに、 各ジャンルの最初の一歩の知識をやさしく紹介している本です。

また自分みたいに促成栽培的に仕事を始めた人が、まだ手を付けてないところの雰囲気をつかむときに必要な章をつまみ食いする読み方がおススメです。

読書メモ

自分はこの本のうち1-6、9-11章を読み進めました。

1-6章に関しては元々大学でC言語で挫折したクチなので、低レイヤーの言語の話（機械語やアセンブラ）を知っておきたいなと思い通読。

あとネットワーク周りも全然わかってないので、やりとりするデータの話も含めて9-11章を読みました。

オブジェクト指向やデータベース周りは実務で触ったり別で勉強したことがあったのでこの本ではスキップ。

オブジェクト指向は「オブジェクト指向でなぜつくるのか」が歴史的背景含めて書いてあり、概要をつかむのに良いと思います。

ec.nikkeibp.co.jp

あとは実戦で意識しながら使い続けないとなかなか腹落ちしないかなと。。自分もまだまだ修行中です。。

データベースはがっつりはやってないので、どこかのタイミングで勉強したいところ。

出版が10年以上前なので話題がちょっと古いところはありますが、そこは必要に応じて流していけばいいかと思います。

まとめ

とりあえずウォームアップ完了ということで、次は「コンピュータの構成と設計」へ

分量的に重い感じなので、まずはさらっと読んでいこうかと思います。

Ruby on Railsもくもく会@新橋に参加してきた（はじめて）

勉強会

最近Rails触りたいなー、と思ってたので参加してきた。

教材

定番中の定番、Railsチュートリアル railstutorial.jp

事前準備

Railsチュートリアル上ではCloud9かホストPCへの環境構築について書いてたけど、 ローカルで仮想環境作っとくと楽だよねってことでDockerにコンテナ立てた。

もくもく会は午後からだったので、午前中にこの記事を見ながらさくっと環境構築

とにかく簡単にDockerでRuby on Railsを動かしてみる(初心者向け) - Qiita

最後のlocalhost:3000で"このサイトにアクセスできません"エラーが出る。。

ちょっとググッてみて、下記記事を参考にIP確認して無事繋げた。

dockerで立ち上げたアプリケーションにアクセスできない - Qiita

第１章

Herokuへのデプロイはスキップ 今までCakePHPとLaravelのチュートリアルしか見たことなかったけど、 RailsチュートリアルはGitやテスト・本番環境へのデプロイについても触れていて良いな～と思った。

第３章

実はテストコードを書いたことなかったので、こういう手順ですすめるのか～と新鮮に思いながら粛々と進めた。TDD

まとめ

もくもく会中はRailsの習得に注力したかったのでデプロイ部分はスキップしたけど、 家で進めるときはちゃんとやろう。

チュートリアルの最初からコードをきれいに保つ重要性など書いてあり、 Railsエンジニアのコードの綺麗さへのこだわりはこう言うところから始まっているのかと感じるなどした。

【スタテク読書会】「Linux標準教科書 ver2.0.0.」を読もう#2 に参加してきた

前回に引き続きスタテクさんのLinux読書会に参加してきたので、そのレポートです。

今回も雑談駆動の勉強会でした　笑

  前回の様子はこちら↓ roo-ashi.hatenadiary.com

 

 

課題図書

今回はLinux標準教科書（Ver2.0.0）の第3,4章が事前課題でした。 （実際は話が飛んで5章の範囲までやっちゃいましたが。。^^;）

メインパート（質問からの雑談）

Q1 正規表現のおススメ勉強法

これは僕の質問です。 grepの検索条件で正規表現を使うのですが、以前業務で正規表現に苦しんだことがあったので何か良い勉強法がないかなと思って聞いてみました。

（回答いろいろ）

  • 実際のところベテランでもたまにしか使わないので、都度調べながら対応している。
  • お題を決めて練習する(電話番号、メールアドレスなど)。 ググってみたら正規表現のドリルがありました。
  • 正規表現チェックツールを使う。 正規表現チェックツールまとめ - Qiita
  • 言語ごとに表現が違うので、それぞれのリファレンスを見に行く。
  • 正規表現は手続き型言語とは違うことを念頭におくと良い
  • 範囲を選ぶときは、ASCIIコード表が指定する順番に注意

いつの間にかログの話題に派生して、tailコマンドのオプションの話になってたり。。

Q2 Linuxの効率的な勉強法

Linux勉強してると今どの辺まで理解できているかよくわからない、という意図だったと思います。

（回答いろいろ）

  • 全体感を把握するなら、LPICの本を見ると網羅的な知識が整理されているのでよい。試験は高いので仕事で必要なときだけ取ればいいのでは、とのこと　笑
  • コマンドリファレンスを一気読み ->コマンドが何となく頭に残っているだけでも、発想力が違ってくる。
  • Linuxを要らないPCに入れる業務を通して覚えた->やってみると気にするべきところがたくさん見えてくるので勉強になる（セキュリティとか）
  • Gitのリポジトリの共有設定の話->Gitサーバー - Gitosis
  • まずはオープンソースの環境構築を立ち上げてから、アプリケーションを作ってみるのが良さげ
  • 環境構築で使うコマンドは意外と少ない

Q3 パスを通す、とは？

前回のブログに書きました↓ roo-ashi.hatenadiary.com

Q4 ログの見方について

さらっと見るときにはlessコマンド等でチェックするが、分析等するなら環境用意してツール使った方が良いというお話でした。

（回答いろいろ）

  • 基本的にはgrepで自分が見たいログがあるかを検索して、lessで確認する。
  • データとして扱うときはログ収集ツールを使う。->fluentdとか
  • elasticsearchやkibanaといったちゃんとした基盤にに入れると便利

Q5 意外と知らないけど知っておくと便利なコマンドシリーズ

  • -vを入れるとコマンドに対するフィードバックが帰ってくる。
  • !$にはコマンドを打った最後の結果が残る。例えばmkdirした直後にcd !$と打つと作ったディレクトリに移ることができる。
  • cd -で一つ前にいたディレクトリに戻る。OLDPWDという環境変数に一つ前のPWDが保存されているのでそれを見ている。
  • readlink -f (シンボリックリンクのパス)とするとシンボリックリンクのリンク先を確認することができる。

まとめ

今回は（も？）読書会でありながら教科書をほとんど開かない感じで進みましたが、質問を起点として話題が縦横に広がるとても勉強になる回でした。今回初耳で消化しきれてない話題がたくさんあったので、これから少しずつ調べていきます。

次回は3/24 (土) 開催予定とのことです！

パスを通す ～WindowsとMac OS X / Linuxの違い～

昨日のLinux読書会でふと疑問に思ったので調べてみた。

元々は別の参加者の方が「パスを通すってどゆこと？」という質問をされていたんだけど、そういえばWindowsを使っていると毎度パスを通す作業があるのでMacと比べて面倒くさいな、とふと思ったのが発端。

普段Windowsでソフトインストールしたときに環境変数にパスを設定すると思う。 例えばGitだとこんな感じで細かくパス指定している↓

C:\Program Files\Git\cmd

でもMacとかでPath変数の中身を確認してみるとこんな感じで浅いところまでパス指定しておけばコマンドが走る。

echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/sbin #実行結果

詳細はこの記事を参考にしてもらうとして、 qiita.com

OSがやることとしては、

「コマンドが叩かれたときにPath変数に保存されているディレクトリ下から実行プログラムを探して実行する」

らしい。

結論としては、ソフトをダウンロードしてきたときに実行ファイルがまとめて一つのディレクトリに保存されるかどうかでお作法が違ってくる。

WindowsとMac/Linuxの違いというより、OSダウンロード時に走るプログラムの違いによるってことだと思う。って書こうとしたんだけど、結局OSのディレクトリ構成起因っぽい。。

WindowsはProgramfiles直下でソフトごとにフォルダが分かれてて、

Programfilesフォルダの中身

それぞれの中に実行ファイルがしまわれている

Git/cmdフォルダの中身

対してMacで確認してみると、例えば/ls/usr/binディレクトリには下記のように実行ファイルがまとめておいてある（わかりにくいですがほぼディレクトリでなくファイルです）。

/ls/usr/binディレクトリの中身

というわけで、Windowsめんどいねという話 OSのディレクトリ構成がこんなところにも影響あるんだねという話でした。

Linux読書会、次は3/24 (土) 開催予定らしいです！ startup-technology.connpass.com

【WIP】WEBエンジニア勉強会 #05 に参加してきた

勉強会

自分の振り返り用にシェア済のリンクまとめました。 感想などあとで追記していきます。

connpassページ

web-engineer-meetup.connpass.com

発表タイトル

HTTPレイヤーで行うパフォーマンスチューニング (@engineer_osca)

とにかく分かりづらいTwelve-Factor Appの解説を試みる (@suke_masa)

www.slideshare.net

なにか作ったらプレスリリースを出してみよう！ (@binbin4649)

www.slideshare.net

OSS BIツール Redash について (@zuckey_17)

speakerdeck.com

redash-meetup.connpass.com

Amazon Rekognitionを用いてフォロワーの男女比を出す (@kzkohashi)

speakerdeck.com

Dockerを利用したローカル環境から本番環境までの構築設計 (@kkoudev)

www.slideshare.net

非機能要件を考えてみよう！ (@iwanaga0918)