新年の目標を立てるのと同じくらい重要なのが、「その目標を達成する方法を見つけること」と「仕事にかまけて自分を大事にするのを忘れないようにすること」です。そのためには、自分の時間の使い方を定期的に見直すために、月に1度「Personal Inventory Day（自分を棚卸しする日）」を設けるといいかもしれません。そう提案しているのは、テクノロジーを通じて人権問題に取り組んでいるSabrina Hersi Issa氏です。同氏は、ジャーナリストのAnn Friedman氏と「Tech LadyMafia」の共同創設者Aminatou Sow氏がホストを務めるポッドキャスト『Call Your Girlfriend』に出演して、そう提案しました。 ポッドキャストでHersi Issa氏は、自分が時間をどう使っているのか、何のために時間を使いたいかをじっくりと考えるひとときを、1年の初めや誕生

Brendan Burns, David Oppenheimerらの論文「Design patterns for container-based distributed systems」を読んで、コンテナを活用したシステム設計や開発に、とても有用と感じたので、図を中心にした要約にしてみた。 要約内容に誤りや理解不足な部分もあると思うので、原文も参照していただきたい。また、自身の理解のために、論文中に無い図を加えた点、独自の注釈も加えている。 背景 コンテナ化されたソフトウェアコンポーネントから構築されたマイクロサービスアーキテクチャの人気が高まり、分散システム開発においても同様の革命が起っている。 コンテナの境界の壁は、分散システムの基本的なオブジェクトの境界に適している。そこで、コンテナを活用して、コードの低レベルの詳細を抽象化し、アプリケーションやアルゴリズムに共通する高レベルのパター

まだアクションクリエイターを自分で書いているの？ reduxとflowtypeを使ってフロントエンドアプリケーションを構築していると、ボイラープレートが多く、面倒だと感じることがありませんか？ しかし、もはや、このAST時代の前には過去の悩みでしかありません。 型を書く。それが全てです。 型を書いて、定数を書いて、アクションクリエイターを書いて、一つ変更したら全て変更して、もしくはなんらかのハックを行って型付けして、なんてものは過去のことです。 これからは、アクションクリエイターの作成に5秒以上時間をかけたら怠惰でありましょう。そして、これはs2sの1プラグインでしかありません。 プラグインを組み合わせると以下のようなこともできます。 s2s (Source to Source) これを実現している仕組みをSource to Source(s2s)といいます。 ソースコードからソースコード

GitHubで公開されているフロントエンドチェックリストというドキュメントが、網羅されている内容が幅広く便利そうだったので、日本語に翻訳しました。 日本語版は、以下のGitHubリポジトリにあります。GitHub側と自動的に連携するようにしておりますので、誤訳や誤りなどがあれば GitHub のプルリクエストまたは Issue で報告していただけると幸いです。 https://github.com/miya0001/Front-End-Checklist 日本語版への貢献方法 最終更新日時: 2017-11-19 03:50:47+09:00 (未翻訳) Front-End Checklist The Front-End Checklist is an exhaustive list of all elements you need to have / to test before lau

Unityを使えばUSBカメラやスマートフォンのカメラからの画像を簡単に取得したり、加工したりすることが出来ます。ここではUnityでWebカメラを使う方法と、取得した画像のピクセルにアクセスして画像処理する方法を紹介します。 今回の記事の内容は次のとおりです。 カメラ画像を画面に表示する 映像が上下逆さまになっている場合 映像が淡い色合いになっている場合 Webカメラからの画像に対して画像処理をする 高速化する iOSで実行するとクラッシュする場合 カメラ画像を画面に表示する まずは画像を表示するためのPlaneを作成します。ヒエラルキーウインドウからCreate -> 3D Object -> Planeを選択してください。カメラに対して垂直になるように回転し、サイズを調整してください。 続いてWebカメラの画像をいま作成したPlaneに表示するためのスクリプトを作りましょう。プロジェ

Looking for Datadog logos? You can find the logo assets on our press page.

Nodeのアドベントカレンダー、既に終わった枠が空いていて、この際書きたいネタがあったんで参加しました。宜しくお願いします。 アドベントカレンダーの時期だけ出没する弱い日曜Haskellerです。普段の実務ではNode.jsにお世話になってます。宜しくお願いします。 さて、みなさんStream API使ってますか？Node.jsといったら非同期ですよね、やっぱり。しかしながら、JavaScriptでも他の言語でも、非同期処理自体は注目されているものの、まだexperimentalという感じで様々なAPIが考案されては消えていき、また元々そういう文化が根強くなかったところから来た人たちにとって、こういう文化はちょっと立ち入りづらいところもあるかもしれませんね。 今日は、主にそういう人たちに向けて、まず非同期の色々なAPIの紹介、そしてその中でのストリームのメリット、そして実際のStream

