はてなブックマーク

みんな大好きSlackですが、無料プランのままファイルをアップしていくとどんどん古いのが消されるのが悩みどころ。 そこでSlackにファイルがアップされたら自動でS3に移すBOT(しまっちゃうおじさんと命名)を作りました。 おとなしく有料プランにすればいいんじゃないすかねぇ... ※しまっちゃうおじさんとは 2016/09/30 githubにソースをアップしました。 Mic-U/putting_uncle 環境構築 一からBOTを作るのは辛いのでBotkitというフレームワークを使います。 また、SlackのAPIにアクセスするためのトークンをあらかじめ発行しておく必要があります。 その辺は↓の記事が非常にわかりやすく解説してくれています。 Slack の BotKit を使う : まだプログラマーですが何か？ 実装 controller追加 Botkitをインストールすると色々ファイル

プロローグ node --helpでnodeの起動オプションを見てみると、実はひっそりと--v8-optionsという初心者お断りオーラを醸し出しまくってるオプションがあります。 Node.jsの公式ドキュメントによると Print v8 command line options. Note: V8 options allow words to be separated by both dashes (-) or underscores (_). For example, --stack-trace-limit is equivalent to --stack_trace_limit. どうやらV8エンジンの起動オプションをnodeコマンドでも与えられるようです。 ついでに、「-」と「_」はどっちでもいいようです。 で、この--v8-optionsを駆使すればNode.jsのパフォーマンス

