オープンソースの開発現場では限られたリソースで品質管理をどうしているのか。Twitter4J、GitBucket、Asakusa Framework、power-assertの作者が討論（中編） 2016年3月8日に都内で開催されたソフトウェアテストシンポジウム「JaSST'16 Tokyo」において、オープンソースソフトウェアの品質管理についてのパネルディスカッション「OSSにおける品質管理・テストと運営」が開催されました。 （本記事は前編、中編、後編の3本から構成されます。いまお読みの記事は中編です） Twitter APIを叩くTwitter4Jのテストは手間が掛かる 和田氏　リリース周りの話の次は、テスト周りの話を聞いてみようと思います。みなさん、どんなテストを書いているかとか、こんなテストを書いておいてよかったとか、そういう話はありますか？ 川口氏　テストについて言うと、Asak

概要 Githubの自分宛てのNotificationをまとめてSlackに通知するLambda Functionを作った。 2017/03/19 追記 こちらのGithub通知ツール、新しく作り直しました! こちらを参照いただければと思います。 Githubでmentionされた通知だけをLambdaでまとめてSlackに通知したい! (改) - Qiita 作ったきっかけ 自分のPull RequestやIssueに対して誰かがコメントしてくれた時やメンションしてくれた時、気づくのが遅くなってしまうケースが多々あった 自分へのコメントにはできるだけ早く返信したい! GithubのWebhookから通知を拾ってやSlackアプリを使ってSlackに通知する方法があるが、その場合プロジェクトごとに設定することになってしまうし、それはどちらかというとチームのための通知という感じ。プロジェクト

クリスマスが過ぎてから始まる Sphinx アドベントカレンダーへようこそ (嘘) Sphinx 大型連載第二夜です。 タイトルにある通り、Sphinx のメンテナ活動をして一年が過ぎたので、その話をします。 OSS 開発者のひとつのサンプルケースとして、何かの参考になれば幸いです。 Sphinx のメンテナ活動をはじめました 去年の 12月から Sphinx のメンテナ活動をはじめました。 Python のリリースマネージャ活動が忙しかったからか原作者の Georg の活動が鈍り、 また、その後を継いだ清水川さんも忙しくて身動きが取れなくなっていたことから、 コミット権をもらっていたことだし、パートタイムで手伝うかと思ったことがきっかけでした。 以前からコミット権は持っていたものの、一切メンテナとしての活動をしていなかったので、 徐々にチケットが溜まっていく様子に後ろめたくなったのかもし

# Welcome to ESDoc This is the place to try ESDoc. Please write a code and click `Try it out`! - `Index` (this) is used as a index page(Markdown). - `Source Code` is used as a source code(JavaScript) - `Test Code` is used as a test code(JavaScript). - `Manual(Usage)` is used as a manual of usage(Markdown). - `Config` is used as a configuration(JSON). /** * this is BaseClass. */ export class BaseCl

知っておくと便利なnpm（Node Packaged Modules）のコマンドとTipsを全部で10本まとめました。 Facebookの新しいYarn projectには興奮を覚える一方で、Node.jsの躍進にはオリジナルパッケージであるnpmの存在が大きく貢献しています。 少ないnpmのコマンドで、初期化したり（npm init）、パッケージをダウンロードしたり（npm install）、テスト（npm test）したり、プロジェクト内でカスタムスクリプト（npm run）を作ったりできます。少し詳しく調べていけば、日々の開発を劇的に変えてくれるさまざまなコマンドがnpmには用意されています。 注意：もしnpmの手引きが必要なら『A Beginner’s Guide to npm — the Node Package Manager』をチェックしてください。npmとYarnの違いにつ

この記事はElectron Advent Calendar 2016の11日目の記事です。 この記事では僕がプライベートで開発しているJasperというGitHub用のIssue Readerについて書きました。 JasperはElectronで作られており、どういうものかを一行で説明すると「任意の条件にマッチしたIssueが流れてくるIssue Reader」です。 https://jasperapp.io/ https://github.com/jasperapp/jasper 今回はそのJasperの開発初期、リリース期、運用期での出来事を時系列でまとめました。 なので、技術的な話はあまり多くありません。 どちらかというと僕自身の備忘録としてJasperの開発史をまとめたものになっており、すごく長い記事になっています。 ご注意ください。 目次 開発初期 コンセプト 初期実装 フィード

