コンテナの物語を読んで、SIerの行く末を想った - 勘と経験と読経
読書メモ。「コンテナ物語」はコンテナ輸送（コンテナリゼーション）が現代社会に与えたインパクトについて書かれた本だ。内容自体とても面白いのだが、読みながら別のことを考えていた。 本書はビルゲイツが2013年の本としてピックアップしている ビル・ゲイツ氏が選ぶ「2013年に読んだ記憶に残る7冊の本」 - GIGAZINE なお私はKindle版をセールで購入（セールは既に終了）。 コンテナ物語―世界を変えたのは「箱」の発明だった 作者: マルク・レビンソン,村井章子出版社/メーカー: 日経BP社発売日: 2007/01/18メディア: 単行本購入: 6人 クリック: 72回この商品を含むブログ (40件) を見る コンテナの物語 本書で紹介されるコンテナを軸にした輸送革命の流れはだいたいこんな感じだ。 コンテナが発明される 標準化されるが、さほど普及せず 効率化は達成されたが、運送コスト大きく
開発のドキュメントをどこに置くか問題 - $shibayu36->blog;
最近開発用のドキュメントをどこに配置するか悩んでて、いくつか試して見てる。今回言っている開発用のドキュメントというのは、コードの触り方も含んだサービスの開発に関するもの。例えば 開発環境セットアップ方法 ページに表示している広告をどのように切り替えたりするか(googleの管理やコードの変更も含めた) サービス内の特定の機能の仕組み 内部用HTTP APIドキュメント などを指している。 結構いろいろ考えるところがあるので、思っていることをまとめてみたい。一応先に結論を言っておくと 基本は実装に一番近いところにコメントとしてドキュメント書くのが良いと思う いろんなパーツが絡みあうような大きな機能の場合、導入部分だけ別の場所に書く 出来るだけrepository内に入れておくと探しやすく、更新しやすいと思う あといろいろ悩んでるので事例あったら教えてください。 起きている問題 ドキュメントは
NUCON 資料を公開しました！ | 株式会社ヌーラボ(Nulab inc.)
昨日は雪が舞う悪天候にも関わらず、大勢の方に NUCON にお越し頂きました。みなさま本当にありがとうございました！ 基調講演は元より各セッションも大盛況で、「どのセッションを見ればよいか悩んだ」「見れなかったほうのセッションの資料をみたい」といったお声もいただきましたので、以下に資料を公開いたしました。 テクニカルトラック 開発者がかたるヌーラボのコラボレーションサービス API 最前線 ( ヌーラボ 染田貴志、中原正二、後藤幸 ) 職人任せにしないインフラ構築/運用 ~ DevOps時代を生きぬくために ~ ( ヌーラボ 中村知成 ) 今どきのリアルタイムコラボレーションツールの作り方〜Backlog、Cacoo、Typetalkにおける実践例〜 ( ヌーラボ 縣俊貴 ) ジェネラルトラック ヌーラボサービスの利用事例 – Backlogを使ったオフショア開発 ( EVERRISE 古
Designing a REST API: Unix time vs ISO-8601
Designing a REST API: Unix time vs ISO-8601 Published on: February 22, 2013 In what format should a REST API return and accept timestamps? The two most popular ways are Unix time (or a slight variation thereof) or ISO-8601. Both have their strengths and weaknesses and both are equally popular as we shall see. A sample of 20 APIs yielded nearly a 50/50 split. Therefore, no matter if this holds any
日本語訳: Trash Your Servers and Burn Your Code: Immutable Infrastructure and Disposable Components — sawanoboly.net
@azukiwasher さんからチャド・ファウラ氏のブログ日本語訳を頂きました。 元の記事はこちらです。 Trash Your Servers and Burn Your Code: Immutable Infrastructure and Disposable Components - Chad Fowler Trash Your Servers and Burn Your Code: Immutable Infrastructure and Disposable Components サーバーを捨て、コードを燃やせ：イミュータブル・インフラストラクチャとディスポーザブル・コンポーネント 2013.06.23 As a developer and sometimes system administrator, one of the scariest things I ever enco
(株)永和システムマネジメントのフェローに就任していました - 角谷HTML化計画(2014-02-05)
■1 (株)永和システムマネジメントのフェローに就任していました TL;DR 1月末日付でesmincの「正社員」ではなくなりましたが、esm.co.jpのメールアドレスは生きております。引き続きよろしくお願いいたします。 current status のまとめ: 一般社団法人日本Rubyの会 理事 株式会社永和システムマネジメント フェロー Asakusa.rb幹部(自称); 最近欠席ぎみ 個人事業主(ソフトウェアをつくり、とどけることにまつわる様々なこと) こんな気分: 保険証を会社に返した途端に家族の体調が崩壊して戦々恐々です……社会は厳しい。 さしあたっては、まだ引き継げてないギョームをどうにかしつつ——先に個別にご連絡を差し上げるべき方々につきまして、ご挨拶が遅れておりますことを、この場を借りてお詫び申しあげます——、組織の運営からはちょっと距離を置いて、主に東京支社のメンバーと
Simple small business software, collaboration, CRM: 37signals
A catalog of ideas — signals — that drive us.
Git を学ぶ - チュートリアル、ワークフローおよびコマンド | Atlassian
Git は、元々 Linus Torvalds によって 2005 年に作られた、無料でオープンソースのバージョン管理システムです。他の SVN や CVS といった中央バージョン管理システムと違って、Git は分散型で、すべての開発者がローカル環境で彼らのコードのリポジトリの完全な履歴を持っています。これは、最初のリポジトリのクローン作成に時間がかかりますが、commit、blame、diff、merge、log といったこれに続く作業を劇的にスピードアップします。 Git は多くの革新的で強力なワークフローやツールにつながる、リポジトリ履歴のブランチ、マージ、および書き換えに非常に役立ちます。プル リクエストは、チームが Git ブランチでコラボレーションを行い、他のコードを効果的に見直すことができる、非常に人気のツールです。Git は現在世界で最も広く使用されているバージョン コント
東京Node学園 11時限目 (2014/02/26 19:30〜)
お知らせ 【重要なお知らせ】iOSアプリの運用および提供を2024年6月3日(月)を以て終了いたします。詳細は お知らせをご覧ください。 お知らせ connpassではさらなる価値のあるデータを提供するため、イベントサーチAPIの提供方法の見直しを決定しました。2024年5月23日(木)より 「企業・法人」「コミュニティ及び個人」向けの2プランを提供開始いたします。ご利用にあたっては利用申請及び審査がございます。詳細はヘルプページをご確認ください。
テストファーストなGitワークフローについて - kazuhoのメモ置き場
Gitのワークフローに関する話題が、また盛り上がっているようなので、僕が好んで使っているワークフローについて書きます。 対象としているソフトウェアは、GitHubやGitHub Enterprise等を使って開発されている、リリースブランチを切らずにmasterにリリースタグを打っていくだけで十分な程度の、ウェブサービス（の部品）やオープンソースプロジェクトです。 まず、以下の２点を原則として考えています。 origin masterを壊さない origin masterの（1st parentをたどるツリー）にテストを通らないcommitを入れないよう努めます 変更の主題を常に明確にする 前者の理由は、masterをいつでもリリース可能な品質に保つためと(←12:44追記)git bisectするときに困らないようにするため。そして、これらの原則から、以下のようなワークフローで作業するこ
なぜクライアントJavaScriptの単体テストを書くのが難しいか、考えてみた - mizchi's blog
ってsinonのスタブ漏れを探しながら何度目かわからない感じにキレてた。 とにかく仕事でJSのテスト書くのが辛いので考えてみる。比較的JSのテストに慣れてる自分ですら辛いのだから、世界はもっと辛いに間違いない。サーバーサイドのnode.jsの話ではない。 JavaScriptで完結しない 構造がHTMLの構造と密結合している。装飾や位置、表示/非表示はCSSによって制御されている。 クライアントJSはHTMLと密結合しており、CSSからビューは影響を受ける。それらがネットワークの結果を受け非同期に振る舞いを帰る。その最終的な値を取得するのが難しい。 もちろんサーバーサイドだってDBやネットワークという外部リソースを扱うが、モックの手法が確立しているし、局所的な複雑度は、JSの方がはるかに多い。 言語仕様が貧弱 mochaやjsmineはrspecを真似てるけど、本質的にJavaScript
「実況解説つき！ペアプロでわかるJavaScriptテスト入門」レポート | gihyo.jp
2014年1月17日、ベルサール新宿グランドにて開催された「エンジニアサポートCROSS 2014」の中の1セッション「実況解説つき！ペアプロでわかるJavaScriptテスト入門」をレポートします。 エンジニアサポートCROSS 2014とは 「複数の技術を身につけなければWebサービスは作れない＝クロスしないと生きていけない」をテーマに、「エンジニアサポート新年会2012 CROSS」として第一回が2012年に開催された勉強会イベント、それがCROSSです。今年で3回目になります。 「実況解説つき！ペアプロでわかるJavaScriptテスト入門」 このセッションは「JavaScriptで書かれたよくあるコードをベースに、ペアプロでテストコードを足していく様子を解説者が説明する」という内容になります。 それでは、さっそくセッションの模様を見ていきましょう。 登壇者 本セッションの登壇者
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Kadoppe’s Blog
TDD のこころ @ OSH2014
