私たちのプロジェクトではいつも、非常に長い Makefile を使用して、インストールやビルド、テスト、デプロイメントの処理を自動化しています。ターゲット名はほとんど標準化されていますが（ make install 、 make deploy ）、中には説明が必要なものもあります（ make run-dev 、 make restart-api ）。そして、詳細なmakeターゲットを追加するほど、それらの処理内容をテキスト形式で大量に記載しなければなりません。私たちのプロジェクトでは通常、このような文書を README ファイルに書いています。 しかしCLI（コマンドラインインタフェース）を用いる場合は、主に自己文書化ツールを使っています。 make と打つだけで、利用可能なコマンドとその説明が一覧表示されたら便利だと思いませんか？ それを実現するのは、実はとても簡単です。まずは各ターゲッ

こんにちは、技術部開発基盤グループの id:hogelog です。 RubyKaigi 2018 楽しかったですね。僕はおそらく RubyKaigi 2010 以来の久しぶりの参加でした。ああいう場の楽しさを思い出し、また今回はスポンサーブースから RubyKaigi に参加するという学生の頃は知らなかった楽しみも新たに知り、RubyKaigi を満喫させていただきました。 さて今回はそんな RubyKaigi で取り戻した Ruby に対する感情と関係あるようなないような、最近自分が取り組んでいるお台場プロジェクトとプロジェクト内で実施している計測と可視化について紹介します。 お台場プロジェクトの発足 クックパッドの開発といえば数年前までは cookpad_all という一つのリポジトリの中に詰め込まれた巨大なモノリシック Rails アプリケーションを社内のエンジニアが寄ってたかって開

ソフトウェアの世界には「悪い方が良い」原則という有名なエッセイがある。キレイにレイヤ分けされた一貫性のある良いデザインよりも、一見手抜きの悪いデザインのほうが実は良いときもあるという話だ。この逆説的なデザイン原則を僕は身をもって体験したことがある。それについてちょっと書いてみようと思う。 僕はlldというリンカの現行バージョンのオリジナル作者だ。リンカというのはコンパイラと組み合わせて使うもので、実行ファイルやDLLを作るのに使用される。lldはプロダクトとしてはかなり成功していて、標準のシステムリンカとして採用しているOSがいくつかあったり、GoogleやFacebookなど皆が知っているような大規模サイトの中で広く使われていたりする。 現在のlldは2世代目で、第1世代のlldは僕がプロジェクトに参加する前から存在していたのだけど、数年前にそれを捨てて一から書き直すということになった。

先日飲み会で技術的負債についての雑談をしていた。結構いろいろな側面の話をしていたのだけど、技術的負債って一括りにしているのが今はあんまり良くなくて、負債の性質によって技術的奨学金、技術的FX、技術的年金などと言葉を変えると良いのではみたいな半分冗談で会話をしていた。 いろんな問題が技術的負債という一言にまとめられてしまっているので、負債の性質に合わせて、技術的奨学金、技術的FX、技術的年金、など用語を分けると良いのではないか、という話をした— 趣味はマリンスポーツです (@hitode909) 2018年3月27日 技術的負債について - hitode909の日記 それで技術的負債のパターンを見つけて、それによりどういう悪影響があるか、それがなぜ起こるのか、どう返却するかについて考えておくと良いのではと思ったので、今日思いついた3つのパターンをメモしておく。 思いついたパターンは3つ。 変

PySpa統合思念体です。これからJavaScriptを覚えるなら、「この書き方はもう覚えなくていい」（よりよい代替がある）というものを集めてみました。 ES6以降の難しさは、旧来の書き方にプラスが増えただけではなく、大量の「旧来の書き方は間違いを誘発しやすいから非推奨」というものを作り出した点にあります。5年前、10年前の本やウェブがあまり役に立たちません。なお、書き方が複数あるものは、好き嫌いは当然あると思いますが、あえて過激に1つに絞っているところもあります。なお、これはこれから新規に学ぶ人が、過去のドキュメントやコードを見た時に古い情報を選別するためのまとめです。残念ながら、今時の書き方のみで構成された書籍などが存在しないからです。 たぶん明示的に書いていても読み飛ばす人はいると思いますが、すでに書いている人向けではありません。これから書くコードをこのスタイルにしていくのは別にいい

自分が先輩社員となり、チームを持ち、すぐに直面する問題といえば「エンジニアの育成」問題です。 私は7年間システムエンジニアとして働いてきた中で早い段階で多くのメンバーを育てる機会に恵まれました。メンバーの中には文系出身の新人や技術に尖った新人、数年間くすぶっていた中堅若手と様々な境遇の人がいました。 性質がそれぞれ違うなかでどのように"プロ"として育て上げたかを紹介したいと思います。 育成のきほん まずは下記の図を見てください。これは「1分間リーダーシップ」(Paul Hersey, Kenneth H Blanchard/1985年) で取り上げられているSL理論 (Situational Leadership)というメンバーの能力とモチベーションに応じて発揮すべきリーダーシップを表した図です。 S1の状態から順に2,3,4とリーダーシップを変更させていくことが望ましいとされています。

いろいろなソフトウェアで、大きいランダムな値をユニークな値とみなすということが行われている。例えばユニークな識別子としてよく使われるUUIDはただの122ビットの乱数だ。gitもSHA-1ハッシュ値が160ビットの乱数のように扱えることを期待して、それをユニークな識別子として使っていた。実際にはランダムな2つの値が同じになる確率はゼロではないのに、なぜこれが安全なやり方だと言えるのだろうか？ それについてちょっと説明してみよう。 あるシステムが、乱数で生成された識別子の衝突のなさに依存しているとして、仮に衝突が発生した場合、相当悪い結果、例えば復旧不可能な形でデータベースが壊れてしまうとしよう。これはどれくらい危険なのだろうか？ 数学の問題で、学校のクラスの中で同じ誕生日の人が1組以上いる可能性は思ったより高いという話を聞いたことがあると思う。あるランダムに生成された値が衝突する確率という