遅れてしまいましたが、これは Rust その2 Advent Calendar 2016 の 5日目の記事です。 この記事はRustをあまり知らない人でも理解できると思います。 Rustを学んで所有権の仕組みに感動したので、 自分の理解の確認を兼ねて所有権のポイントをまとめました。 また、所有権によって得られるメリットを二つ、所有権の魅力として書いて見ました。 所有権の原則 RustはGCなし（ゼロコスト）でリソースを自動的に解放する仕組みを持っていて、それを実現する概念が所有権です。 Rustでは変数(束縛)がスコープを抜けるとき、リソースが解放されます。 スコープを抜けた時に全てのリソースが解放されなくてはいけないので、 変数に対する参照がある場合も、参照は参照元のスコープより長く存続できません。 3つのポイントで所有権を理解する 上記の原則を前提として、実際にプログラミングするときに

本稿は良いDockerイメージを良い方法でビルドすることを探求した記録である。 Supership株式会社 Advent Calendar 2016の21日目にあたる。 2019年現在は@inductor氏の改訂版を見たほうが良い。 この記事で論じた望ましいコンテナイメージの姿は2019年でも変わらない。ただし、multi-stage buildのような新しい仕組みが普及したりツールの評価が定まってきたりと、実現に用いるツールの状況が2016年からやや変化している。 良いDockerイメージ 良いDockerイメージとは何だろうか。Dockerの利点は次のようなものだから、それを活かすイメージが良いものであるに違いない。 ビルドしたイメージはどこでも動く 適切にインストールされ、設定されたアプリケーションをそのままどこにでも持っていける。 コンテナ同士が干渉し合うことはないので、任意のイメ

プロダクトに関わるエンジニアは40人近くいて、弊社ではフロントエンド/サーバーサイドといった明確な線引きがないため全員がフロントエンドに触れる機会が有りえます。開発チーム・コード共にそれなりに大規模と言えるのではないでしょうか。 やったこと モジュール間の依存解決 もともとRailsのSprocketsに沿ってjsを書いていたため、classは全て一つのグローバル変数に格納され、全てのjsが結合された巨大なapplication.jsをロードしている状態で、メンテナビリティやパフォーマンスに大きな問題を抱えていました。そこで去年よりWebpackを導入し、各モジュールの依存関係を整理してjsファイルを適切な単位に分割するようにしました。ファイル数が多いため段階的に作業をつづけ、今年ようやく全てのファイルの依存解決が完了することができました。 過渡期はWebpackとSprockets両方か

https://amakan.net/ のこの辺の改善の続き。 amakanをUnicornからPumaに移行した - ✘╹◡╹✘ amakanでyarnを使うようにした - ✘╹◡╹✘ amakanでRuby 2.3.3を使うようにした - ✘╹◡╹✘ amakanを Ruby 2.3.3 から 2.4.0-preview3 に移行した - ✘╹◡╹✘ amakanのフロントエンドを色々改善した - ✘╹◡╹✘ amakanをSidekiqに移行した - ✘╹◡╹✘ 環境構築 docker が動く環境なら、git clone して bin/setup を叩けば開発が始められる。 $ cat bin/setup #!/bin/bash set -ex docker-compose up -d docker-compose run --rm node yarn install docker-

最近、OOUX という言葉を見聞きしました。これはオブジェクト指向の利用者体験（Object-Oriented User Experience）のことで、いくつかの記事を読んだところ、アプリケーション設計において画面とデータを対応づける際にオブジェクトを手掛かりにするという方法論のようです。つまり OOUX は「オブジェクトベースのUIモデリング」と言い換えることができそうです。そうすると実は以前からそのようなデザイン手法はあり、「OOUI（オブジェクト指向ユーザーインターフェース）」と呼ばれていたのです。最近になって OOUX という言葉が使われるのは、OOUI のことを知らなかったか、もしくは流行語である「UX」を用いた方がかっこいいと考えたからではないでしょうか。 「オブジェクトベースのUIモデリング」というデザイン手法は、GUI アプリケーションをデザインする際の基本的なテクニック

はじめに プログラマの中には、TDDのような自動テストを整備すれば、手動テストは必要なくなると考えている方もいるようです。本記事では、主にプログラマー向けに、手動テストの大切さとはじめ方を書きます。 はじめ方に忍者式テストが出てきます。 プログラマーが得意なテスト、不得意なテスト プログラマーはCheckingが得意です。Testingは不得意です。 テストには Testing と Checking の二つの作業がある Michael Boltonという人のお言葉があります。 Testing vs. Checking « Developsense Blog Checking Is Confirmation Testing Is Exploration and Learning テストにという行為はCheckingとTestingの二つの行為の分けられます。 Checkingは既知の不具合が