FindBugs の不穏な話を聞いて、まだ余裕あるけれど他の方法があっても良いかなと考えていたところで、こんな記事を見た: FindBugsコミュニティにおける例の件の顛末、そしてSpotBugsとは何か - Kengo's blog 他にはIntelliJ IDEAも推奨されています。IDEAはIDEですが、バッチ（CI）に組み込んでXMLを出力させることも可能とのことです。 どうやら、IDEA でコードを書いている最中に表示される諸々の警告をヘッドレス環境でも取得できるらしい。 ところが該当リンクに飛んでみてもあまり詳しいことが書いてなかったので調べてみた。 まずはじめに ローカル環境でやるなら IntelliJ IDEA を終了させること。 すでに起動している IDEA インスタンスがあると、後述のコマンドは期待通りに動かない。 コマンドどこ Mac だと app の中にコマンドが入

お客様のブラウザはInternet Explorerです。 サイトが正しく見えなくなる場合がございますので、最新ブラウザのご利用をお勧めいたします。

みなさんこんにちは。@ryuzeeです。 2016年9月16日に行われたDevelopers Summit 関西で表題のテーマで登壇してきましたので資料を公開します。 カイゼンについては1日のトレーニングコース（バリューストリームマップ作成含む）を[@haradakiro](https://twitter.com/haradakiro)と提供していますのでご興味のある方は[ご連絡](https://www.ryuzee.com/contact.php)ください。

fastTextとは何なのか 自然言語処理の学習を高速化するツール これまで５日かかっていたタスクがたったの１０秒で終了 fastTextで取り組める３つのこと fastTextで出来る３つの全体像 Facebookはニュースフィードから釣り見出しを排除するためにfastTextをつくった？ リクルートテクノロジーズでは、レコメンドに応用 サイバーエージェントが実用化したAWAでのアーティストレコメンド Yahoo!はレシートメールの文章から製品をオススメする ◯2Vecを考えれば推薦に応用できる fastTextを安全に使うために必要な理論 単語をベクトル表現化するWord2Vec ベクトル表現を構築するアーキテクチャ CBoW Skip-gram fastTextを使ってみよう fastTextをインストールする 単語のベクトル表現を構築しよう Tweetデータの収集 単語のベクトル表

エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 はじめに 何かはじめてのことをする場合、人はとても「不安」を感じます。人は未来を考えることができる生き物です。その特異な能力ゆえに、未来に起こるかもしれないよくないことを考えると「不安」を感じてしまうのです。 仕事のプロジェクトなどは、「間に合わなかったらどうしよう」とか「この仕事はちゃんと終えられるのだろうか。」など、未来のことを

「オープンソースソフトウェア(OSS)」と聞いて、あなたがイメージするものはなんですか？　多くの人は Linux や Apache、Firefox といった成功した大規模なソフトウェア製品を思い浮かべることでしょう。 実は、ウェブ上でサービスを提供する会社のエンジニアたちは、これらとは別の種類のOSSを使って仕事をしています。このブログエントリでは、そのようなOSSを紹介し、それらがなぜ開発され使われているかを説明したいと思います。 ■ウェブ企業におけるOSS開発の実例と合理性 下の図は、Perl で記述される大規模ウェブアプリケーションの一般的な構成を示しています注1。このうち、「自社ロジック」と書かれているところ以外は、全てオープンソースとして開発／公開されているモジュール（ソフトウェア部品）です。各社のエンジニアが密接に協力しながら、ミドルウェアをオープンソースとして整備していること

npm < 僕と契約してnpm scriptsおじさんになってよ！！ タスクランナーとしてnpm scriptsを使おうという入門＆忘備録記事です。 なぜnpm scriptsか なぜGulp等ではなくてnpm scriptsなのでしょう。 簡単 Gulpの構築コストは意外に高いです。 また、一枚抽象レイヤーを導入するわけで、 そのレイヤーの安定度 そのレイヤーの仕様変更 そのレイヤーのプラグインの安定度 に非常に振り回されます。 それならシェル叩いたほうがいいのでは？という発想で、実際それで困ることはあまりないよ、という話です。 npm scriptsの機能 インストールしたパッケージのCLIを起動 npm i -D rollup とすると、当然ながらコマンドラインからrollupをたたくことはできません。 npm i -g rollup というようにグローバルインストールする必要があり

ちょっと贅沢をして家族3人でお寿司を食べに行った。ネタの新鮮さでは界隈で一番という店である。期待通りの、いや期待を超えた美味だったし、いつもは寡黙なメインの寿司職人さんが、珍しくいろいろ話をしてくれた。包丁の入れ方だけでイカはどれほど旨みが変わるか、雲丹は塩水保存とミョウバンを使ったものでは口どけが全く異なること、などなど。サンプルと実演を混ぜて教えてくれた。寿司職人の勤務時間や修業時代についても、語ってくれた。お盆の連休前で、リラックスしていたのかもしれない。 帰り道に、息子が感心したようにつぶやいた。「寿司職人て、なるのはやっぱり大変なんだね。時間も仕事もきつそうだし。でも、それだけ修行したら、あの人みたいな腕になるんだ。」就活が一段落したばかりの息子は、たぶん来年からの自分自身も重ね合わせて、感じ入ったらしい。「それに、あのイカの味の差！　すごい技術だよね。」 ——技術じゃなくて、技

original: The Product Management Triangle (by Dan Schmidt) (translated by ninjinkun, reviewed by Kosuke) はじめに プロダクトマネジメントは多くのソフトウェア企業が重要だと認識している役割だ。それにもかかわらず、「プロダクトマネジメント」を正確な言葉で定義することは驚くほど難しい。自らを「プロダクトマネージャー」と呼ぶ人々は、企業ごとに全く違うことをやっている。彼らは異なるタイプのプロダクト、異なるタイプのチーム、異なる組織構造の中で働いている。このプロダクトマネジメントの立場の違いは、とても不毛だ。外の立場から見ていると、同じ肩書きの仕事を参照する際に、誤解を引き起こしているように見える。全てのプロダクトマネジメントの仕事を統合して、共通の話題を抽出しようとすると、価値を説明しようとし

こんにちは、みんなのウェディングに出向中の小室 (id:hogelog) です。 今回はクックパッドとみんなのウェディングで利用しているデータベースドキュメント管理システム dmemo を紹介します。 https://github.com/hogelog/dmemo dmemo を作成し導入した経緯 私は2016年3月頃からみんなのウェディングで Redshift, bricolage, embulk, re:dash 等を利用したデータ分析基盤の構築を進めています。 (みんなのウェディングのデータ分析基盤の現状 - みんなのウェディングエンジニアリングブログ) 社内の誰でも扱えるデータベース、データの集約・計算・加工、ダッシュボードの作成、クエリの共有などは上記ブログ記事でも書いたように Redshift, bricolage, embulk, re:dash 等を組み合わせることで実現

相変わらずヤパチー自体のエントリをかいていない主催のuzullaです、こんにちは。 さておき、ヤパチーはGithubで色々まわしていたのです。 Slackで雑談し（たり、自分が気付いたら立てる） ISSUEをたて ISSUEのコメントで色々やりとりをし Wikiにまとめる こういったフローで回しておりました。Slackだとながれちゃうし、長文は書けないからね。 さて、こういったフローで問題になるのが、「ISSUEをみない・見逃す問題」です。 GithubのISSUEは何かしらのアクションが発生しますと、なんらかのNotificationをとばします。ご存じの通りサイトには勿論表示されますし（鈴のマーク）、設定によりますがメールでも通知されますね。 しかしながら人はこれは見落とすわけです。後、自分が関係があるけど議論に参加してない話も漏れがちです。 こういうのを解決するために、人は様々なツー

最近は、大体月一ぐらいのペースでメンバーと1on1ミーティングをするようにしている。 一人あたり30分から60分ぐらいで、前回のミーティングからの振り返りとその他相談を話す感じ。相談は仕事のことが主だけれど、プライベートな内容もある。 1on1ミーティングにあたって今年から事前アンケートを用意するようにしたのだけれど、そこそこいい感じに回っているのでまとめてみる。 事前アンケートを用意するメリット 話すことが事前に想定できる アンケート自体がアジェンダになるので、ミーティングがコントロール可能になる。 どんな話をするか分かっていると安心感もあるし、話が横道に逸れることもない（雑談は雑談で良いものだけど）。 その場で回答が思いつかなくて適当な返しになることがなくなる（お互いに） 自分の体験談なんだけど、何か質問をされたときにその場では「うーん、今は特に思いつかないです」と答えたのに終わってか