GitHubは、オープンソースで公開している開発者向けのエディタ「Atom」で複数のプログラマがリモートでコードの編集を行える追加機能「Teletype for Atom」のベータ版をリリースしました。 Teletype for AtomをインストールしたAtomでは、Portal（ポータル）と呼ばれる機能が利用できるようになります。自分のAtomをポータルにすることで、ほかのプログラマを自分のAtomエディタに招待できるようになり、複数のプログラマで同一のコードが編集可能になります。 複数のプログラマが自分のエディタから同時にコードを編集可能 以下は公開されたデモ動画から、「Teletype for Atom」の動作を紹介しましょう。 Atomエディタ右下のポータルボタンをクリック。ID番号が生成されます。

It makes me smile when someone raves about how fast this website loads, because that's no accident. We put a lot of effort into making it so. It is the sort of thing that usually goes unnoticed, but when your readers are developers, there's a better chance they notice and appreciate it. I have written about this in the past, but it's worth re-examining because these ideas are always evolving. From

パスワードを忘れた方はパスワードの再設定を行ってください。 初めての方ははてなID登録 (無料) してください。 うまくログインできない方はお問い合わせをご覧いただき、Cookieの設定をご確認ください。

本稿は、JavaScriptのテストについて最も重要な根拠、用語、ツール、アプローチなどの知識を身に着けることを目的とした簡略版ガイドブックです。本稿で検討する数々の側面に関する最新の秀逸な記事も紹介しつつ、私たちが経験的に得たことも多少付け加えたいと思います。 Facebookによるテスト用フレームワークであるJestのロゴをご覧ください。 見てお分かりのように、このフレームワークは「苦痛のない」JavaScriptのテストをスローガンに掲げています。しかし、 “次のように言う人” もいます。 苦痛のないテストなんてあり得ない。 実際、Facebookはこのスローガンを掲げるだけの素晴らしい理由があります。一般的にJSのデベロッパは Webサイトのテストにあまり満足していません 。JSのテストには制限があり、実装が難しく、低速である傾向があります。 一方、正しい戦略を立てて適切にツールを

もう5年か、まだ5年というべきかちょっと判断に迷う。大抵の業務系のシステムがクラウドを始めるのは現実的には今年来年以降になるので、今の自分達の状況は多分、今後の業務系システムをクラウド移行したユーザの近未来になると思う。ので、予想的にまとめておく。本格的にクラウドを利用した業務アプリケーションの5年がどうなるかの一つの指針になるかと。 以降は別に統計データでもなんでもなく5年間を眺めてみて自分の印象。 ・障害：大規模は５年で2-3回程度。一度は業務に影響が出て客先にお詫びに行った。AWSだったけど、サポートからは「もう回復してるのでチケットクローズね」みたいな話だったと記憶している。その後は大体四半期に一回程度のN/W障害。障害は普通に起きているし、オンプレと比べてどうか、という比較では細かい障害件数は減った気はしていない。ただし、「ドカンと来るでかい障害」は確実に減った。 ・データ増加対

で完了 なければ nodeのバージョンをnで管理する などを読みつつnodeとnpmをインストールしてください 準備するもの コンソール db.json ブラウザ（動作確認用） やること db.json ファイルを作成する bashの touch コマンドやWindowsなら右クリックからなどでお好きなようにファイルを作ってください db.json にリソースを登録する ここでモックサーバから返して欲しいデータリストを列挙します 最上位の階層の key がエンドポイントになります { "users": [ {"id": 1, "name": "hoge"}, {"id": 2, "name": "fuga"} ], "tweets": [ {"id": 1, "contents": "あー眠い", "user-id": 1}, {"id": 2, "contents": "ファビュラス！"

これ以上は長くなるため後述． Chromeは既に，Safariもようやく 上記の通り，Service WorkersがPWAでも最重要な機能の一つである．Chromeでは既に対応済み． しかしSafariが対応しておらず，世間的にはモチベーションの上がらない状況であった（やちまもその一人である）． Safariにおいて，Service Workersの実装状況 No active development が Under Consideration になったのは2015/12/041のことである． 20ヶ月という永遠とも呼べる時を経て，2017/08/032にようやく In Development となったわけであった． ちなみにMicrosoft Edgeでは既に開発中34である． だから何なのか SafariにService Workersの実装がなされると，一気にウェブアプリへの移行が

本稿は Swift Tweets 2017 Summer で発表（ツイート）したものをまとめ、Qiita 用に追記・再構成1したものです。 発表概要 CotEditor プロジェクトの現主催者 1024jp です。CotEditor は昨年 2016 年に Objective-C から Swift に移行しました。今日はその話をします。 本発表は、事前に以下のような概要を開示していました。 2004 年から脈々と受け継がれる総 Cocoa 製の macOS 用テキストエディタ CotEditor は、昨年 2016 年に Objective-C から Swift に 100% 移行しました。 Swift は魅力的な言語ですが、すでに Objective-C で 10 年超動いてるアプリケーションを誰に頼まれたわけでもないのにわざわざ Swift で書き直す意味は果たしてあるのでしょうか？

2017年7月20日に行われた Rails Developers Meetup #3 の発表資料です。

DDDを始めるにあたって実施したことを実例を交えて紹介しています。 内容 - DDDとは何か - なぜDDDをやるのか - 実際にどうやって導入したか