本エントリーは Serverless Advent Calendar 2016 - Qiita と Fusic Advent Calendar 2016 - Qiita の7日目の記事です。 今日は AWS re:Invent 2016 Serverless Follow Up がありますね。うらやましい。 サーバーレスアーキテクチャなエラートラッキングツール faultline を作っています。 これは何 AWSのマネージドサービスのみで構築しているサーバーレスアーキテクチャなエラートラッキングツールです。 近いツールとしては、Rollbar、Airbrake、Bugsnag、errbit などがあります。 エラートラッキングのためのAPIバックエンドを提供する faultline と、そのAPIを利用するWeb UIのサンプル実装の faultline-webui があります。 git

ふと、思い立って、先週からダイエットを始めた。ちょうど初めて１週間だが、あっという間に効果がでている。 鏡を見ると心なしか顔のラインがすっきりしてきたような気がするし、昼間の会議でも明らかに頭の回転が鈍っていて、確実に血液中の糖分濃度が下がっている証拠だろう。 夜の会食でも、最近は年のせいか、なかなかコースで出てくる料理の全てを平らげるのが苦痛になってきていたのだが、ダイエットを始めてからすっかり食欲も回復し、先週あった3回の会食でも、大変美味しくいただけて、ほぼ完食することに成功した。 ダイエットすると寝付きが悪くなるらしい。朝早く目覚めたついでにひさびさにブログを書いてみようと思う。 しかし１年ぐらいブログを書いてなかったような気がするが、ネットをやめると本当に仕事が捗って素晴らしい。 というか、ネットをやると仕事にならない。 ネットサーフィンなど、ただでさえ無駄な情報ばっかり気がつく

この記事は2016年に書かれた古い記事です。当時はまだTypeScript2.0も出ていないころで今とは状況がかなり異なっています。参考にする場合注意してください。 はじめに TypeScriptの型システム Declaration space Open-ended ここまでの確認 型定義ファイルを読み書きできるようになるために declare キーワード 既存のオブジェクトの型定義を拡張する グローバルなオブジェクトに対する宣言 module Export Assignments Relative or Non-relative module imports ES2015形式 実際の定義ファイル 既存の定義ファイルを拡張する declare global { } について Typings について おわりに インターン募集中 はじめに こんにちはアプリケーションエンジニアの id:t_k

Supershipの社内勉強会で使ったやつ

This document summarizes an AWS User Group meeting in Japan hosted by Hiro Fukami of Fluxflex. It includes: 1. A presentation on Fluxflex, an innovative web hosting platform that uses AWS products like EC2, S3, SQS, and Elastic Load Balancing for auto scaling and no server management. 2. Updates on game companies like Zynga, RockYou Asia, and gumi adopting AWS in Japan. 3. An announcement of a dem

おはようございます。シニアアプリケーションエンジニアの id:cockscomb です。WWDC が目前に迫ったいま、今秋にリリースが予定されている Swift 3.0 について、Swift OSS コミュニティの中心である Swift Evolution から読み取っていきたいと思います。 [PR] 本記事は、筆者が株式会社はてなの協賛を得て主催した「関西モバイルアプリ研究会 #14」において、“Swift Otaku — Nerdy Swift-Evolution Watching” と題して発表したものをブログの記事として再構成したものである。 関西モバイルアプリ研究会は、毎月一度、平日夜に京都や大阪で開催される、モバイルアプリ関連の勉強会である。次回の「関西モバイルアプリ研究会 #15」は6月22日水曜日に開催予定だ。 目次 Focus Winding Down Complete

概要 AWS ECS でマルチプレイゲーム用インスタンスの管理すると限りなく最強。 はじめに リアルタイム・マルチプレイゲームを作る時、まず考えられることは、あるプレイヤーの行動や状態が他のプレイヤーに伝わることではないかと思われます。しかし、スマートフォンアプリは不安定であったり、複数端末同士で(基地局やバックボーンを介さずに)物理的に直接接続することは出来ませんし、理論的にできたとしても、だいたい開発が進んでいくうちに排他制御の問題などで炎上、もしくはとん挫してしまいます。軽い気持ちでマルチスレッド処理をおこない事故る現象と全くおなじです。 もっとも簡単な解決方法としてはマルチスレッド処理のときようにクリティカルセクションを設けることです。ようはサーバを用意してそこで処理すれば、比較的容易に一意な結果が得られますし、接続に関する問題も起こりにくくなります。 長くなるので → http: