最近は以下の組み合わせでLambda関数を書いている AWS Lambda (Node 4.3) Serverless Framework serverless-webpack + babel + eslint Yarn 参考 ベースは以下のリポジトリを参考にした。 https://github.com/americansystems/serverless-es6-jest package.json テンプレはこんな感じ。 { "name": "your-service", "version": "0.0.1", "dependencies": { "babel-polyfill": "^6.20.0", "babel-runtime": "^6.20.0", }, "devDependencies": { "babel-core": "^6.21.0", "babel-eslint":

ここから、DevとOpsが協力すればより効率的になる＝DevOps、という言葉が生まれました。 当時は大企業においてはDevとOpsが分かれていることが当たり前だったのです。そして、大企業における当たり前が、当たり前ではないことに気付き始め、DevOpsを実現するためのツールができ始めたころでもあります。 ではなぜ、大企業ではDevとOpsが分かれているのが当たり前だったのでしょうか？ ハードウェアの時代その昔、産業の主役はハードウェアでした。 そのため、多くの企業はハードウェアを作ることに対して最適化が行われました。 ハードウェアには研究開発、製造、運用サポートといった大きな区分けが存在します。そして、それぞれの仕事において要求する人材レベルは異なります。 加えて、大量生産された製品の運用サポート（設置作業員、サポートセンタ）には、大量の人員が必要になってきます。 したがって、組織を研究

SystemJSでAngular 2の環境を構築する SystemJSはwebpackやBrowserifyのようなJavaScriptファイルの依存関係を解決するためのモジュール管理ツールです。 Angular 2ではquickstartではSystemJSを利用したコンパイル環境を、Angular CLIではwebpackを利用したコンパイル環境を提供しています。 今回は用意されている環境を利用せずに0ベースでSystemJSの環境を構築していく方法を解説します。 （quickstartの設定内容を最小限にして順序立てて解説しています） package.jsonの作成 まずはターミナルなどで以下のコマンドを入力してpackage.jsonの作成を行います。 npm init -y ローカルサーバーの構築 SystemJSではAjaxでファイルの取得などを行うためローカルサーバーの設定が

こんにちは。 2016新卒でLobiのサーバーサイドエンジニアをやっているmorikuniです。 今回は、mdqというGo製のツールを作ったので、その紹介をします。 mdqは複数のデータベースに並列にクエリを投げて、結果をJSONで出力してくれるというものです。 github.com mdqに近いコンセプトのツールとして、弊社の荒賀(@ken39arg)が作ったshard_promptがあります(#6「Shardingマジ怖い」tech.kayac.com Advent Calendar 2012)。 こちらはSQLを解析し、複数データベースにまたがる集約関数を一部サポートしていますが、MySQL専用かつ直列にクエリを投げるというものでした。 mdqでは複数データベースにまたがる集約関数はサポートしませんが、PostgreSQLなどMySQL以外のデータベースへのクエリや、並列処理による速

4. なぜ、この発表をするのか • 導入の相談も何度も受けました • 導入できないとスキルを上げづらい – 理論より実践 • 悪いサイクルに入るのを減らしたい – スキルが無いから導入できない – 導入できないからスキルが上がらない 5. 既存の手法を使う場合 • ノウハウ本を見てもうまく使えない – 導入を経験して/理論を理解して読むと良書 – 周りの人は使いこなすのが難しい • 振り返りから導入するセオリー – 振り返りから導入はよく聞きますが – 振り返りすら反対されることもあります

その結果、自分はすっかり言及の減ってしまったリーンソフトウェア開発や、それらの源流であるトヨタの生産方式、トヨタが現在取り組んでいる自工程完結を評価するのがよいのではないかと思い至った。本稿は、そういうポエムである。 本稿でいうリーン（ソフトウェア）開発とは何か？ 2003年にメアリー・ポッペンディークとトム・ポッペンディークにより提唱されたトヨタ生産方式を源流とするリーン生産方式をソフトウェア開発に適用した原則集。以下を指す。 リーンソフトウエア開発～アジャイル開発を実践する22の方法～ リーン開発の本質 エリック・リース氏のリーンスタートアップやオライリーのリーンシリーズとは異なるので注意いただきたい。 きっかけとしてのアジャイル方法論の違和感：結局、アジャイルでも多くの課題が残る。 「今回のプロジェクトがやりにくいのはウォーターフォールでやっているからだ」、「今回のプロジェクトが適当

やりたいこと flowで書かれた npmパッケージを作成する時、webpack/browserifyでバンドルされるのを想定してes5水準までコンパイルしつつ、かつflowの型定義も外部ファイルに頼らず提供したい .babelrc package.json src/ # ソース index.js index.test.js lib/ # コンパイル済み index.js index.js.flow *.test.js はスキップしつつ、コンパイル済みの index.js と index.js.flow を作成したい 方法 babelの設定は省略。yarnを使ってるけどnpmに置き換えれば良いとして、yarn add babel-cli flow-bin -D を前提として { ... 略 "scripts": { "build:flow-gen": "flow gen-flow-files

タイトルは釣り、かつ、自分のための備忘録です。 マイクロサービスアーキテクチャでサービスを構築すると、APIサーバをサービスごとに立てるわけですが、 ブラウザ上のJSエンジンからAPIサーバを叩く時に避けて通れないのが、Same-Origin Policy（同一生成元ポリシー）によるCORS (Cross-Origin Resource Sharing)制限です。 これを回避するには、APIサーバ側でAccess-Control-*ヘッダを適切に返す必要がありますが、どう設定するべきかの情報が意外と少ないので（自分的）これが決定版！　という設定を考えてみました。 結論 nginxの場合の設定例です。 server { listen 80; server_name site.localhost; charset utf-8; root /var/www/app/public; locatio

今回は、メモ書き... テーマはJavaScriptのメモリ消費についてです。 JavaScriptのメモリモデルはガベージコレクションという技術を用いています。 この手法は、ガベージコレクター(以下、GC)が最適と判断したタイミングでメモリの開放を行います。 問題点としては、下記があげられます。 ・タイミングが制御できない ・GCの処理中は、プログラムが利用可能な処理時間を奪う 要は、メモリ消費が大きいWebアプリはGCが頻発し、パフォーマンス劣化に繋がるよってこと。 GCの頻度はどうやって確認する？ 下記の画像は、YahooのトップページをDeveloper ToolsのTimelineタブでレコーディングしたものです。 山になっている水色部分がメモリの使用量で、一回ガクッと下がっています。 これがGCのタイミングで、ギザギザになってるほどGCの頻度が高いです。 （「バージョン 39.

以下のグラフは、年収いくらの階層がどのくらいの割合いるかを職種別に示しています。左から平均年収が高い順に並べてあります。 赤い線が年収700万円のラインを示しており、それより上が多いほど年収700万円以上の人が多いことがわかります。 グラフを見ると、一部を除けば平均年収の高いほど、700万円以上の層も多いことがわかります。 全体の半数以上が700万円以上なのは「研究／開発」と「技術営業／アプリケーションエンジニア」のみ。いずれも全体の約60％が700万円以上の年収をもらっています。次点の「組み込みソフトウェアエンジニア」は、約50％が700万円以上です。 また、「電気設計」「機械設計／機構設計」の2職種は、いずれも700万円以上の層が約40%強と同水準ですが、1000万円以上の割合は「機械設計／機構設計」のほうが高い結果です。 一方、年収が低いところで言うと、サービスエンジニアは700万円

合同勉強会 in 福岡で発表したスライドです

合同勉強会 in 福岡で発表した資料 https://connpass.com/event/49117/

社員1人のためにリモートワークは始まった 米田：リモートワークはたまたま始められたのだとうかがっています。導入するきっかけを教えていただけますか？ 倉貫：初期メンバーの中にフリーランスながら会社の経営に深く関わっていた人がいたんです。フリーランスとはいえ経営会議にも出席するなど、社員と変わらない立場でした。 彼は人生において何かに縛られたくないという人生観の持ち主で、あるとき「海外に行って働きたい」と言い出したのがきっかけです。ほかのメンバーもいいじゃないかと応援ムードで、まずは在宅勤務から始めることになりました。 2週間ほど彼だけ家で仕事をしてみたら、そこそこ上手くいったんです。それで次は3カ月、バンクーバーに行って働いてみることになりました。その頃、ちょうど東日本大震災がありまして...。 米田：震災があった当時は毎日何が起こるか分からない状況が続いて、在宅で家族の近くから働くことを多

当初は better AppCache1 として開発が始まった Service Worker2 ですが、ページとは独立したライフサイクルを持つことでイベント駆動型のサービス3実行基盤としての色合いが強くなっています。本記事では、イベント駆動型のサービス実行基盤とは何なのか、そこへと発展していった流れについて紹介します。 なお本記事は Service Worker の使い方を紹介するものではありません。Service Worker をある程度理解している開発者を想定読者としています。また、本記事はすべて私の個人的な意見や調査に基づくものであり、所属する組織、団体とは一切関係ありません。前置きおわり。 AppCache、そして Service Worker へ 冒頭でも述べた通り、Service Worker は当初 better AppCache として開発が始まりました4 5 6。AppC

記事の最後に 変更履歴 を記載しております。 はじめに この記事は、HTML / CSSの知識はあるけど、ピクセルなどの各単位についてあまり理解していない初学者向けの内容です。 私自身未熟ですので説明に誤りがあるかもしれません。 誤りがあれば、ご指摘ください ((_ _ (´ω｀ )ﾍﾟｺ 第1章 メートルとは 第2章 インチとは 第3章 ポイントとは 第4章 ピクセルとPPIについて 第5章 ドットとDPIについて 第6章 解像度とは 今回、調べて記事をまとめるのに結構な時間を費やしました。 単位について理解を深めたいと考えている方の一助になれば嬉しいです。 第1章 メートルとは 私たちはメートルという単位を使って、長さを表すことができます。 先人の方々がメートルという単位を定義し、普及させてくれたお陰です。 最初は、このメートルという単位がどのように誕生したのか簡単に見ていきましょう。

エンジニアが働く上で気になる【開発環境】に焦点を当てた、チーム紹介コーナー。言語やツール類を紹介するだけではなく、チーム運営や開発を進める上での不文律など、ハード・ソフト面双方の「環境づくり」について深掘りしていく。 Google会長のエリック・シュミットが2014年に出した書籍『How Google Works』によると、同社には 「組織のエンジニア比率が50％を下回らないようにする」 「悪党を退治し、ディーバを守れ（自分本位で仕事をする人より、ユーザー目線で仕事をする人が役職に関係なく尊重されるという意味）」 など、複数の独自ルールがある。 これらの狙いは、エンジニアたちの手で「創るカルチャー」を醸成・維持し、より多くのスマート・クリエイティブ（Googleの造語で、多面的な能力を持つ新種の従業員のこと）を引き付けること。それが優れたプロダクトを生み出す源泉になるのは、Googleの実

Ubuntuのバージョンは16.04を利用しています。 macOSで使っていたツールの乗り換え 乗り換えの検討で一番の悩みどころは「macOSで使っていたあれはUbuntuでできるの？」というところかと思います。乗り換えてから１ヶ月程度経ちましたが、現状は以下に紹介するツール群を使っています。ツール選びにあたっては、前述のk0kubun氏の記事や、Ubuntu Alternatives and Similar Software - AlternativeTo.netというサイトが参考になりました。 [ エディタ ] Visual Studio Code macOSから使い続けていますが、体感ほぼ同じで使用できます。たまにCI環境の構築等でiOSのビルドをする場合は、リモートデスクトップでMacBookProに接続して作業しています。 [ ターミナル ] iTerm2 -> guake グロ

ネット上ではSIer批判＝技術のことをわかっておらずプログラムも書けずPMも出来ない非効率でダメダメな上流工程と、 人月単位での労働力提供という業界の慣習に縛られ、持ち前の優秀な技術力・知識を生かせず非効率な作業を強いられているかわいそうな下請け開発者、という構図が確立されているように思います。 自分が関わるまでは、まあそうなんだろうなと思っていましたが、しかし実際にそういう立場のひとと関わりをもつにつれて、どうもそうではないのではないかと思うようになりました。このあたりの実情を書いていこうと思います。 なお、先に言っておきますが本記事で書くことは、上流工程がどうのとか、業界の多重請け負い構造がどうのとか、給料が安くてとか労働条件が過酷でとか、そういう話とは全く関係がなく、純粋にプログラミングのスキルの話だけです。 対象はおもに詳細設計、実装UTだと思ってもらえれば。外部仕様が決まった状態