2017-06-22のアップデートでCodeBuildのビルド結果をCloudWatchEventsで捕捉できるようになりました。 そのままSNSで通知してもいいのですが、LambdaからIncoming Webhookを使ってSlackに通知してみようと思います。 事前準備 以下のことはすでに済んでいる前提で話を進めます。 CodeBuildのプロジェクト作成 SlackのIncoming Webhookの設定(URL発行) 実装 さくっと済ませたいのでServerlessフレームワークを使います。 serverless.yml設定 まあこいつを見てもらおうか service: notify-build-result provider: name: aws runtime: nodejs6.10 timeout: 180 stage: ${opt:stage, self:custom.d

紆余曲折の果てにたどり着いた私の開発環境をご紹介します。 あ、私は業務ではもっぱらNode.jsでexpressを使ったアプリを作ってますので、そのつもりで読んでください。 ファイルのパスとかは適宜お使いの環境に読み替えていただけると幸いです。 基本構成 実装に使っているのは下記になります TypeScript(AltJS 使い始めるともう生のjavascriptには戻れない) SCSS (CSSのメタ言語) Pug (テンプレートエンジン　商標の関係でJadeから改名された模様) これらで実装し、ファイルに変更があれば自動でコンパイル、TypeScriptに関してはWebpackでバンドル、 そして自動でブラウザリロードといった感じです。 Pugのウォッチ ウォッチはgulpで行います。 htmlへの変換とかはexpressのお仕事ですので、ここでは.pugの変更を検知してブラウザをリロ

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 2017-08-11にaws-sam-localのベータ版がリリースされました。 単に「早速試したで!」と言う記事を書いても良かったのですが、少し趣向を変えてサーバレス界隈の開発環境のこれまでの推移を語った上で、aws-sam-localの使ってみた感想もお話しようかと思います。 サーバレス開発環境の今昔 サーバレス自体がかなり最近になって生まれた風潮なので昔とか言うのも問題はあるかと思いますが、とにかくサーバレスなるものの開発環境について私にわかる範囲でお話しようと思います。誤りや不正確な点については編集リクエストやコメントを頂けると

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

version: "3" services: mysql: image: mysql ports: - 3306:3306 environment: MYSQL_ROOT_PASSWORD: root volumes: - ./containers/mysql:/var/lib/mysql adminer: image: adminer ports: - 8080:8080 links: - mysql app: build: context: . dockerfile: ./Dockerfile command: "bundle exec hanami server --host 0.0.0.0 -p 2300" volumes: - .:/app - ./containers/bundle_install:/app/vendor/bundle - ./containers/bundle

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

はじめに パッケージ管理にbowerを使っているプロジェクトがあったのですが、つい先日公式からこんな通達が... Add yarn and webpack recommendation from bower.io to readme Fixes #2298 これによって、bowerを使おうとすると ..psst! While Bower is maintained, we recommend yarn and webpack for new front-end projects! という不穏な警告が出るようになりました。 うーん、以前から「bowerはオワコン」みたいに言われてましたが、これは本格的に廃止すべきですねぇ。 bowerが絡むとwebpack2.0系がうまく動かなかったりしたし。 というわけで、bowerをやめてnpmに統合した流れと注意事項を記しておきます。 構成 件のプロジ

業務でExpressを触り始めてから1年ほど経ったので、私が思う「これはヤバい」をまとめておきたいと思います。 アンチパターンなので各見出しはやっちゃいけないことです。 みなさん真似しないように。ドミナントとの約束だ。 「サーバサイドもクライアントサイドもJavaScriptとか超楽じゃん」という考えでNode.jsに手を出す。 そもそも論として、Expressの中でのアンチパターンというか、プラットフォームを選ぶときに こんな考えでNode.jsを使おうとするのはヤバい というものです。 Node.jsに手を出した人の約9割(主観)がこういう思いから始め、そしてそのほとんどが「あ、これやっぱ別物だわ」となります。 まあ確かにjsなので文法は同じなんですけどね。 どちらもnpmからライブラリを引っ張ってこれるんですけどね。 結局サーバサイドとクライアントサイドを同じノリでできるわけがないん

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 春ですね。 全国各地で数多の新人プログラマが生まれたことでしょう。 新人のうちはわからないことだらけですし、真っ当な労働環境でしたら先輩方が「わからないことがあったら何でも聞いてやー」と言ってくれます。 ですので、プログラムが謎のエラーメッセージを吐き出したりしたらすぐに質問したくなるかと思います。 しかし、個人的な見解ではプログラマのスキルが最も鍛えられるのは、わからないことを前にして自分なりに色々と調べて試行錯誤する時です。 多分、世の中の凄い人たちの中には身近に質問できる相手がいなくてひたすら自分で頑張った結果、超進化を

はじめに もともと業務でscssを使うための環境を作ってたのですが、ちょっと後輩に丸投げしてた目を離した隙にwebpack周りも色々と状況が変わっていたので、これを機に色々調べ直して設定し直したりしました。 やりたかったこと webpackでscssをビルドする jsで出力されるのは困るのでcssで出力する ベンダープレフィックスは自動でつけてほしい -mozとか書きたくない リントチェック欲しいなぁ... まぁ、これはwebpackじゃなくていいか webpack2でのscssのビルド パッケージインストール まずは必要なパッケージを入れましょう。 今回scssのビルドに使ったパッケージは autoprefixer css-loader extract-text-webpack-plugin node-sass postcss-loader precss sass-loader styl

第一部 JavaScript、その起源 1995年 NetScape社のブレダン・アイク氏が開発 ポケモン赤・緑とタメ 最初はLiveScriptって名前だった 「Javaっていう言語が超ナウいらしいぞ」 1995年にJavaによるブラウザWebRunnerが、HotJavaという名で世界に公開 NetscapeがJavaのサポートを表明 今、Javaが熱い!! #「せや!名前もらったろ!」 改名 LiveScript -> JavaScript 第二部 スクリプト戦国時代 ライセンスの乱 1996年　MicrosoftがIE3.0を発表「JavaScript使わせてやー」 NetScape社「だが断る」 Microsoft「ほな勝手に作るわ」 => JScript誕生 各ブラウザベンダが独自言語を実装する戦国時代へ Webエンジニアは血の涙を流す 想像図 「JavaScriptってどうよ

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに コーディング規約を守り続ける、簡単そうでとても難しいことです。 数多の宗教論争の末に打ち立てられたコーディング規約が次第に形骸化していくのはとても悲しいことです。 なぜコーディング規約を守るのは難しいのか、形骸化させないためにはどうしたら良いか考えようと思います。 なぜコーディング規約を守れないのか 前述の通り、コーディング規約を守り続けるのはとても困難です。 明文化されていたとしても困難ですので、ましてや暗黙の了解のようになってしまっていたらもはや守るのは不可能でしょう。(暗黙的になっている時点で規約としては破綻していると思

はじめに サーバ一台で稼動するアプリでしたらサーバー内でセッション情報を持たせとけばいいですが、 サーバ複数台に対してELBでリクエストを振り分けるとかなるとそういうわけにもいかなくなります。 セッション情報のためにDBサーバとかRDSとかは仰々しいし、ファイルにしてS3に置くというのも微妙な気がしてたのですが、DynamoDBを使うモジュールがあったので使ってみました。 パッケージインストール 使うのは express-session connect-dynamodb の二つですので、 npm install --save express-session connect-dynamodb でさくっとインストール 余談 express-sessionはセッション情報の保存先に応じて必要なモジュールを追加でインストールするという形式をとっていて、 対応できる範囲はかなり広いです。 app.j

はじめてのGet Wild 駆動開発 先日発表されたAmazon Athenaを使えばWebサーバのログもそのまま分析にかけられるということなので、手始めにApacheのログを分析してどれだけGETでリクエストが来ているか調べてみました。 GETリクエストは即ちGet Wildリクエストです(暴論)。 下準備 Athenaで分析するためのログが必要ですが、自前でサーバを用意してログがたまるのを待ってると時間がかかるのでProcessing Logs in Hiveにあったサンプルデータを拝借しました。 サンプルデータ こいつをS3に放り込んでおきます。 今回はこのためにget-wild-athena161208というバケットを作り、apache-logsフォルダに保存しました。 バケット名はグローバルで一意である必要がありますが、日付を入れることで他の人もget-wild-athenaYY

はじめに こんにちは、先日投稿したソースコードの混沌はどこから這い寄るのかという記事が思いのほかストックされて浮かれ気味のMic-Uです。 そのときは「こうしようぜ！」と訴えるだけでしたので、今回は実際に戦った過程を紹介したいと思います。 今回扱うのはこれまた仕事で遭遇したカオスコードですが、先日の記事の投稿後に新たに発見されたものです。 その特徴は簡潔に言うとやたらとネストが深い。 ネストが深いのはカオスコードにはよくあることです。 ネストの深さがもたらす混沌 プログラミング経験者なら誰もが「ネストは深くしてはいけない(戒め)」と言われたことがあると思います。 本当に始めたばかりでそんなこと言われたこと無いという人も、いつか必ず言われます。 ていうか今私が言ってます。 戦いの記録に入る前に、改めてネストが深くなるとなぜいけないのか見つめ直しましょう。 物理的問題 ネストが深くなると視覚的

プロローグ エンジニアとして働いているなら、誰もが混沌に満ちた闇の深いコード、カオスコードに遭遇したことがあるだろう。 何をしているかわからない、何故こんな書き方をしているかわからない、しかし正常に動作しているらしいというブラックボックス。そして往往にしてそのようなカオスコードは密結合になっていて一度手を加えればどこにどのような影響を与えるかもわからない。故に放置され、時を経てさらなる闇を生み出す。そうなるともはや我々人類は立ち尽くすしかないのである。 しかし考えてみてほしい。悪意を持ってカオスコードを生み出すものなど存在しないはずである。 誰もが光差すコードを書こうと腐心しているはずである。 それなのに今日もどこかで新たな闇が生み出されている。 それは何故なのか。 実装した者のスキルや意識の低さのせいにして「クソがぁ!」と叫ぶのは簡単である。 しかしそれでは何の解決にもならない。 我々は

それでは前回宣言した通り、Elastic Beanstalkの設定ファイルを用いた環境構築の自動化をご紹介しようと思います。 はじめに 今回の大きなテーマは**.ebextensions**を使った環境構築の自動化です。 そのための題材として、ナウいWebアプリのHTTPS対応をやってみたいと思います。 SSL証明書はACMに登録しているものを使う前提です。 なので今回の内容としては .ebextensionsの作成 Elastic Beanstalkへのデプロイ Route53での名前解決 となります。 ナウい環境って? こんなの 事前準備 ACMへの証明書の登録 まず、「そもそもドメイン持ってないよ」という方は、Route53のコンソールから適当なドメインを取得してください。 手順はこの記事がわかりやすいかと思います。 実践 では、色々と設定を.ebextensionsに追記して行きま

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? みなさん、Elastic Beanstalkって使ってますか？ なんか設定する項目が多くて「もう普通にEC2立てた方が楽だわ」ってなる方が多いかと思いますが（多いですよね...?私はそうだったのですが...）、使ってみると後々の管理が超絶楽になるので、 ナウい構成のサンプルアプリを構築する手順を公開することで広めたいと思った次第です。 はじめに そもそもナウい構成って何よ? あくまで主観ですが、イメージ的にはこんな感じ ロードバランサーの下にEC2をぶら下げて、アプリ自体はDockerコンテナで稼働させ、nginxにリバースプロキシさせ

仕事でTypeScriptを書きながら「あ〜、真面目にドキュメント作るって面倒くさいよな〜」とか考えていたのですが、 そんな時に便利な素敵ツールTypeDocなるものがあったので使ってみたらとても捗りました。 TypeDocって何? TypeScriptのソースを解析してドキュメントを自動で作ってくれるツールです。まあ、jsdocのTypeScript版ですね。 jsdocより便利な点としては、アノテーションを書く必要がほぼありません。型情報とか全部ソースに書いてるんで。 jsdocのために @param {number} とか@classとかコメントで書くのダルいですよね。 人類はツールのためにコメントを書く責務から解放されつつあるのです。 使ってみた インストール TypeDocはnpmでインストールします。 npm install typedoc --save 個人的にグローバルイン

Node.js開発に欠かせないnpm install その中でもgulpやmochaみたいにコマンドから起動する類のものには-gオプションをつけることが多いかと思います。 ていうかサンプルとかだと普通に「-gつけてね」みたいな感じのノリです。 例:npm installでググってみたら上の方に出たやつ(注:リンク先の記事ではnpm install -g gulpとなってますが、2016-04-14現在公式でnpm install -g gulp-cliが推奨されています) しかし私は極力-gを使いたくないのです。ていうか全く使わなくていいのではとさえ思っています。 というわけで-gについて徒然なるままに心にうつりゆくよしなし事を書き綴ります。 なぜ-gが必要か そもそもなぜ-gが必要なのでしょうか。 -gをつけないとパスが通らないからですね。 gulpで試してみましょう。 当然「そんなコマ