tag:blogger.com,1999:blog-10018801340485565832023-11-16T01:29:48.301+09:00unready-made blog技術的な話題が中心のブログですynishihttp://www.blogger.com/profile/13212382728793556793noreply@blogger.comBlogger65125tag:blogger.com,1999:blog-1001880134048556583.post-75476089884621561802017-09-06T01:08:00.000+09:002017-09-06T01:08:33.116+09:00Golang で Webサービスにドキュメントをプッシュするツールを作りました<ul>
<li>複数のWebサービスにドキュメントを公開するツールです。</li>
<li>tdのようなログ送信ではなく、ドキュメントファイルを想定しています。</li>
<li>Golang 製なので、バイナリ一つで動きます。</li>
<li>シンプルなライブラリ設計で、Publisherインターフェイスを実装すればOKです。</li>
<li><p>context対応しているので、安全にAPIをクローズできます。</p></li>
<li><a href="https://github.com/ynishi/publish" class="uri">https://github.com/ynishi/publish</a></li>
<li><p><a href="https://godoc.org/github.com/ynishi/publish" class="uri">https://godoc.org/github.com/ynishi/publish</a></p></li>
</ul>
<h2 id="対応">対応</h2>
<ul>
<li>github => commit を追加します。Endpointを最初からオプションで渡せるので、GHEもOKです。</li>
<li>s3 => ファイルをアップロードします。</li>
</ul>
<h2 id="golang-のtips">Golang のTips</h2>
<h3 id="デバッグ">デバッグ</h3>
<ul>
<li>ライブラリでも最初から実行可能にしておく(mainを設置)</li>
<li>TDDとはいえ、dlvがきかないからきつい。</li>
<li>処理を飛ばすと、debugしにくくなる。</li>
</ul>
<h3 id="構成">構成</h3>
<ul>
<li>cobra/viper を最初から固めておく。</li>
<li>cobra使うなら、viperとセットで。</li>
<li>最初から使うなら、cobraのscaffoldingを使う</li>
</ul>
<h3 id="tdd">TDD</h3>
<ul>
<li>err処理や、testの共通処理を関数で飛ばすのは、いまいち。</li>
<li>context.cancelに関しては、cancelして動作を確認しておく。</li>
</ul>
<p>よきGolang lifeを!</p>ynishihttp://www.blogger.com/profile/13212382728793556793noreply@blogger.com0tag:blogger.com,1999:blog-1001880134048556583.post-23192642303671998092017-08-26T17:12:00.000+09:002017-08-26T17:12:08.651+09:00Golang で nagios plugin をつくりました<p>REST api 特化した nagios plugin を Golang で書きました。SAASやサーバレスなどのサービスが本格的に使われるようになってきたので、REST apiに特化したGlobal監視を前提にしたプラグインを作りました。</p>
<ul>
<li>github.com/olorin/nagiosplugin を使う</li>
<li>commandのみ(ライブラリ化はしてません)</li>
<li><p>バイナリはcheck_rest</p></li>
<li><p><a href="https://github.com/ynishi/nagios-check-rest" class="uri">https://github.com/ynishi/nagios-check-rest</a></p></li>
</ul>
<h2 id="インストール">インストール</h2>
<pre><code>go get github.com/ynishi/nagios-check-rest
cd $GOPATH/src/github.com/ynishi/nagios-check-rest
make
# move check_rest file to nagios plugin dir</code></pre>
<p>よきnagios lifeを!</p>ynishihttp://www.blogger.com/profile/13212382728793556793noreply@blogger.com0tag:blogger.com,1999:blog-1001880134048556583.post-59346791971139774722017-08-12T01:25:00.000+09:002017-08-13T10:35:37.711+09:00go開発環境構築 on Windows<ul>
<li>WindowsでGolangのIDE開発環境を構築します。</li>
</ul>
<h3 id="go-">goのインストール</h3>
<ul>
<li><a href="https://golang.org/doc/install#windows">https://golang.org/doc/install#windows</a></li>
<li>PATHの追加<ul>
<li>%PATH%;%USERPROFILE%\go\bin</li>
<li>C:\go\bin は設定されるが、ユーザごとの%USERPROFILE%\go\bin は追加されない。</li>
</ul>
</li>
<li>GOPATHの追加<ul>
<li>%USERPROFILE%\go</li>
</ul>
</li>
</ul>
<h3 id="git-">gitのインストール</h3>
<ul>
<li><a href="https://git-for-windows.github.io/">https://git-for-windows.github.io/</a></li>
<li>git bash からUNIX likeな操作でgo/go toolsコマンドが使えるようになる。</li>
</ul>
<h3 id="go-tools-https-godoc-org-">go tools のインストール</h3>
<ul>
<li><a href="https://godoc.org/">https://godoc.org/</a> で最新の情報を確認</li>
<li>dlv</li>
<li>goimports</li>
<li>dep</li>
</ul>
<h3 id="gogland-">Goglandのインストール</h3>
<ul>
<li><a href="https://www.jetbrains.com/go/">https://www.jetbrains.com/go/</a></li>
<li>goimportsの設定<ul>
<li>setting => keymap => goimportsを検索 => Ctrl + Shift + S などに設定</li>
</ul>
</li>
<li>Terminalの設定<ul>
<li>setting => Terminal => Shell path => C:\Program Files\Git\bin\bash.exe に設定</li>
<li>Unix likeな操作がターミナルパネルで使える</li>
<li>C:\Program Files\Git\git-bash.exe だと別ウィンドウになる</li>
</ul>
</li>
</ul>
<h3 id="-">プロジェクトの配置</h3>
<ul>
<li>Goの標準に従う<ul>
<li><a href="https://golang.org/doc/code.html#Workspaces">https://golang.org/doc/code.html#Workspaces</a> に従って構成。</li>
<li>各リポジトリをGoglandでOpenしてGogland Projectとして取り込む。</li>
</ul>
</li>
<li>もしくは、github.com/user 直下をまるごと一つのGoglandプロジェクトとして読み込む。<ul>
<li>一括で取り込み管理できる。</li>
<li>各リポジトリのGo SDKなどの設定ができない。</li>
</ul>
</li>
</ul>
<p>WindowsでもよきGo lifeを!</p>ynishihttp://www.blogger.com/profile/13212382728793556793noreply@blogger.com0tag:blogger.com,1999:blog-1001880134048556583.post-47493113714885139202017-08-05T14:25:00.000+09:002017-08-05T14:27:44.546+09:00Golangの Redash APIクライアントライブラリを作りました<p>Redash の Rest api をラップするGolang ライブラリを書きました。</p>
<p>GolangからRedashクライアントを使いたいときは使ってみてください。</p>
<p>今後機能追加するとしたら、cli化だと思います。セッション管理機能を持ったcliを作って一般的なDB clientのようにredashを使えればかなり便利だと思います。</p>
<p><a href="https://github.com/ynishi/redash" class="uri">https://github.com/ynishi/redash</a></p>
<ul>
<li><p>インストール</p>
<pre><code>go get github.com/ynishi/redash</code></pre></li>
<li>実装機能
<ul>
<li>Client(Get/Post/Deleteを実行)</li>
<li>Queries系API</li>
</ul></li>
</ul>
<h3 id="redash">Redash</h3>
<p>今年に入って仕事でOSSのBIツール、Redashを使う機会がありました。</p>
<p>Redashの特徴は、豊富なDB連携と、ほとんど全ての機能がAPI経由でできることです。 (Redashの構成自体そうなっている)</p>
<p>API利用は、オフィシャルに推奨されています。 特にドキュメントはなく、サポートに問い合わせたところ、ソースコードを見て是非使ってくださいとのことでした。</p>
<p>仕事の案件ではサーバにDBクライアントの追加が厳しい環境 だったので、Redashを経由してデータを取得しました。</p>
<p>DB連携が限定的でよければ、Airbnbが作ったツールがあります。画面の作りこみと、権限管理などがRedashよりよさそうです。 <a href="https://github.com/apache/incubator-superset">superset</a></p>
<h3 id="golang">Golang</h3>
<p>Golangのライブラリはなかったので、作ることにしました。</p>
<p>仕事でもGolangの導入を画策しているので、テスト、ドキュメンテーション、ライブラリ管理なども含めて一通り用意しました。</p>
<h4 id="apiクライアントについて">APIクライアントについて</h4>
<ul>
<li>GolangでAPIクライアントを実装</li>
<li>http://deeeet.com/writing/2016/11/01/go-api-client/</li>
</ul>
<h4 id="開発にあたって">開発にあたって</h4>
<p>とにかく参考になるのが、本家日本語版ドキュメントです。</p>
<ul>
<li>本家日本語版のドキュメント<a href="http://golang-jp.org/doc/" class="uri">http://golang-jp.org/doc/</a></li>
</ul>
<p>実際にコードを書く際には必須のEffective Goですが、本家は英語版のみです。</p>
<ul>
<li><a href="http://golang-jp.org/doc/effective_go.html" class="uri">http://golang-jp.org/doc/effective_go.html</a></li>
</ul>
<p>日本語訳は、有志の方によるものがいくつかあります。少し古いですが日本語で読めるのはありがたいです。</p>
<ul>
<li>全訳済 <a href="http://golang.jp/effective_go" class="uri">http://golang.jp/effective_go</a></li>
<li>一部未訳部あり <a href="http://go.shibu.jp/effective_go.html" class="uri">http://go.shibu.jp/effective_go.html</a></li>
</ul>
<p>このページにまとまってます<a href="http://qiita.com/tenntenn/items/0e33a4959250d1a55045">Go言語の初心者が見ると幸せになれる場所 #golang</a></p>
<h4 id="プロジェクトの開始">プロジェクトの開始</h4>
<ul>
<li>上記の<a href="http://golang-jp.org/doc/code.html">Goの書き方</a> が参考になります。
<ul>
<li>ディレクトリ構成は github.comなどと密接に結びついた構成になってます。</li>
<li><span class="math inline"><em>G</em><em>O</em><em>P</em><em>A</em><em>T</em><em>H</em><em>を</em><em>d</em><em>i</em><em>r</em><em>e</em><em>n</em><em>v</em><em>の</em><em>よ</em><em>う</em><em>な</em><em>も</em><em>の</em><em>を</em><em>使</em><em>っ</em><em>て</em><em>通</em><em>す</em><em>よ</em><em>り</em>、</span>GOPATHは固定にして、その中にリポジトリを置く方がよさそう。</li>
<li>$GOPATH内にリポジトリ本体を置いて、他の場所には、シンボリックリンクを張る構成に落ち着きました。</li>
</ul></li>
<li>自動テスト
<ul>
<li>開発環境の自動コンパイル・テストは標準ツールはありません。<code>godo</code>などを使います。</li>
<li>Goglandなら、コンパイルエラーは随時検知できます。</li>
<li>travis, werker, CircleCI, droneなど各種CIサービスで公式サポートされてます。簡単に設定できるので、最初にしておく方がいいです。</li>
</ul></li>
<li>リポジトリタグ
<ul>
<li>githubのリポジトリタグ => 公式に合わせて <code>go</code> に。</li>
</ul></li>
</ul>
<h4 id="ツール">ツール</h4>
<ul>
<li>vim-go
<ul>
<li>vimでは必須</li>
<li>壊れたときの復旧<a href="http://syossan.hateblo.jp/entry/2017/02/16/133851">vim-goの入力補完が動かなくなった</a></li>
</ul></li>
<li>[Gogland(IDE)](https://www.jetbrains.com/go/)
<ul>
<li>最初は便利</li>
<li>debuggerが使えないなど一部難あり</li>
<li>$GOPATH内に置いたリポジトリを取り込む(または、$GOPATH/../自分のアカウントディレクトリ/をとりこむ)</li>
</ul></li>
</ul>
<h4 id="ドキュメンテーション">ドキュメンテーション</h4>
<ul>
<li><a href="http://golang-jp.org/pkg/code.google.com/p/go.tools/cmd/godoc/">godoc</a>に合わせて作成。
<ul>
<li>基本パッケージ、公開するものにコメントを書けばOkです。</li>
<li>ライセンス表記は、ファイルの一番上に書いて空行を入れてからパッケージコメントを書くとgodocに表示されません。</li>
<li>Exampleテストを書けばそれが表示されます。</li>
</ul></li>
<li><a href="http://godoc.org/">GoDoc host</a>の登録方法
<ul>
<li><p>インポートするパッケージ名を一度検索します。</p>
<pre><code>//↓これで検索
github.com/ynihsi/redash</code></pre></li>
<li><p>次からはキーワード検索でマッチします。</p>
<pre><code>//↓これでひっかかる
redash</code></pre></li>
</ul></li>
</ul>
<h4 id="ライブラリ管理">ライブラリ管理</h4>
<ul>
<li>公式ツール dep があります。
<ul>
<li>まだ開発中で標準ツールに取り込まれてはいません。</li>
<li>(2017/7現在)設定ファイルは固まったようでプロダクションuse OKになりましたが、まだAPIは変わる可能性があります。</li>
</ul></li>
<li>glideなど各種ツールがあります。</li>
<li>パッケージ名でバージョン管理する方法があります(これまで公式依存管理ツールがなかったため)</li>
<li>Golangの設計として安定する傾向が強いです(mapのキャストが手間で結局構造体とインターフェイスを使うなど)</li>
</ul>
<p>よきGolang & Redash ライフを!</p>ynishihttp://www.blogger.com/profile/13212382728793556793noreply@blogger.com0tag:blogger.com,1999:blog-1001880134048556583.post-2260488972001674352017-07-23T13:32:00.000+09:002017-07-23T13:32:44.200+09:00cliでGo Playground 的なこと<ul>
<li>Go Playgroundは、ちょっとしたコードを試すのによい。</li>
<li>ただ、3rd Partyのライブラリが読み込めない。</li>
<li>今あるGoの開発環境を使いたい(ライブラリ,Cli)</li>
<li>Go のreplもいくつかあるので、そちらが合う人はどうぞ。</li>
</ul>
<p>と考えて、godoというgulp likeなタスクランナーを使ってcli上で、コードを試せるものを簡易的に作りました。</p>
<p><a href="https://github.com/ynishi/simple-go-playground" class="uri">https://github.com/ynishi/simple-go-playground</a></p>
<p>単純に、goのスニペットファイルを作って、変更があったら自動でrunするだけのシンプルなものです。</p>
<h2 id="vimで使う">vimで使う</h2>
<p>vimで開発してる人は、vim内の別ウィンドウで、プロセス起動できるプラグインがあります。</p>
<p><a href="https://github.com/vim-scripts/Conque-Shell" class="uri">https://github.com/vim-scripts/Conque-Shell</a></p>
<p>これを使うと、vim内でスニペットファイルを変更して実行結果が随時確認できるので、Playgroundにより近くなると思います。</p>
<p>よきGo lifeを!</p>ynishihttp://www.blogger.com/profile/13212382728793556793noreply@blogger.com0tag:blogger.com,1999:blog-1001880134048556583.post-7862528082053893782017-07-01T23:19:00.000+09:002017-07-01T23:19:10.158+09:00JSプロジェクトのテンプレートを公開しました
<ul>
<li>フロントエンドを改めて調べた。</li>
<li>各種ツールを組み合わせる必要があり、公開されてるテンプレートが非常に役に立った。</li>
<li>やりたいことが一通りできたので、テンプレートを公開します。</li>
<li>リポジトリ https://github.com/ynishi/riot-firebase-es6</li>
</ul>
<h2 id="概要">概要</h2>
<h3 id="やりたかったこと">やりたかったこと</h3>
<ul>
<li>ES6でできるだけ記述</li>
<li>テスト可能にする</li>
<li>npmパッケージを使用する</li>
<li>学習コストの低い軽量ライブラリ/サービスを使う</li>
</ul>
<h3 id="使用フレームワークと対応仕様">使用フレームワークと対応仕様</h3>
<ul>
<li>Riot(tag & route) => ES6</li>
<li>Firebase => ES6</li>
<li>Karma => ES6</li>
<li>Rollupで上記ES6 => ES5 => test & build & deploy => ブラウザで閲覧</li>
<li>npm => npm-scriptで簡易ビルドコマンド</li>
</ul>
<h3 id="参考になった記事">参考になった記事</h3>
<ul>
<li>npm とか bower とか一体何なんだよ!Javascript 界隈の文脈を理解しよう http://qiita.com/megane42/items/2ab6ffd866c3f2fda066</li>
<li>Riot+Firebase APIをたたくhttp://qiita.com/tomomichi/items/43da4d35007e69d0f484</li>
<li>Riot+Webpack https://github.com/esnunes/riotjs-loader</li>
<li>Riot+Rollup http://qiita.com/cognitom/items/c20c22614560627062cb</li>
<li>Riot+Rollup Example http://qiita.com/cognitom/items/c20c22614560627062cb</li>
<li>Firebaseにデプロイする http://qiita.com/kohashi/items/43ea22f61ade45972881</li>
<li>SAMモデル(SPA/Reactをモデル化) https://www.infoq.com/jp/articles/no-more-mvc-frameworks</li>
</ul>
<p>よきES6ライフを!</p>ynishihttp://www.blogger.com/profile/13212382728793556793noreply@blogger.com0tag:blogger.com,1999:blog-1001880134048556583.post-379326280249842252017-05-03T23:39:00.000+09:002017-05-03T23:39:14.223+09:00プログラミング入門講座 で最新のプログラミング学習方法を読んでみる<ul>
<li>「プログラミングの基本を最少の時間で確実に習得できる学び方とは?」とのことで、最近の学習方法について気になったので読んでみました。</li>
</ul>
<h3 id="-">対象読者</h3>
<pre><code>◆◆本書の対象読者◆◆
・ できるだけ効率よく、プログラミングの基本を習得したい人
・ プログラミングに興味はあるが、そもそもの「学び方」がよくわからない人
・ 社会人の一般教養として「プログラミングの基本」を身につけておきたい人
・ 子どものプログラミング教育に興味のある人
</code></pre><p>とのことで、内容からもブルーバックスや理系の新書も読まないレベルの方々が対象と感じました。</p>
<p>プログラミングをやりたい=>「Java入門/計算機科学入門/コンピューターのしくみ/アルゴリズム入門をやらないと」という方々にはあまり有益と感じられる情報はないかもしれません。</p>
<h3 id="-">気になった個所</h3>
<p>その前提ではありますが、目に留まった個所を紹介します。</p>
<ol>
<li>オンライン講座の紹介が豊富<ul>
<li>この本では、オンライン講座から入門することを推奨していて、様々なサービスが紹介されています。</li>
<li>動作環境ありのオンライン講座は経験者でもさくっと試してみるにはいいです。</li>
<li>経験者でも、新しい分野をCourseraなどから入門する方法はありですね。</li>
</ul>
</li>
<li>簡単なことから難しいことへ<ul>
<li>オンライン講座でとりあえず動かしてみて、基本的な用語も身についたところで、質問をしてみる。</li>
<li>本でスムーズに独学できるレベルになってから独学する。</li>
</ul>
</li>
<li>企画と開発を分けて考える<ul>
<li>プライベート・入門者だからこそ、企画と開発を分けて考えることが重要。</li>
<li>プライベートでプログラミングをしようとして挫折するパターンとして、「とりあえず○○入門を買ってくる」=> 「写経する」=> 「終わったけどどうしよう?」となる。</li>
<li>これではプログラミングの醍醐味である、自分の好きなアプリを作って、それが実際に動くというところが体験できないし、続かない。</li>
</ul>
</li>
</ol>
<p>プログラミング「言語」の入門を期待すると全く違う内容ですが、プライベートでプログラミングを体験してみることの概要がつかめるので、「プライベートでプログラミングやってみたいんだけど」と相談された時に、上記の条件にあっている人に教えてあげると役立つと思います。</p>
<p>よいプログラミング入門を!</p>
ynishihttp://www.blogger.com/profile/13212382728793556793noreply@blogger.com0tag:blogger.com,1999:blog-1001880134048556583.post-63622723515666481922017-04-30T12:22:00.000+09:002017-04-30T12:22:51.605+09:00初めてのRuby 1章について<ul>
<li>「言語のしくみ」を読んで、MatzさんとRubyに改めて興味を持ったので、Rubyエンジニアの方に聞いたら「Rubyは作りたいものを作りやすい」とのことでした。</li>
<li>「初めてのRuby」を以前買っていたので読み直しました。</li>
<li>他の言語経験者向けの入門書で、他の言語や一般的な言語の作りと比較してRubyの基本を説明しています。リファレンスを読みながら進められるところまで。</li>
<li>「1章 ようこそ、Rubyのある生活へ」で気になったところをまとめました。</li>
<li>コラムでは、「文字列の変更可能性」や「型変換」など、簡潔に他言語との比較で、はまりそうなポイントを説明していて気に入ってます。</li>
<li>バージョンが1.8, 1.9対応だったのが難ですが、それ以外はおすすめです。</li>
</ul>
<h3 id="章-ようこそrubyのある生活へ">1章 ようこそ、Rubyのある生活へ</h3>
<ul>
<li>Rubyの主要概念が書いてある。</li>
<li>バージョンナンバーの振り方や、開発環境/実行環境など一通り書いてある。</li>
<li>Rubyの文脈を理解してRubyらしいコードを書くとよい。</li>
</ul>
<h4 id="rubyの特徴的な部分で気になったところ">Rubyの特徴的な部分で気になったところ</h4>
<ul>
<li>動く擬似コード
<ul>
<li>ほぼ擬似コードのまま動く</li>
<li>処理の本質的な記述に集中できる。</li>
</ul></li>
<li>高階関数
<ul>
<li>コードブロックというオブジェクトをやりとりすることができる。無名関数のように使える。</li>
<li>コードブロックを受け取るメソッド(=高階関数的に動く) => ブロック付きメソッド</li>
<li>コードブロックはクロージャとして機能するが、メソッドはそうではない。</li>
</ul></li>
<li>DSL
<ul>
<li>言語内DSL</li>
<li>カスタム言語を追加する => それを使ってソフトを作る。</li>
<li>このスタイルがRubyでは一般的になっている。</li>
</ul></li>
<li>動的
<ul>
<li>実行時にクラス定義を処理する。</li>
<li>メリットはクラス定義まで通常の制御で管理できる。</li>
<li>デメリットはクラス名がずれたりしても、実行時エラーにしかならない。</li>
<li>どちらにしろ単体テストかくのだから、そのあたりは問題ないという考え方も。</li>
</ul></li>
<li>メタプログラミング
<ul>
<li>DSL/動的な機能を使って、かなりの部分をパラメータ化できる。</li>
<li>それをしようとしたときに、特別な宣言等をする必要なく、シームレスに言語を拡張できる。</li>
<li>クラス定義が実行時に行われるため。</li>
</ul></li>
</ul>
<h4 id="機能探索順">機能探索順</h4>
<ol style="list-style-type: decimal">
<li>専用の文法</li>
<li>組み込み関数</li>
<li>組み込みクラス</li>
<li>標準ライブラリ</li>
<li>外部ライブラリ</li>
<li>自作</li>
</ol>
<h4 id="構成">構成</h4>
<ul>
<li>言語本体</li>
<li>組み込みライブラリ
<ul>
<li>組み込み定数</li>
<li>組み込み変数</li>
<li>組み込み関数</li>
<li>組み込みクラス</li>
</ul></li>
<li>標準添付ライブラリ</li>
</ul>
<h4 id="外部ライブラリ">外部ライブラリ</h4>
<ul>
<li>標準添付ライブラリ
<ul>
<li>追加インストール不要。</li>
<li>ユーザプログラムからインクルード必要。</li>
</ul></li>
<li>外部ライブラリ
<ul>
<li>基本はRubyで書かれている</li>
<li>拡張ライブラリ(C言語等で書かれたネイティブライブラリ)</li>
</ul></li>
</ul>
<h4 id="実行環境">実行環境</h4>
<ul>
<li><p>対話</p>
<pre><code>irb</code></pre></li>
<li><p>スクリプト実行</p>
<pre><code>ruby hello.rb</code></pre></li>
<li><p>デバッガ</p>
<pre><code>ruby -rdebug hello.rb</code></pre></li>
<li>リファレンス
<ul>
<li><p>コマンドライン</p>
<pre><code>ri String</code></pre></li>
<li><p>irb</p>
<pre><code>irb help</code></pre></li>
</ul></li>
</ul>
<h4 id="あると便利">あると便利</h4>
<ul>
<li><a href="http://mikeda.hatenablog.com/entry/20090318/1237400527">irbでタブ補完</a></li>
<li><p>コード整形</p>
<pre><code>gem install ruby-beautify </code></pre></li>
<li>Test <a href="http://qiita.com/jnchito/items/ff4f7a23addbd8dbc460">Ruby標準のテスティングフレームワークで手軽にテストコードを書く方法</a></li>
<li><p>型(クラス)確認方法 <a href="http://kinopyo.com/ja/blog/to-find-out-ruby-object-class">Ruby オブジェクトのクラスを調べるには?</a></p>
<pre><code># classメソッドを使う
s = "str"
s.class</code></pre></li>
</ul>
ynishihttp://www.blogger.com/profile/13212382728793556793noreply@blogger.com0tag:blogger.com,1999:blog-1001880134048556583.post-1428195200804753632017-04-25T23:39:00.000+09:002017-04-25T23:39:45.188+09:00リーン・スタートアップを改めて<ul>
<li>改めてリーンスタートアップを読みました。</li>
<li>起業やベンチャーにいる方以外のビジネスマンにもぜひおすすめしたい本です。</li>
<li>最初期の検証をどうやって行ったかの事例も豊富でどのような行動が検証といえるかのイメージができます。</li>
<li>気になったポイントをまとめました。</li>
</ul>
<h3 id="スタートアップの事業運営を検証による学びのプロセスととらえる">スタートアップの事業運営を検証による学びのプロセスととらえる</h3>
<ul>
<li>スタートアップの最大の課題は、事業が成立する(顧客がいる)ことが「仮説」に過ぎないこと。</li>
<li>「仮説」といえば、大層に聞こえるが、程度の差はあれ思い込みにすぎない。</li>
<li>この「仮説」を最も低コストかつ、最も確実に検証し、そのフィードバックを得ること、また、その一連のプロセスを最短にすることを目標とする。</li>
<li>「仮説」の元とした事実が間違っている場合など、考察によって見つけることは現実的にかなりの困難を伴う。</li>
<li>そのため、実験(検証したいことにあった最小のビジネス活動)を行って定量・定性的にフィードバックを集める。</li>
<li>スタートアップにとっては、価値仮説と成長仮説が重要。</li>
</ul>
<h3 id="とにかくやってみようではすぐに手詰まりになる">「とにかくやってみよう」では、すぐに手詰まりになる</h3>
<ul>
<li>計画と遂行を基礎とする一般的なプロジェクトマネジメント(総括マネジメントと呼んでいる)は、新製品を開発するのには向かないが、無計画も同様に成果を出しにくい。</li>
<li>行動力は重要だが、それだけでは失敗する。</li>
<li>体系的で適切な仮説と検証をすることは難しいが、それをやらずに、全ての仮説に基づいて商品を作って試していたら、それをうまくやる競合に必ず負ける。</li>
<li>先にものを作ってしまうと、コストがかかりすぎる。</li>
<li>検証という視点がないと、「製品」を作ろうとしてしまう。</li>
</ul>
<h3 id="mvpやスモールスタートなどとリーンスタートアップ">MVPや、スモールスタートなどとリーンスタートアップ</h3>
<ul>
<li>MVPなど、聞いたことがない人の方が少ないかもしれませんが、リーンスタートアップでは、明確に定義しています。</li>
<li>MVPは最低限使える機能を持った製品ではなく、仮説の検証が可能な最小の製品。</li>
<li>リーンスタートアップを「小さく始める手法」と紹介されることがあるが、解決しようとする課題によっては、「仮説」の検証にかなりの品質が必要となる場合がある。</li>
<li>デザイン思考やA/Bテストなどの手法は以前からあった。リーンスタートアップはこれらの手法を、製品開発に活用するのが違い。</li>
</ul>ynishihttp://www.blogger.com/profile/13212382728793556793noreply@blogger.com0tag:blogger.com,1999:blog-1001880134048556583.post-32578356176564500602017-04-24T21:29:00.000+09:002017-04-24T21:29:16.362+09:00IoTを調べた情報ソース<ul>
<li>IoTについてキャッチアップしたときの情報源です(2017年4月)。</li>
</ul>
<h3 id="入門">入門</h3>
<ul>
<li>技術・ビジネス両面を解説している。</li>
<li>最初に概要をつかむにはよい。</li>
</ul>
<h4 id="図解でわかるiotビジネス-いちばん最初に読む本">図解でわかるIoTビジネス いちばん最初に読む本</h4>
<ul>
<li>IoTの活用事例が載っていて、イメージがつかみやすい。</li>
<li>技術解説を含めて初心者向けでわかりやすい。</li>
<li>https://www.amazon.co.jp/gp/product/4897951976/ref=oh_aui_detailpage_o03_s00?ie=UTF8&psc=1</li>
</ul>
<h4 id="iotとは何か-技術革新から社会革新へ-角川新書">IoTとは何か 技術革新から社会革新へ (角川新書)</h4>
<ul>
<li>TRONの坂村氏によるIoT入門本。</li>
<li>早期から研究してきた立場から書いている。</li>
<li>https://www.amazon.co.jp/IoT%E3%81%A8%E3%81%AF%E4%BD%95%E3%81%8B-%E6%8A%80%E8%A1%93%E9%9D%A9%E6%96%B0%E3%81%8B%E3%82%89%E7%A4%BE%E4%BC%9A%E9%9D%A9%E6%96%B0%E3%81%B8-%E8%A7%92%E5%B7%9D%E6%96%B0%E6%9B%B8-%E5%9D%82%E6%9D%91-%E5%81%A5/dp/4040820584/ref=asap_bc?ie=UTF8</li>
</ul>
<h4 id="インターネット白書2017iotが生み出す新たなリアル市場">インターネット白書2017 IoTが生み出す新たなリアル市場</h4>
<ul>
<li>定番だが、一通り押さえられる。</li>
<li>IoTの他にもAI、ブロックチェーンなどこの1年話題になった技術に触れている。</li>
<li>https://www.amazon.co.jp/gp/product/B01MYDIDWW/ref=oh_aui_d_detailpage_o04_?ie=UTF8&psc=1</li>
</ul>
<h3 id="技術入門">技術入門</h3>
<h4 id="iotエンジニア養成読本">IoTエンジニア養成読本</h4>
<ul>
<li>IoTを使ったサービスを作る際に必要な技術を一通り押さえている。</li>
<li>ハンズオンがある。</li>
<li>https://www.amazon.co.jp/gp/product/4774188654/ref=oh_aui_detailpage_o02_s00?ie=UTF8&psc=1</li>
</ul>
<h4 id="雑誌">雑誌</h4>
<ul>
<li>トランジスタ技術</li>
<li>Interface</li>
<li>ラズパイマガジン</li>
</ul>
<h3 id="ネットニュース">ネットニュース</h3>
<ul>
<li>IoTNews</li>
<li>https://iotnews.jp/</li>
<li>Make:</li>
<li>http://makezine.jp/</li>
<li>カメリオ IoTタグ</li>
<li>https://lp.kamel.io/</li>
</ul>
<h3 id="iotプラットフォーム">IoTプラットフォーム</h3>
<ul>
<li>サービス名 - プロバイダー</li>
<li>大手はたいていサービスを提供している
<ul>
<li>AWSIoT - Amazon</li>
<li>Azure - Microsoft</li>
<li>Watson IoT Platform - IBM</li>
<li>他</li>
</ul></li>
<li>SORACOM - SORACOM</li>
<li>Kii - Kii</li>
<li>さくらのIoT Platform - さくらインターネット</li>
<li>Predix - GE</li>
<li>Lumada - 日立</li>
<li>ABEJA Platform Open - ABEJA</li>
</ul>
<h3 id="勉強会">勉強会</h3>
<ul>
<li>IoT縛りの勉強会</li>
<li>https://iotlt.connpass.com/</li>
</ul>
<h3 id="事例">事例</h3>
<ul>
<li>クラウドファンディング(特に海外)はIoTプロダクトの宝庫</li>
<li>https://www.kickstarter.com/</li>
</ul>ynishihttp://www.blogger.com/profile/13212382728793556793noreply@blogger.com0tag:blogger.com,1999:blog-1001880134048556583.post-73676609312540287052017-03-05T13:09:00.000+09:002017-03-05T13:12:43.458+09:00技術ブログを書いてみて<p>2016年4月にこのブログを始めて、早1年がたちました。 その経験を踏まえて、技術ブログをすることの価値を考えました。</p>
<p>結論をいうと</p>
<ul>
<li>ブログ(にアウトプットすること)はエンジニアとしてメリットが多い。</li>
<li>ただ、いざ書こうとすると、エンジニアにとってハードルが高いアドバイスが多い。</li>
<li>「技術ブログ」に限定することで、ハードルが下がる。</li>
</ul>
<p>キャリアの初期からアウトプットをすることは、 エンジニアにとって、非常に効果的で有用なツールになると 考えてます。</p>
<p>なので、4月から何か新しいことをという方や、技術ブログ始めてみようかな という方はぜひはじめてみてください。</p>
<p>ただ、その際に、ブログの書き方とかを検索すると、一般的なブログの 書き方が多く、エンジニアにとっては、ハードルが高い項目もあります。</p>
<p>例えば、プロフィールを充実させろ、日常的な話題を入れろ、誰にでも わかるようにしろ、マーケティングを考えてSNSで積極的に宣伝しろなどです。</p>
<p>技術ブログの場合、そこに力を入れなくても、技術記事を書きためて、 アウトプットすることをキャリアの初期からすることの方が、エンジニア自身が 得られるメリットは十分にあると思います。</p>
<p>もちろん、マーケティング的な要素を強化すれば、エンジニアとしての働き方は 選択肢が増えると思うので、そこを重視したい方は、ぜひやってみてください。</p>
<p>また、ブログマーケティング的な話は、すでに非常にたくさんの情報が出てるので 検索してみてください。</p>
<h3 id="技術ブログの位置づけ">技術ブログの位置づけ</h3>
<p>この記事での技術ブログを定義します。</p>
<p>見てもらう人は、</p>
<ul>
<li>技術ワードで検索して来る人</li>
<li>職場のエンジニア</li>
<li>勉強会など職場以外のエンジニア</li>
</ul>
<p>と、ネットに記事内容は公開するのに加えて、 身内の人々が見ることも想定した半SNS的な位置づけを想定してます。</p>
<p>身内の人々が見る前提で始めるとフィードバックがもらえたり、 一定の品質を保つモチベーションになり、職場以外の場所や 転職活動でも、気兼ねなくポートフォリオの一部として公開 できるので、おすすめです。</p>
<h3 id="公開する要素について">公開する要素について</h3>
<p>ブログを始めようと思って調べると、ブログマーケティング的な話が出てきて「自分の情報を公開してファンを作ろう」的な話が出てくると思います。</p>
<p>その辺の話がネックになって、技術ブログを持たないのはもったいないです。</p>
<p>リアルでつながりがある人には、直接URLを伝えることを想定しているので、プロフィールなどは充実しなくてもメリットは十分あります。</p>
<p>また、技術以外の記事や、情報について書かなくても、同様にメリットは十分あります。</p>
<p>ただ、その場合は、ネット上での反応は薄くなります。</p>
<h3 id="技術ブログのメリット">技術ブログのメリット</h3>
<p>上記を対象者として技術ブログを書くメリットです。</p>
<ul>
<li>学習効果が高くなる。
<ul>
<li>理解度が高くなる</li>
<li>フィードバックがもらえる</li>
</ul></li>
<li>情報感度が高くなる。
<ul>
<li>意識的にネタを集めるようになる</li>
<li>ネタから一歩進めて形にするのが習慣になる</li>
</ul></li>
<li>備忘録になる。
<ul>
<li>ネットは最強のバックアップストレージ</li>
</ul></li>
<li>名刺代わりになる。
<ul>
<li>履歴書、職務経歴書だけでは伝わらない技術をアピールできる</li>
</ul></li>
<li>Web技術の勉強になる。
<ul>
<li>特に自分でホスティングしたりする場合。</li>
</ul></li>
</ul>
<h3 id="技術ブログのデメリット">技術ブログのデメリット</h3>
<p>「ブログで有名人になろう」というスタンスで臨むと相応のデメリットも生じると思いますが、自身の技術を高めることをメインに考えるとそれほど大きなデメリットは生じないと思います。</p>
<ul>
<li>時間がかかる
<ul>
<li>コマンドを並べただけの記事ならば、1時間で書ける。</li>
<li>ある程度価値がありそうな記事は数時間かかる。</li>
</ul></li>
<li>PVが少ない
<ul>
<li>マーケティングに力を入れないと、PVは伸びない。</li>
<li>PVを伸ばしたいなどは、一般のブログと同じように施策してください。</li>
</ul></li>
<li>NG内容がある
<ul>
<li>リアルとのつながりを前提としているので、ネットならではの自由さは制限されます。</li>
</ul></li>
</ul>
<h3 id="記事とテーマについて">記事とテーマについて</h3>
<p>技術ブログの記事のスタイルをカテゴリ分けしてみました。 比較検証記事は、勉強になりますが時間もかかります。</p>
<p>ブログを継続するためには、手順やTIPS記事などと 織り交ぜていくといいと思います。</p>
<p>テーマですが、最初は特定の技術分野に絞り過ぎない方がいいと思います。</p>
<p>以前、いくつか作ってみたのですが、個人ブログでやるときは、モチベーションが重要な要素になるので、ある程度幅を持たせた方が継続しやすいと思います。</p>
<ul>
<li>比較
<ul>
<li>あるテーマに沿って類似の技術やアプリ等を比較する。</li>
<li>比較軸と論拠を明示すると記事の質が上がります。</li>
<li>使用ケースを想定して、それぞれ最適なものを選んでみる。</li>
<li>技術選定の経験が積める。</li>
</ul></li>
<li>検証
<ul>
<li>1つの技術やアプリ等について、仕様や性能調査をする。</li>
<li>調査軸を明確にして、それを実地調査する。</li>
<li>前提条件や、実施状況など基礎的な要素を明示する。</li>
<li>パフォーマンス調査が学べる。</li>
</ul></li>
<li>TIPS
<ul>
<li>ある技術やアプリ等について、細かい仕様や使いこなし。</li>
<li>一般的なコマンドなどについても、以外と記事がないことがある。</li>
<li>検索してもよい解説がでてこなくてmanページを読んだりして解決したことはそのまま記事になる。</li>
</ul></li>
<li>手順
<ul>
<li>インストール方法や、設定方法、一般的な使い方など。</li>
<li>記事があっても、新しいバージョンに更新されてない場合におすすめ。</li>
<li>historyコマンドが重宝する。</li>
</ul></li>
<li>技術解説
<ul>
<li>技術やモデルなどについて、解説する。</li>
<li>モデルの理解の仕方など。</li>
<li>入門者向けに。</li>
<li>HaskellのMonad解説ページのようなイメージ。</li>
</ul></li>
<li>書評
<ul>
<li>技術書を中心とした書評です。</li>
</ul></li>
</ul>
<h3 id="記事を書くときの注意点">記事を書くときの注意点</h3>
<p>可能な限り正しい記事を書きましょう。 不明、未検証箇所は、そのまま書いておきましょう。</p>
<p>以下のメリットがあります。</p>
<ul>
<li>ちゃんと調べることで自分の勉強になる。</li>
<li>見た人も確実な情報を得られる。</li>
</ul>
<p>また、記事を読む人のレベルを想定しましょう。 全ての記事を初心者でも問題なく読めるレベルにする必要はないと思います。 読む人のレベルを、できるだけ具体的な人物を想定して書くとまとまった記事になると思います。</p>
<h3 id="実際に書いてみる">実際に書いてみる</h3>
<p>現実的にエンジニアにとってメリットのある技術ブログについて、まとめてみましたが、いかがでしたでしょうか?</p>
<p>技術ブログの始め方でおすすめは、<a href="https://www.amazon.co.jp/SOFT-SKILLS-%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E9%96%8B%E7%99%BA%E8%80%85%E3%81%AE%E4%BA%BA%E7%94%9F%E3%83%9E%E3%83%8B%E3%83%A5%E3%82%A2%E3%83%AB-%E3%82%B8%E3%83%A7%E3%83%B3%E3%83%BB%E3%82%BD%E3%83%B3%E3%83%A1%E3%82%BA/dp/4822251551">SOFT SKILLS</a>です。 ブログを持つことをかなり推奨していて、マーケティング的なところもカバーしています。</p>
<p>実際にスタートするときは、以下の2つのやり方があると思いますが、初めてブログを書く場合は、とにかく書いてみることをおすすめします。</p>
<h4 id="とにかく書いてみる">1. とにかく書いてみる</h4>
<p>初めてブログを書く方は、とにかくある程度の記事を実際に書いてみることをおすすめします。</p>
<ul>
<li>まずHello world動かしてみるイメージです。</li>
<li>書いて見ないと、自分でしっくりくる記事や、面白いと思える記事はよくわからない。</li>
<li>最初はほとんど反応がないので、いろいろと手を尽くしてもいいのか悪いのか判断しにくい。</li>
</ul>
<h4 id="既存のブログを参考にする">2. 既存のブログを参考にする</h4>
<p>何らかのブログを書いていたり、他のブログを読むのが好きな方におすすめです。</p>
<ul>
<li>気になった技術ブログをいくつかフォロー => 書いているテーマや、スタンス、記事の言葉遣いなどを観察 => まねして書く => 自分のスタイルで書く。</li>
<li>技術を身につけるときと同じです。</li>
</ul>
<h4 id="継続するときに気をつけること">継続するときに気をつけること</h4>
<ul>
<li>アクセスがなくても気にしない。</li>
<li>書き始めてからプラットフォームを移動するのは大変。
<ul>
<li>WordPress触るのが苦でない人は、自分でWordPressホスティングするのがいい。</li>
<li>WordPress触るのがいやな方は、ブログサービスを使うのがいい。</li>
<li>ブログを書くのとWordPressなどを勉強するのは分けた方がいい。</li>
</ul></li>
<li>移行せずにブログのテーマなどを変えるのはできる。</li>
<li>数ヶ月更新しないとフェードアウトしてしまうので、月に1回以上を最低ラインに目指すといいと思います。</li>
</ul>
<p>よき技術ブログLifeを!</p>ynishihttp://www.blogger.com/profile/13212382728793556793noreply@blogger.com0tag:blogger.com,1999:blog-1001880134048556583.post-73979937516117207842016-12-06T22:17:00.000+09:002017-03-02T13:27:46.554+09:00Haskellでログパーサを書く時の参考記事
<p>Haskellでログ解析をしたいときに、こちらの記事が参考になります。</p>
<p><a href="http://delihiros.hatenablog.jp/entry/2012/06/12/174635">Parsec を使って Apache のログファイルをパースしてみる</a></p>
<p><a href="http://delihiros.hatenablog.jp/entry/2012/06/12/185344">Parsec を使って Apache のログファイルをパースしてみる2</a></p>
<p>内容は、ApacheログをParsecを使ってパーサを作ってレコードシンタックスのデータとして読み込むところまでをステップバイステップで解説しています。</p>
<p>ログを解析するような処理は、awkなどのコマンド/PythonなどのLL言語と、正規表現を使うのが一般的だと思います。</p>
<p>そこでHaskellでパーサを使うメリットが、この文章に集約されてます。</p>
<pre><code>このスクリプトを Python が書いた時、正規表現を用いてパースをしました。すると、コーディングに時間がかかり、また使っている間はずっとバグに出会う羽目になりました。しかし、 Haskell はもっとよい方法を提示してくれています。正規表現を用いるより、 Parsec ライブラリのパーサコンビネータを使いましょう。 小さなパーサをつなげて大きなパーサにするという Parsec のアイデアは、対象物が何であるかを一歩一歩確実に定義していくことを可能にしています。</code></pre>
<p>Haskellもできあがりのコードをいきなり見ると、難しい場合もありますが、小さく簡単なものから作っていけば十分理解できます。</p>
<p>Haskellを始めたばかりの人にもおすすめです。</p>
<p>現行のGHCでは動かないコードがあったので、同じくコンパイルできない方は、以下のコードを試してみるといいと思います。</p>
<p>2の最後の2つのコードの箇所です。</p>
<pre><code>main = do
file <- readFile "logfile.txt"
let logLines = lines file
let result = map (parse line "(test)") logLines -- result::[Either ParseError String]
mapM_ (either print print) result</code></pre>
<p>記事に記載のこちらだと、</p>
<pre><code>result <- mapM (parse line "(test)") logLines</code></pre>
<p><code>mapM...</code>の戻り値が<code>IO (...)</code>でないといけないのですが、実際には、<code>Either ...</code>となってしまいます。</p>
<p>説明が丁寧でとてもいい記事なので、ぜひお試しください。</p>
<p>よきHakellライフを!</p>ynishihttp://www.blogger.com/profile/13212382728793556793noreply@blogger.com0tag:blogger.com,1999:blog-1001880134048556583.post-77810423249210377802016-11-20T10:23:00.000+09:002016-11-20T10:23:51.230+09:00Google App Engine/Go(Go apps on App Engine) でWEBアプリを作るために<ul>
<li>2015年にGoがサポートされ、最近東京リージョンが発表されるなどGAEの取り巻く環境は、改善されてきています。また、AWS Lambdaのような、Paas的なサービスがリリースされPaas的なサービスが増えてきています。</li>
<li>Paasの古参GAE/GO でWebアプリを作るための情報収集をしました。</li>
</ul>
<h3 id="概要">概要</h3>
<p>まずは公式から</p>
<p><a href="https://cloud.google.com/appengine/">公式GAEのサービス概要</a></p>
<pre><code>Google App Engine は拡張可能なウェブ アプリケーションとモバイル バックエンドを作成するためのプラットフォームです。App Engine には、NoSQL データストアや Memcache、ほとんどのアプリケーションで使用されているユーザー承認 API など、さまざまな API と組み込みサービスが用意されています。
App Engine は、受信したトラフィック量に応じて自動的にアプリケーションを拡張するので、未使用のリソースに対して費用が発生することはありません。 コードをアップロードするだけで、Google がアプリの可用性を管理します。サーバーのプロビジョニングやメンテナンスを行う必要はありません。</code></pre>
<p>まとめると↓</p>
<h4 id="コンセプトと機能">コンセプトと機能</h4>
<ul>
<li>スケーラビリティとアベイラビリティ</li>
<li>Web/MobileアプリプラットフォームのPAAS</li>
<li>(Webアプリのスタックで)Httpサーバレイヤー以下を提供</li>
<li>加えて、認証など通常アプリサーバレイヤーで実現する機能も提供</li>
</ul>
<p>ざっくりとしたイメージだと、Javaでいうサーブレットレベルのところまで独自開発したPAAS。特定の用途に特化したため、DBやキャッシュ、ロードバランシングなども全て独自のものを作ってある。また、一般的なレイヤーにとらわれず、認証など必要なものは入れた感じです。</p>
<h4 id="コストが下がる要素">コストが下がる要素</h4>
<ul>
<li>インフラの物理的なコスト</li>
<li>インフラ構築・運用コスト</li>
<li>インフラ設計コスト(※GAEの構成を理解して適切な設定をする必要はあるが、従来に比べれば低い)</li>
</ul>
<h4 id="コストが上がる要素">コストが上がる要素</h4>
<ul>
<li>GAEの構成を理解する必要がある
<ul>
<li>HTTPサーバの特性、負荷分散のしくみなど</li>
<li>HTTPSやドメイン関連で実現できないことがある</li>
</ul></li>
<li>GAEの各サービスを理解する必要がある
<ul>
<li>NoSQL(Datastore), Memcacheなど</li>
</ul></li>
<li>GAEの開発手法を理解する必要がある
<ul>
<li>開発環境、テストフレームなど</li>
</ul></li>
<li>(上記特性を生かした)GAE向けの設計にする必要がある</li>
<li>情報が古い場合がある。最新の情報は1次情報を確認する</li>
</ul>
<h3 id="情報源">情報源</h3>
<ul>
<li><a href="https://cloud.google.com/appengine/docs/go/">公式 Google App EngineドキュメントGo</a>チュートリアル、ガイド、リファレンスなど一通り揃っている</li>
<li><a href="https://www.amazon.co.jp/%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0-Google-App-Engine-Sanderson/dp/4873114756">プログラミングGoogle App Engine</a>GAEのコンセプトとはまりどころがよくまとまってる。GAEは、一般的なWebアプリをクラウド化したサービスでは「ない」ことが技術的な観点で書いてあって、Webアプリエンジニアにとっては、違いが明確になって理解しやすい。Goの説明はない。</li>
<li><a href="http://write.kogus.org/articles/Y2Rtpp">2016年半ば現在のGoogle App Engine</a> GAEの歴史と経緯</li>
</ul>
<p>GAEの書籍は他にもいくつか出ているので、1冊手元にあるといいと思います。</p>
<p>また、ネット記事は2013年くらいまでのが多いですが、大体出てくるので、個別のトピックに関しては、都度検索する方が良さそうです。</p>
<h4 id="sample">Sample</h4>
<ul>
<li><a href="https://cloud.google.com/appengine/docs/go/tutorials">公式チュートリアル</a> 一通り触って動かせる。</li>
<li><a href="https://cloud.google.com/appengine/docs/go/tools/using-local-server">公式How-to Guides Developing Go Apps on App Engine</a> GAEのドキュメントを開くと左メニューにハウツーガイドが表示される。そこのDeveloping~の中にテストの仕方などがある。</li>
<li><a href="http://write.kogus.org/articles/laszmL">Google App EngineとGoでブログ風CMSを自作する</a> 実際に開発する際のライブラリなどの紹介があるなど非常に実践的です。</li>
</ul>
<h3 id="実際に">実際に</h3>
<p>GAEは特定用途に特化したGoogleらしいサービスです。確かにゲームなど想定するアクセス数のレンジがかなり広い場合は有効だと思います。</p>
<p>GAEの紹介ケースで、メディアなど突発的ににアクセスが増えた場合に自動でスケールするというのがあります。GAEが出た当初はそうかもしれませんが、現在は状況によりけりかと思います。上記の本にもありますが、GAEはサーバ1台でまかなえなくなったときに真価を発揮するですが、Iaasのバランシングの制御も今はかなり楽に柔軟にできるので。</p>
<p>実際に開発する場合は、GAEの設計モデルとDatastore(GAE向けに開発されたKVS)、各種API群をよく理解して使いこなすのが肝です。</p>
<p>AWSのLambdaでもそうですが、Paasでは設計モデルと各種サービスとの連携の理解が不可欠です。従来のWEBフレームワークを使うのと同様に、しっかりと習熟するレベルになっておけば、モデル自体はシンプルなので開発効率が高まります。</p>
<p>単純にWebアプリを作るだけならば、得意なWAF+Iaasで作った方が簡単です。 また、PaasだとOSSではないため、動作がわからないときは、ソースを見るのは通じないですね。</p>
<p>「得意なWebアプリ開発プラットフォームにGAEを加えよう」という考え方で取り組む方が、しっくりきそうです。</p>
<p>ではよきGAEライフを!</p>ynishihttp://www.blogger.com/profile/13212382728793556793noreply@blogger.com0tag:blogger.com,1999:blog-1001880134048556583.post-79269526628450805362016-11-16T00:01:00.000+09:002016-11-16T00:01:35.807+09:00要約サービスflierを使ってみました
<p>サービスの概要は、以下です。 <a href="https://www.flierinc.com/docs/services">公式サイト サービス紹介</a></p>
<pre><code>「本の要約サイトflier フライヤー」は、多忙なビジネスパーソンが本の内容を効率的につかむことで、ビジネスに役立つ知識・教養を身に付け、スキルアップにつなげることができます。具体的には、新規事業のアイデア、営業訪問時のトークネタ、ビジネストレンドや業界情報の把握、リーダーシップ・コーチングなどです。</code></pre>
<h3 id="いくつか無料プランの本を読んでみました">いくつか無料プランの本を読んでみました。</h3>
<p>無料プランには、最近の本ばかりでなく、孫子や、利己的な遺伝子など古典的な作品もあって、読んだことのある本がどのレベルで要約されるのかがつかめます。</p>
<p>このチョイスはかなりいいと思います。</p>
<p>一通り使ってみた感想はこちらです。</p>
<ul>
<li>数行の要点 => 著者紹介 => 要約者レビュー => 要約 となっていて、最短3分もあれば概要がつかめる。</li>
<li>出版社と連携。プロのライターの要約。質が高い。</li>
<li><p>本をよく読む人なら割安と思います。</p>
<pre><code>ゴールドプラン(月額2,000円(税別))
毎月20~30冊新たに追加される要約が読み放題。さらに、これまでに掲載した要約についても制限なく読んでいただくことができます。</code></pre>
<pre><code>シルバープラン(月額500円(税別))
これまでに掲載された要約のなかから、ひと月当たり5冊まで閲覧可能。閲覧した5冊については、翌月以降も何度でも読むことができます。
(過去に閲覧した要約は、当月の閲覧数に含めません。ただし、ゴールドプランからシルバープランに変更した場合、ゴールドプランご契約時に閲覧した要約であっても、1冊お読みいただくたびに当月の閲覧可能数が1冊分減ります。)</code></pre></li>
</ul>
<p>専門書や技術書など、自分のホームグラウンドの本は、相応の時間をかけても読み込みますが、専門分野外の時事的な話や新刊は、流し読みで済ませてしまうことも多いと思います。</p>
<p>そういった流し読みの代わりに、要約で内容をつかむのは効率面では、かなりいいと思います。</p>
<p>気にいった本があれば、購入して読み込むことができます。</p>
<p>要約者レビューや、この本を読むべき理由など、購入したくなったときの最後の一押しをしてくれる紹介もしっかりあります。</p>
<h3 id="技術者としてはsafari-onlineがほしい">技術者としてはSafari Onlineがほしい</h3>
<p>オライリーを中心とした技術書が月額40ドル程度で、無制限に読めるSafari Online。英語版のみです。</p>
<p>技術者としては、書籍関連のサービスで、一番日本語化してほしいサービスですね。</p>
<p>あとは、論文形式で数10ページレベルの書籍を集めたサービスがあるとうれしいです。</p>
<p>flierの要約よりも一歩踏み込んだ内容で、30分程度で読めて、数百円程度で、水増しのエピソードなどがないエッセンスのような書籍を集めたサービスです。</p>
<p>kindleの低価格書籍はそうなってきてるような気がします。</p>
<p>時間は有限なので、効率的に情報収集したいですね。</p>
<p>よい読書ライフを!</p>ynishihttp://www.blogger.com/profile/13212382728793556793noreply@blogger.com0tag:blogger.com,1999:blog-1001880134048556583.post-67413046012728814522016-11-13T21:13:00.000+09:002016-11-13T21:13:40.506+09:00Haskell MTL(モナドトランスフォーマーライブラリ)の資料のまとめ<p>MTLを使うための資料を整理しました。</p>
<p>集めた資料を見てみると、まずは、モナド、モナドトランスフォーマーをよく理解して、ライブラリの各モナドを一つ一つ使えるようにするという流れがよさそうです。</p>
<p>モナドトランスフォーマーの記事を探すと、モナド自体はわかっている前提の記事が多いので、モナドになれていない場合は、モナドからやった方がいいと思います。</p>
<p>モナドは、実装だけを考えると、単なる型クラスにすぎません。Haskellの実装上は、モナド則を満たしてなくても使用できます。</p>
<p>まずは、モナドクラスの仕様をみて、実際にいくつかサンプルを作ってみてから、モナド則をみるといいと思います。</p>
<p>ここでは、ネットの記事をまとめましたが、手元にある本のモナド・モナドトランスフォーマーの箇所をしっかり読み込んでわからないところは解説記事を参照する方が、よく理解できると思います。</p>
<ul>
<li><a href="https://www.amazon.co.jp/%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0Haskell-Graham-Hutton/dp/4274067815">プログラミングHaskell</a>は、シンプルでモナドの解説がしっかりしていて、haskellの入門におすすめですが、モナドトランスフォーマーの説明がないのでそこは他の資料が必要です。</li>
<li><a href="https://www.amazon.co.jp/%E3%81%99%E3%81%94%E3%81%84Haskell%E3%81%9F%E3%81%AE%E3%81%97%E3%81%8F%E5%AD%A6%E3%81%BC%E3%81%86-Miran-Lipova%C4%8Da/dp/4274068854/ref=cm_cr_arp_d_product_top?ie=UTF8">すごいHaskell楽しく学ぼう</a>モナドの解説が懇切丁寧です。プログラミングHaskellは、Functor, Applicativeなどの説明はないですが、こちらはそれぞれの関係が詳しく載っています。ただ、モナドトランスフォーマーの説明はありません。</li>
<li><a href="https://www.amazon.co.jp/%E9%96%A2%E6%95%B0%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E5%85%A5%E9%96%80-_Haskell%E3%81%A7%E5%AD%A6%E3%81%B6%E5%8E%9F%E7%90%86%E3%81%A8%E6%8A%80%E6%B3%95_-Richard-Bird/dp/427406896X/ref=pd_cp_14_3?_encoding=UTF8&psc=1&refRID=ANRPT86P3Q7VSQ0BR50X">関数プログラミング入門 ―Haskellで学ぶ原理と技法</a>こちらは、モナドトランスフォーマーの説明があります。</li>
</ul>
<p>ライブラリの紹介記事は<code>MTL</code>で検索してもなかなか出てこないので、<code>Control.Monad.State</code>など具体的なモジュール名で検索する方がよさそうです。</p>
<p>今回は、State, Reader, Writerの紹介記事をまとめました。</p>
<h3 id="mtlモナドトランスフォーマー全般">MTL、モナドトランスフォーマー全般</h3>
<ul>
<li><a href="https://wiki.haskell.org/Monad_Transformers">Monad Transformers</a> Monad トランスフォーマーライブラリのまとめと、モナドトランスフォーマーの関連記事のリンク。この中でMTLが主要ライブラリの一つとして紹介されている。</li>
<li><a href="https://wiki.haskell.org/Monad_Transformers_Explained">Monad Transformers Explained</a> モナドトランスフォーマーの説明。</li>
<li><a href="http://catamorph.de/publications/2004-10-01-monad-transformers.html">Monad Transformers Step by Step</a> モナドトランスフォーマーの使い方。日本語訳あり。</li>
<li><a href="https://wiki.haskell.org/All_About_Monads">All About Monads</a> モナドとモナドトランスフォーマーのチュートリアルと主要なモナドインスタンスを一通り紹介。</li>
<li>他は、MTLとTransformersどちらを使うかの議論ページ。</li>
<li><a href="https://hackage.haskell.org/package/mtl">The mtl package</a> hackageのページ。パッケージ状況について詳しい。mtlの公式情報はここから。</li>
<li><a href="https://github.com/ekmett/mtl">MTLのリポジトリ</a> Githubのリポジトリ</li>
<li><a href="http://web.cecs.pdx.edu/~mpj/pubs/springschool.html">Functional Programming with Overloading and Higher-Order Polymorphism</a> monadトランスフォーマーの基礎理論。</li>
</ul>
<h3 id="control.monad.state">Control.Monad.State</h3>
<ul>
<li><a href="http://d.hatena.ne.jp/bellbind/20060509/1147148363">Haskell: Control.Monad.Stateメモ</a> Control.Monad.Stateの解説。</li>
<li><p><a href="http://qiita.com/lotz/items/503ef04b03433d29f77c">Stateモナドが便利に使えた!</a> 実際のコードがたくさんのってる。</p></li>
<li><p><a href="http://jutememo.blogspot.jp/2009/10/haskell-state-1.html">Haskell の State モナド</a> 説明が丁寧。</p></li>
<li><p><a href="http://itpro.nikkeibp.co.jp/article/COLUMN/20070109/258229/">第6回 局所的な「状態」を利用するためのStateモナド</a> こちらも説明が詳しい。</p></li>
</ul>
<h3 id="control.monad.readercontrol.monad.writer">Control.Monad.Reader/Control.Monad.Writer</h3>
<ul>
<li><a href="http://itpro.nikkeibp.co.jp/article/COLUMN/20090303/325807/">第29回 グローバル変数の代わりに使えるReaderモナドとWriterモナド</a> 説明が詳しい。</li>
<li><a href="http://yu-i9.hatenablog.com/entry/2014/11/19/235007">Haskellで大域変数が欲しい時はReaderモナドを使いましょう</a> 実際の使いどころ。シンプルでわかりやすい。</li>
<li><a href="http://www.geocities.jp/m_hiroi/func/haskell18.html">お気楽 Haskell プログラミング入門 モナド (2)</a> 再実装して理解を深める。</li>
<li><a href="http://qiita.com/7shi/items/2e9bff5d88302de1a9e">Haskell 状態系モナド 超入門</a>モナドの説明</li>
</ul>
ynishihttp://www.blogger.com/profile/13212382728793556793noreply@blogger.com0tag:blogger.com,1999:blog-1001880134048556583.post-39767065139505910302016-11-12T12:44:00.000+09:002016-11-12T12:46:47.312+09:00HaskellでmonadTのあとはMTL
<p>金曜日、会社の同僚とその友人とご飯を食べてきました。 全員アプリエンジニアで、特に同僚の友人のエンジニアは、Haskellエンジニアでした。</p>
<p>Haskellはモナドトランスフォーマーをやったところで止まっていたのですが、その話をすると、アドバイスをしてくれました。</p>
<h3 id="mtl-をやれば一通りのことはできるよ">MTL をやれば、一通りのことはできるよ</h3>
<p><a href="https://hackage.haskell.org/package/mtl-2.2.1">MTL</a>は、モナドとモナドトランスフォーマーでよく使う処理をまとめたライブラリです。</p>
<p>モナド系の標準ライブラリのデファクトとなっているそうで、本格的なHaskellプログラムを書くときはもちろん、最近のライブラリでよく使われているので、読むときも楽になるということでした。</p>
<p>なので、ここまで頑張ってマスターすれば、やりたいことは大体haskellで実装できるようになるよと言われました。</p>
<p>見てみると<code>Control.Monad</code>にある各種モナドとモナドトランスフォーマーです。</p>
<p>確かにReader, Writer, Errorなど使いでがありそうなモナドがそろってます。</p>
<p>モナドトランスフォーマーを勉強すると、どこかで使ったことはあると思います。</p>
<h3 id="haskell熱が戻ってきました">Haskell熱が戻ってきました</h3>
<p>他にもNIXOSの話や、GHCの言語拡張、さらには、Haskellなどのプロダクションとしては、少数派だが、強力な言語を導入するにはどうすればいいかという話題なども出て刺激的でした。</p>
<p>プロダクションレベルだと、GHCの拡張も厳選した20〜30個くらいを設定しているそうです。</p>
<p>ただ、このあたりの話はリファレンスくらいしかないらしく、Haskell力がはっきりとでてしまいますね。</p>
<p>最近は、Elixirばかりでしたが、次のステップが見えたので、Haskell熱が復帰してきました!</p>
<p>よきモナドライフを!</p>ynishihttp://www.blogger.com/profile/13212382728793556793noreply@blogger.com0tag:blogger.com,1999:blog-1001880134048556583.post-49159451788961597222016-10-12T23:07:00.000+09:002016-10-12T23:07:06.983+09:00質問をストーミングする「Qストーミング」<p>アイデアを出したり、課題について考えたりするとき、ブレインストーミングはごく一般的に使われていると思います。</p>
<p>ブレインストーミングのメリットは、グループでアイデアを出すことでアウトプットの質が高まることです。</p>
<p><strong>Q思考 シンプルな問いで本質をつかむ思考法</strong> は、「質問」を仕事や生活に生かそうという内容の本ですが、この本によると、ブレインストーミングにも弱点があるそうです。</p>
<ol style="list-style-type: decimal">
<li>他人がいることがプレッシャーになり、つい当たり前な結論に収束しがち</li>
<li>アイデアが発散しすぎて、収拾がつかなくなる</li>
</ol>
<p>確かに思い当たる節はありますね。</p>
<p>この本で代わりに紹介されているのが、質問をストーミングする「Qストーミング」です。</p>
<h3 id="qストーミング">Qストーミング</h3>
<p>このQストーミングは、実際に研究も進んでいるそうで、この方が良い結果につながるという研究もあるとのこと。</p>
<p>理由としては、</p>
<ul>
<li>アイデアを出すより、疑問を出す方が簡単</li>
<li>疑問、質問は他人の評価を受けにくい(プレッシャーになりにくい)</li>
<li>間違った問いに答えようとするのを避けられる</li>
</ul>
<p>ということです。</p>
<p>やり方はシンプルです。ブレインストーミングの要領で、アイデアの代わりに質問をどんどん出すことです。</p>
<p>進め方の方針としては、</p>
<ul>
<li>とにかく数を出す(50〜70くらいらしい)</li>
<li>クローズド<=>オープンの変換を繰り返し、質を高める</li>
<li>討論を通じて、「ベスト・クエスチョン」(2〜3個)を決める</li>
</ul>
<p>良い質問があると、調べてみたくなるのが人間心理だそうで、そういう質問を見つけるのがゴールだそうです。</p>
<h3 id="まずは一人でやってみました">まずは一人でやってみました</h3>
<p>ミーティングなどで使う前に、どのような感じかやってみました。</p>
<ol style="list-style-type: decimal">
<li>テーマを用意</li>
<li>10分くらい質問をストーミング</li>
<li>出した質問をブラッシュアップ</li>
</ol>
<p>最初こそ、ちょっと出しにくかったですが、すぐにたくさん出てきました。</p>
<p>一つの質問を出すと、それについて考えて、さらに質問が湧いてきます。新しいことを知ると、頭の中で次々疑問が湧いてくるのと同じ感じです。それを書き出していくと、頭の中で考えてるよりも、堂々巡りにならず、どんどん先に進んでいきます。</p>
<p>そのテーマについて、多角的に考えることになるので、その問題自体に対する理解が深まりました。的確な質問をするには、問題のポイントをつく必要があるので、その問題自体をよく考えることになります。それだけでもかなり効果はあると思います。</p>
<p>普段なかなか答えが出しにくいような問題に向いていますし、アイデアが煮詰まった時など、一人でやるのもオススメですのでお試しください。</p>ynishihttp://www.blogger.com/profile/13212382728793556793noreply@blogger.com0tag:blogger.com,1999:blog-1001880134048556583.post-73696437357801492792016-10-10T20:26:00.001+09:002016-10-10T20:26:15.181+09:00Google DevFest Tokyo 2016 に行ってきました<p>1000人を超える申し込みがあったようで、午後から雨が上がったこともあり、かなりの人出でした。</p>
<p>DevFestはこんな感じのイベントです。</p>
<pre><code>DevFest は、Google Developer Group (GDG) コミュニティによって世界各地で開かれるデベロッパー向けイベントです。DevFest Tokyo 2016 は、普段は別々に活動している複数のコミュニティが集まり、新しいノウハウや最新情報を共有するだけではなくコミュニティやプロダクトを超えた交流の場となる「技術者の祭典」となることを⽬指して開催されます。どうぞみなさんも一緒に盛り上がりましょう!</code></pre>
<p>対象はどちらかというと、初心者向けと、最近のGoogleの動向が多かったです。 各発表が基本20分だったので、一通り表面をなぞるのにはちょうど良かったです。</p>
<p>Android関連が半分以上あり、特にFirebaseの話題が多かったです。</p>
<p>普段GCPしか触ってないので新鮮でした。</p>
<p>GCPはGCPUGが1会場を通してやっていました。</p>
<h3 id="気になった話題">気になった話題</h3>
<p>ざっくりですが、気になった話題です。GCPばかりです。</p>
<ul>
<li>GCPのIaasの強化
<ul>
<li>サブネット対応</li>
<li>Google Cloud SQL v2</li>
</ul></li>
<li>GCEでPerconaクラスタ最強説
<ul>
<li>インスタンスは安いし、性能は良いし、Perconaならクラスタリングも楽。</li>
<li>バックアップなどの運用系は用意する必要あり。</li>
</ul></li>
<li>Cloud Machine Leaning
<ul>
<li>Tensorflowのマネージド</li>
<li>別の環境で学習させたTensorflowのモデルをそのまま使える</li>
<li>これまでクラスター立ち上げてた必要がなくなるか?</li>
</ul></li>
<li>プリエンティブルVM
<ul>
<li>GAE + キュー+ プリエンティブルでクラスター作れば、安価にかなりのコンピューティングができる</li>
<li>Firebaseと組み合わせれば、モバイルのサービスに。</li>
</ul></li>
<li>GAEが枯れてきた
<ul>
<li>GAEの機能強化は落ち着いた。</li>
<li>GCPの各種サービスとの連携は強化。</li>
<li>GCPのフロントとしての地位を固めてる。</li>
</ul></li>
<li>GKE
<ul>
<li>最小構成(3台)でも十分使える。</li>
<li>構成管理もまとめてできるのが良い。</li>
</ul></li>
</ul>
<h3 id="日本androidの会">日本Androidの会</h3>
<p>基本、GCPの話ばかり聞いてたのですが、このセッションだけ、Androidの話を聞きました。</p>
<p>Androidは随分裾野が広いですね。 教育の話は、実践の中で作り上げたプラクティスの話でした。</p>
<p>例えば、「他人に教える」が最も教育効果が高いとかの話は聞いたことある方が多いと思いますが、それを実践して、さらに、ならではのノウハウを取り入れているのでとても参考になりました。</p>
<p>エンジニアのスキルアップといえども、楽しいというのは重要ですね!</p>
<pre><code>ROOM A 15:30-16:10</code></pre>
<pre><code>TensorFlow on Android
古川 新
日本Androidの会 学生部</code></pre>
<pre><code>メイドさんと一緒に楽しく学ぶ、ソフトウェア技術者教育方法論
鈴峰 きり
日本Androidの会 /株式会社テクモード</code></pre>
<p>全て参加費無料ということで、各ユーザグループと電気大の学生さん?のボランティアの方がかなり参加していたようです。このような大規模なものになると相当大変かと思います。ありがとうございました!</p>ynishihttp://www.blogger.com/profile/13212382728793556793noreply@blogger.com0tag:blogger.com,1999:blog-1001880134048556583.post-53585613160728142372016-10-08T21:03:00.000+09:002016-10-08T21:03:09.693+09:00GCPUG Beginners Tokyo で LTしてきました。<p>先週の金曜日(2016/10/7)に渋谷道玄坂のロフトワークさんで行われた<a href="http://gcpug-bt.connpass.com/event/41025/">GCPUG Beginners Tokyo #1</a>でLTしてきました。</p>
<p>当日は、GASエキスパートのサントリーさん(<span class="citation">@soundTricker318</span>)が、メインのハンズオンを担当され、その後の懇親会のLTセッションの一人として参加しました。</p>
<p>GCPを使い始めた方が対象のハンズオンということで、<strong>bdutil</strong> を使ってクラスター構築など試してはどうでしょうか?という内容で話してきました。</p>
<p>資料は、SpeakerDeckで公開しています。</p>
<p><a href="https://speakerdeck.com/ynishi/bdutilde3dda-hadoopdeisutoribiyutaitukishi-si">bdutilで3d大Hadoopディストリビュータイッキ試し</a></p>
<h3 id="bdutilとdataproc">bdutilとDataProc</h3>
<p>サントリーさんに、「bdutilの日本語情報はほとんどないので貴重なLT笑」とおっしゃっていただいたり、LTの後には、DataProcとbdutilどちらがいいの?という話にまで発展したりと会を盛り上げるのに多少なりとも役に立ったようでよかったです。</p>
<p>その時の話をまとめると、Hadoopクラスタをマネージド的に使いたい時はDataProcで、Iaas的に使いたい時は、bdutilが良いというところです。</p>
<p>DataProcは、Googleの各種サービスをフル活用したクラスターを立ち上げることができ、スムーズにアプリが完成するのに対し、bdutilは、簡単にディストリビュータの提供するHadoopクラスタが立ち上がりますが、それを使って何をどうするかは、ユーザに任されています。</p>
<p>Hadoopsディストリビュータのそのままのクラスタが欲しい時や、既存のDataProcでは、対応できないレベルのチューニングやアーキテクチャを採用したい時はbdutilの方が向きそうです。</p>
<h3 id="ハンズオンのクオリティが半端なかったです">ハンズオンのクオリティが半端なかったです</h3>
<p>ハンズオンの資料(一部GCPの入門用の資料参照)が非常に秀逸でした。</p>
<p><a href="https://goo.gl/jO4ELe">Google Cloud Platform ハンズオン</a></p>
<p><a href="http://goo.gl/ua5fQw">簡単スタートアップガイド</a></p>
<p>多少画面が変わっているとかはあったのですが、とにかく1ステップ1ステップが丁寧で、はまりようがないと言っていいくらいわかりやすいものでした。</p>
<p>今回のテーマである、<code>GoogleCloudComputing</code>の他に<code>BigQuery</code>なども含んだ資料ですが、総ページ数は、300ページをに迫る分量です。</p>
<p>チューターとして待機していたのですが、サントリーさんのインストラクションのうまさもあって、ほとんど出番がない状態でした。</p>
<p>新しい技術をスムーズに導入するのは、相応のコストがかかりますが、しっかりやれば、必ずしも難しいものではないと思えました。</p>
<h3 id="gcpugの皆様のおかげです">GCPUGの皆様のおかげです!</h3>
<p>GCPUGさんのイベントにスタッフ参加したのは初めてでしたが、初心者の方でも気楽に参加できるゆるい雰囲気があってよかったです。</p>
<p>また、当日参加された方向けの無料クーポン(60日無料トライアルとは別のものです)が用意されていたりと至れり尽くせりでした。</p>
<p>GCPUGの皆様、特にこの会の発起人の安藤さんのおかげで、GCPを使ってみようという方がまた増えたと思います!</p>
ynishihttp://www.blogger.com/profile/13212382728793556793noreply@blogger.com0tag:blogger.com,1999:blog-1001880134048556583.post-26486086634503342282016-10-05T22:00:00.000+09:002016-10-05T22:00:06.637+09:00AWS Lambdaで既存のコードを走らせる時に検討したいこと<p>既存のコードをLambdaで走らせる際に、検討すべき項目をまとめました。</p>
<p>既存のコードを持っていこうとすると、「<strong>Java/Pythonだから、そのまま動くでしょ?</strong>」逆に、「<strong>既存コードは全部書き換えないとでつらい</strong>」の中間くらいの手間になります。</p>
<p>実際には、全体的な構成を変える必要があるので、新しく作り直す方がいいと思います。</p>
<p>ですので、以下は、どうしても既存コードを持っていく必要がある場合のみご参考に。</p>
<h3 id="lambdaの特徴">Lambdaの特徴</h3>
<h4 id="立ち位置">立ち位置</h4>
<ul>
<li>dockerなどコンテナーは、サービス単位で起動できるが、lambdaは、プログラム単位で起動できます。</li>
<li>マネージドなコンテナーの機能限定版と言えます。</li>
</ul>
<h4 id="コーディングはロジックに集中できる">コーディングはロジックに集中できる</h4>
<ul>
<li>Pythonの実行環境設定など、すべてLambdaがやってくれるので、ロジックに集中できます。</li>
</ul>
<h4 id="awsのイベントベースを学ぶ必要がある">awsのイベントベースを学ぶ必要がある</h4>
<p>lambdaを活用するなら、awsのイベントベースのやり方を学ぶ必要があります。</p>
<h3 id="プログラム上の影響">プログラム上の影響</h3>
<p>以下はJavaのバッチの例です。</p>
<p>既存コードを持っていくとすると、キッカーとなるshellが内部でJavaのプログラムを呼び出すような構成は割とあると思います。</p>
<pre><code>cron -> kicker.sh -> java program -cp ... -> read data file write ... -> check_output.sh</code></pre>
<p>この場合、lambda化で影響がある箇所は、これだけあります。 コンテナ化よりも変更箇所は多いと思います。</p>
<ul>
<li>cron(実行タイミングを管理)</li>
<li>kickerとなるシェル</li>
<li>javaへ渡すデータ作成をs3などにする</li>
<li>java内のread/write処理(ラップするなど)</li>
<li>ログ処理の変更</li>
<li>check_output.sh(エラー検知など)</li>
</ul>
<h3 id="開発の各工程への影響">開発の各工程への影響</h3>
<p>上記のように、アーキテクチャレベルで変更がかかるので、行程のほぼ全般に影響が出ます。</p>
<p>導入に関しては、できるだけ初期の設計段階で検討すべきです。</p>
<p>Lambdaの開発・テストは、サーバベースでやっていた時とは異なるので、その準備などにかかるコストも見込んでおく必要があります。</p>
<h3 id="まとめ">まとめ</h3>
<p>lambda化はプログラムの修正以外にも工数がかかります。</p>
<p>lambda化すれば定型的な処理がほとんどAWS上の設定にできるので、かなり簡潔になります。</p>
<p>上記のメリットと、コストを比較検討するとよいかと思います。</p>ynishihttp://www.blogger.com/profile/13212382728793556793noreply@blogger.com0tag:blogger.com,1999:blog-1001880134048556583.post-90503931488965420352016-10-01T18:00:00.000+09:002016-10-01T18:00:36.016+09:00Webアプリケーションサーバ構築時のチェックリスト
<p>Webアプリケーションサーバを構築する際にチェックしたいことをまとめました。</p>
<p>できるだけ簡潔にしたので、状況によって追加が必要な項目があると思います。</p>
<p>アプリの開発の詳細は含んでいません。開発が終わってもサービスインするまでには、プログラム開発以外で必要なことがたくさんあります。それらを主にリストアップしました。</p>
<p>ここ数年、<strong>DevOps</strong>が流行っていますが、開発を始める前に、運用を含めた全体像を考慮して開発・運用が連携するのは理想的だと思います。</p>
<p>また、最近はサーバーレス構成もあると思いますが、検討ポイントとしては多くの部分が共通すると思います。</p>
<h3 id="サーバ構築時のチェックリスト">サーバ構築時のチェックリスト</h3>
<ol style="list-style-type: decimal">
<li>進め方
<ol style="list-style-type: decimal">
<li>初回ミーティング
<ol style="list-style-type: decimal">
<li>参加者(開発、運用、ステークホルダー)</li>
</ol></li>
<li>スケジュール
<ol style="list-style-type: decimal">
<li>開発</li>
<li>外部テスト</li>
<li>告知</li>
<li>リリース</li>
</ol></li>
<li>担当者のアサイン
<ol style="list-style-type: decimal">
<li>全体の管理</li>
<li>開発・構築</li>
<li>外部連携</li>
</ol></li>
<li>情報の共有方法
<ol style="list-style-type: decimal">
<li>随時連絡する方法</li>
<li>定期ミーティング
<ol style="list-style-type: decimal">
<li>タイミング</li>
<li>参加者</li>
</ol></li>
</ol></li>
</ol></li>
<li>コスト項目
<ol style="list-style-type: decimal">
<li>インフラ調達(初期、ランニング)</li>
<li>開発コスト</li>
<li>運用コスト</li>
</ol></li>
<li>設計
<ol style="list-style-type: decimal">
<li>アプリ
<ol style="list-style-type: decimal">
<li>機能/非機能</li>
<li>デプロイ</li>
</ol></li>
<li>ログ
<ol style="list-style-type: decimal">
<li>出力内容</li>
<li>収集方法</li>
<li>ローテーション</li>
</ol></li>
<li>ハード要件</li>
<li>構成
<ol style="list-style-type: decimal">
<li>耐障害設計
<ol style="list-style-type: decimal">
<li>ロードバランサー</li>
</ol></li>
<li>セキュリティ
<ol style="list-style-type: decimal">
<li>SSL</li>
<li>アクセス制限</li>
<li>認証方法</li>
</ol></li>
<li>環境
<ol style="list-style-type: decimal">
<li>設置するネットワーク</li>
<li>ホスト名</li>
</ol></li>
</ol></li>
<li>構成管理
<ol style="list-style-type: decimal">
<li>ツール</li>
<li>構成設定の管理</li>
</ol></li>
<li>運用
<ol style="list-style-type: decimal">
<li>サービス保証のレベル</li>
<li>サポート体制</li>
<li>監視</li>
</ol></li>
</ol></li>
<li>構築・テスト
<ol style="list-style-type: decimal">
<li>アプリ</li>
<li>ミドル(Web, アプリサーバ)</li>
<li>ハード(インスタンス)</li>
<li>監視</li>
<li>外部との連携
<ol style="list-style-type: decimal">
<li>調整のフロー(担当者)</li>
<li>テスト手順</li>
<li>スケジュール調整</li>
</ol></li>
<li>リリース
<ol style="list-style-type: decimal">
<li>リリース方法</li>
<li>リリース後の確認方法</li>
<li>切り戻し方法</li>
</ol></li>
</ol></li>
</ol>ynishihttp://www.blogger.com/profile/13212382728793556793noreply@blogger.com0tag:blogger.com,1999:blog-1001880134048556583.post-42827508209361621792016-10-01T16:26:00.001+09:002016-10-01T16:26:47.482+09:00開発でわからないことがあった時の質問の仕方
<p>仕事で開発をしていると、他の人とコミュニケーションをとりながら進めることが多いと思います。</p>
<p>新しいプロジェクトに入った場合、先輩や周りの人に聞くスキルで仕事の進みが変わります。</p>
<p>整理されてない状態で質問すると、質問される方も何を答えればよいか判断できなく、お互いにやり取りが負担になります。結果、必要なことまで質問できないようになってしまうと更に悪い方向に行ってしまいます。</p>
<h3 id="聞くことのテンプレート">聞くことのテンプレート</h3>
<p>ということで、テンプレートにまとめました。</p>
<p>全くの新規案件でしたら、「動いているもの」はないかもしれませんが、実際、既存の修正などが多いと思うので入れました。</p>
<p>仕様が「まとまってない、メンテされてない」などの事情で使えない場合や、仕様読むよりソースの方が早くて確実などあると思うので、動いているものの確認以降は、ケースバイケースで順番が変わると思います。</p>
<pre><code># 案件があったら
## 何をやればいいのかを確認
要件はどこにありますか?
## 動いているものを確認(再現)
どのサービスですか?
どこで動いてますか?
ログはどこにありますか?
確認できる環境はありますか?
## 仕様を確認
仕様はどこにありますか?
(信頼性はどの程度ですか?)
## ソースコードを確認
ソースコードはどこにありますか?
(リポジトリの信頼性はどの程度ですか?)</code></pre>
<p>それぞれで、まずは「どこにあるか?」を聞くようにします。</p>
<p>どこにあるかが想像つかない状態だと、相当にロスが発生するためです。どこにあるかわかれば、それを調べて「わかる・わからない」だけです。</p>
<p>対象にたどり着いたら、調べます。</p>
<p>たどり着けなかったか、理解できない場合は、そこでストップして周りの人に聞きます。</p>
<p>「ここまではわかりました。これを調べてますが、わかりません。」と聞くと質問される方もどこまで分かっていてどこまで分かってないのかがわかり、何をどのレベルで答えればいいのか判断できるので答えやすいです。</p>
<p>手書きでもいいので、書いたものを持って行って見せながら言うとさらに確実になります。</p>
<p>全ての質問は、「この話は、誰に聞くのが一番ですか?」を入れて、適切な相手を探すステップを入れると更にいいと思います。</p>
<p>聞く方、聞かれる方お互いにスムーズにコミュニケーションとれるといいですね。</p>ynishihttp://www.blogger.com/profile/13212382728793556793noreply@blogger.com0tag:blogger.com,1999:blog-1001880134048556583.post-86289323679159989092016-09-28T15:00:00.000+09:002016-09-28T15:00:30.047+09:00Tomcatとクラウドサービスを組み合わせる場合のメモ<p>従来、ネットワークやミドルウェアで設定していた分野のクラウドサービスの充実に伴って、アプリサーバの構築方法も変わってきました。</p>
<p>AWSの<strong>api-gateway</strong>+<strong>lambda</strong>のような組み合わせでサーバレスにすることも可能です。</p>
<p>Tomcatなどもまだまだ現役ですので、今回は、Tomcatとクラウドサービスを組み合わせて作る場合のメモです。</p>
<h3 id="方針">方針</h3>
<ul>
<li>インフラ部分は、AWSなどクラウド基盤のサービスをできるだけ使う</li>
<li>基本的に、サーバはアプリのみを使い、できるだけシンプルにする</li>
</ul>
<h3 id="tomcatの設定">tomcatの設定</h3>
<h3 id="context">Context</h3>
<ul>
<li>基本、コンテキストパスは一個にする。</li>
<li><p>server.xmlで直指定。コンテキストxmlは、複数のコンテキストを複雑に使う場合。</p>
<pre><code><Server ...>
...
<Context path="/"
docBase="/opt/tomcat/html/ROOT" />
<Context path="/v1"
docBase="/opt/tomcat/html/v1" />
...
</Server></code></pre></li>
</ul>
<h4 id="web.xml">web.xml</h4>
<ul>
<li>上記のWEB-INFに直接設置</li>
<li>servlet-mappingでurlパターンとマッチさせる</li>
<li>対応するHTTPメソッドを設定する</li>
</ul>
<h3 id="httpサーバとの連携">HTTPサーバとの連携</h3>
<p>この辺りは、できるだけクラウドインフラで行う。</p>
<ul>
<li>ロードバランサ</li>
<li>SSL</li>
<li>ディレクトリ単位のアクセス制限</li>
<li>IP制限</li>
</ul>
<h4 id="nginx">nginx</h4>
<p>プロキシ設定</p>
<pre><code> server {
...
location / {
proxy_pass http://127.0.0.1:8080;
}
}</code></pre>
<p>リバースプロキシを設定するには、SELinuxの設定変更が必要. <a href="http://www.crystalsnowman.com/?p=723#i">nginx リバースプロキシ設定時の502 Bad Gatewayエラーを解消する方法</a></p>
<pre><code>setsebool -P httpd_can_network_relay=1</code></pre>
<p>他にも、ドキュメントルートの変更などSELinuxを変更する必要がある。</p>
<h3 id="その他">その他</h3>
<p>この辺りは、httpサーバでしておいた方が安心です。</p>
<h4 id="存在しないパス">存在しないパス</h4>
<ul>
<li>200で独自のエラーコードを持ったJSONを返す。</li>
<li>404エラーを返す</li>
</ul>
<h4 id="method-not-allowed">Method Not Allowed</h4>
<ul>
<li>許可メソッドを指定する。</li>
<li>200で独自のエラーコードを持ったJSONを返す。</li>
<li>405エラーを返す</li>
<li>nginxの444を使う。</li>
</ul>
<h3 id="死活監視">死活監視</h3>
<ul>
<li>死活監視用のページを表示させる.</li>
<li>example.com/check.html</li>
</ul>ynishihttp://www.blogger.com/profile/13212382728793556793noreply@blogger.com0tag:blogger.com,1999:blog-1001880134048556583.post-26377639959643723932016-09-28T00:49:00.000+09:002016-09-28T00:49:59.404+09:00Elixir/Phoenixを何度もインストールする時に
<p>少し前にインストールした、Elixir/Phoenixを再利用しようとしたら、動かないところがあったので、記事にします。</p>
<p>対応としては、<code>mix</code>の<code>phoenix</code>をリインストールします。ただし、以前構築した<code>phoenix</code>は動かなくなることがあります。</p>
<pre><code>mix archive.install https://github.com/phoenixframework/archives/raw/master/phoenix_new.ez</code></pre>
<p>以下は詳細です。</p>
<h3 id="phoenix_ecto-phoenix_htmlのエラー">phoenix_ecto, phoenix_htmlのエラー</h3>
<p>mixでプロジェクトを作成して、<code>mix phoenix.server</code>したところエラーが出ました。</p>
<pre><code>mix phoenix.new prj --database mysql
cd prj
mix phoenix.server</code></pre>
<p>依存性エラーが出ます。</p>
<pre><code>== Compilation error on file lib/phoenix_ecto/html.ex ==
** (CompileError) lib/phoenix_ecto/html.ex:7: unknown key :model for struct Phoenix.HTML.Form
(elixir) src/elixir_map.erl:185: :elixir_map."-assert_struct_keys/5-lc$^0/1-0-"/5
(elixir) src/elixir_map.erl:62: :elixir_map.translate_struct/4
could not compile dependency :phoenix_ecto, "mix compile" failed. You can recompile this dependency with "mix deps.compile phoenix_ecto", update it with "mix deps.update phoenix_ecto" or clean it with "mix deps.clean phoenix_ecto"</code></pre>
<p>mix.exsを以下のように変更したら依存性はOKになる。</p>
<pre><code>{:phoenix_ecto, "~> 3.0"},
{:mariaex, ">= 0.0.0"},
{:phoenix_html, "~> 2.6"},</code></pre>
<p><code>phoenix</code>をリインストールしてOKならば、上記のようにリインストールする。 ただ、リインストールすると、当然古いphoenixプロジェクトは動かなくなることがある。</p>
<h3 id="dev.exsの設定">dev.exsの設定</h3>
<p>つい忘れがちなconfig設定も行います。 localhostで動かないときは、<code>netstat -an | grep 3306</code>などで解放ホストとポートを確認すると良いです。 今回は、外部IPで開いていて、localhostでは通りませんでした。 mysqlクライアントからは、localhostで入れてもectoからはいけない時があります。</p>
<pre><code>config :word_prj, WordPrj.Repo,
adapter: Ecto.Adapters.MySQL,
username: "XXX",
password: "XXX",
database: "XXXDB",
hostname: "XXX.XXX.XXX.XXX",
pool_size: 10</code></pre>
<p>あとは、migrateして</p>
<pre><code>MIX_ENV=dev mix ecto.migrate</code></pre>
<p>起動します。</p>
<pre><code>mix phoenix.server</code></pre>
<h3 id="ページを追加">ページを追加</h3>
<p>ページ追加については同じコマンドで動きました。</p>
<pre><code># テンプレート作成
phoenix.gen.html Repos table col1:string col2:string
# DBにマイグレート
MIX_ENV=dev mix echo.migrate
# router追加
vi web/router.ex
scope "/", Prj do
pipe_through :browser # Use the default browser stack
get "/", PageController, :index
resources "/card", CardsController
end
# サーバー起動
mix phoenix.server</code></pre>
<p>今時、一つのサーバに複数のWEBアプリを入れることは稀なケースかと思いますが、一つのサーバに複数世代の<code>phoenix</code>を混在させる場合は注意が必要です。</p>ynishihttp://www.blogger.com/profile/13212382728793556793noreply@blogger.com0tag:blogger.com,1999:blog-1001880134048556583.post-5239190004709964442016-09-27T22:34:00.000+09:002016-09-27T22:34:07.897+09:00SOFT SKILLS ソフトウェア開発者の人生マニュアル を読んでいます<p><a href="https://www.amazon.co.jp/dp/B01GDS0994/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1">SOFT SKILLS ソフトウェア開発者の人生マニュアル</a></p>
<p>ざっくりというと、「20代でやっておきたいこと」のエンジニア版です。</p>
<p>実践的なエンジニア向けのキャリア指南書で、ここまでまとまっているのはなかなかないので、20代や新人のエンジニアの方、キャリアに悩んでいる方にぜひおすすめです。</p>
<h3 id="おすすめのポイント">おすすめのポイント</h3>
<p>この本は、エンジニアの特殊事情を踏まえて、人生の全方向的についてカバーしています。</p>
<p>例えば、テクノロジーに対するスタンスや、エンジニアにとってクリティカルなスキルと言える、学習についてもしっかりと書いてあります。</p>
<p>記述は全体的に簡潔で具体的ですぐに活用できる形に落ちています。</p>
<p>各項目の最後に、最初のワンステップ(これだけはやってみよう)というアクションプランが付いていて実践的です。</p>
<p>今ブログを書いているので、ブログについての箇所は特に気になりました。</p>
<p>アウトプットする第一歩としてブログはおすすめです。</p>
<p>エンジニアの方は、読んで損はないと思います。</p>ynishihttp://www.blogger.com/profile/13212382728793556793noreply@blogger.com0