レガシーコード改善の戦略と戦術自己紹介 name: 和田 卓人 hatena : t-wada twitter : t_wada github : twada レガシーコード改善コンサルティングも多いです
日本語で読める IT名文書 三選 - naoyaのはてなダイアリー
pplog の方に書いたけど、別にブログに書けばいいかと思い直したので投稿。Slack でチャットしてて、なんとなくこれ面白いよ URL を共有する機会があったので適当に選んだもの。 伽藍、バザール、ノウアスフィア、おなべ(3) http://www.artonx.org/diary/20120411.html#p01 artonさんがノウアスフィアの開墾についてわかりやすく書いてるもの。原文はちょっと長くて読むのが大変だけど、こっちは分かりやすいし、面白い。OSS の構造がなんかわかったきになる、すごい。 Steve Yegge の Google とプラットフォームに関するぶっちゃけ話を訳した http://anond.hatelabo.jp/20111018190933 (前編) http://anond.hatelabo.jp/20111018192953 (中編) http://a
bash の脆弱性 "Shell Shock" のめっちゃ細かい話 (CVE-2014-6271) - もろず blog
※(2014/10/1 追記) 脆弱性の番号を誤って CVE-2014-6721 と表記してしまっていました 正しくは "CVE-2014-6271" です 失礼致しました ※(2014/10/7 追記) 2014/10/7 14:00時点で Shell Shock への修正パッチは6個 公開されています 既に対応済みのシステムでもパッチの漏れがないか注意してください シェルに脆弱性が見つかったらしいです このコマンドを実行すると脆弱性があるバージョンかのチェックができるようです $ env x='() { :;}; echo vulnerable' bash -c "echo this is a test" 以下のように表示されたらアウトです vulnerable this is a test どうやら、このコマンドが正常に実行できるというのがこの脆弱性の正体らしく、 echo vuln
東日本大震災時に拡散された「辻元清美が阪神淡路大震災時に反政府ビラを配っていた」という流言について - 荻上式BLOG
東日本大震災の際、ウェブ上では政治家に関する流言も多く流れた。特によく見られたのが、災害ボランティア活動担当として内閣総理大臣補佐官となった辻元清美氏に関する流言だろう。辻元清美氏自身も、ブログで「辻元清美に関するデマについて」というエントリをまとめている。中でも、「阪神大震災のときに、辻元清美が『自衛隊は違憲です。自衛隊から食料を受け取らないでください』と書いたビラをまいた」という流言は、頻繁に拡散されていた。 ※当時のツイート例 阪神淡路大震災の時、「お腹が空いても我慢しましょう」「自衛隊から食べ物をもらってはいけません」「ミルクがなくても我慢しましょう」 そんなビラを配っていた、辻元清美さんがボランティア担当として政府補佐官に。 辻元は阪神大震災の時、自衛隊よりも先に現地に入り、ピースボートの宣伝と、自衛隊は違憲だから食料を受け取るななどのビラを撒いて政府批判活動をしていたという指摘
その選択、ちょっと待った！NoSQLデータベースへ乗り換える前に検討すべき3つのポイント
最近、どうも安易に「NoSQLにすれば厄介なDB設計から開放される」と考えている人が多いように思えて仕方がない。だが待って欲しい。本当にNoSQLと呼ばれるデータベースを使えばアプリケーションの開発・運用の苦しみから逃れられるのだろうか。もちろん「そんなことは無い！！絶対にだ！！」と私は考える。今日はその理由について語ろうと思う。 トランザクション先日、リレーショナルデータベースにおけるDB設計についてセミナーで解説したばかりだが、リレーショナルデータベースにおけるデータの整合性は何もDB設計だけが担保しているわけではない。リレーショナルモデルと同じかそれ以上に欠かせないのがトランザクションだ。 トランザクションがあるおかげで、トランザクション終了後のステータスは「成功」か「失敗」の2つしかないということが保証される。すなわちオール・オア・ナッシングだ。もしトランザクションの途中で何らかの
MongoDBが適さないケース - 中年engineerの独り言 - crumbjp
> 原文(Why MongoDB is a bad choice for storing our scraped data) 私自身はMongoDBを推進する立場なのだが、確かにMongoDBに適さないケースはある。 闇雲に推進しても結局は全員がアンハッピーになるので、この様なネタもどんどん紹介していこうと思う。 この記事はMongoDBを徹底的に使い尽くしたエンジニアが書いている様で状況が良く解った。 ちょっと難しい所もあるので要点を意訳して、軽く解説を書いてみる。 （もちろん是非原文で読むのをお勧めする） 状況 最初はMongoDBでうまく動いていたが、だんだん苦労が増えてきて 元々のアーキテクチャを刷新するタイミングでMongoDBから別のプロダクトに乗り換える事にした。 システムの規模 詳しく書かれていないが、１ノード辺り数TBとあるのでSharding環境ではないかと思われる。
MongoDBの薄い本
2.6対応版 MongoDBの薄い本 The Little MongoDB Book Karl Seguin 著 / 濱野 司 訳 i 目次 目次 i この本について iii ライセンス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii 著者について . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii 謝辞 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii 最新バージョン . . . . . . . . . . . . . . . . . .
PHP: PHP 5 ChangeLog - Version 5.4.0
Getting Started Introduction A simple tutorial Language Reference Basic syntax Types Variables Constants Expressions Operators Control Structures Functions Classes and Objects Namespaces Enumerations Errors Exceptions Fibers Generators Attributes References Explained Predefined Variables Predefined Exceptions Predefined Interfaces and Classes Predefined Attributes Context options and parameters Su
ストーリー、エピック、テーマ by Mike Cohn - kawaguti’s diary
「アジャイルな見積りと計画作り」の著者マイク・コーンさんがブログで、「ストーリー」と「エピック」の使い分けについて説明していましたので、だいたい訳して載せておきます。 ちょうど最近、ストーリーとエピックについてご質問をいただいたので、これを参考にしていただけるとうれしいです。 ストーリー、エピック、テーマ ( STORIES, EPICS AND THEMES by Mike Cohn) http://blog.mountaingoatsoftware.com/stories-epics-and-themes 最近、「ユーザーストーリー」「エピック」「テーマ」の違いがわからないというメールを受けることがだんだん多くなってきている。今回はこれらの用語を説明する事を通じて、基本的な(でもとても役立つ)領域に立ち返り、確認していく。 まず、この用語にはあまり深い意味はない。この用語には、プログラ
ScalaMatsuri ふりかえり（今更） - seratch's weblog in Japanese
何となく ScalaMatsuri のふりかえりでもしてみようかという気分になりました。自分の中での整理という感じなので、あまり面白みはないかもしれません。 Scala と私 というところで見直してみたけど、私の Scala への関わり方は以下のスライドに全てあらわれているので、その点はもう補足の必要がないですね。私の活動に興味を持っていただいていた方にとっては、やってきたことそのままであることがおわかりいただけるかと思いますが、この機会に明文化できて自分としては一区切りついたというか、すっきりした感はあります。 スライド もう少し踏み込んだ話 もう少し踏み込んで言うと、もしも Scala 使うようになって前より仕事が楽になったり、楽しくなっていないとしたらそれは明らかに間違っているというか、少なくとも今いるメンバー、やろうとしてることとのミスマッチがあるわけなので「頑張って FP の勉強
技術的負債を抱えた状態で技術者がすべきこと - sandbox
この Qiita のエントリに触発され、元文章の目的はさておき、技術的負債についての自分の考えを書いてみようと思う。 技術的負債の定義や、問題は下記エントリを参照して頂くとして、なかでも最後の「技術者がすべきこと」について、「自分だったらこの様にアプローチするか」ということを書く。 技術者がすべきこと 大前提 開発前にステークホルダー(ここではプロジェクトの責任者とする)に、プロジェクトの性質として何を重視するかを認識、選択してもらう。 短期的な価値実現を最優先とし、初速を重視、ソフトウェアの健全さ、プロダクトの成長速度を犠牲にする 長期的な価値実現を最優先とし、ソフトウェアの健全さ、プロダクトの成長速度を重視し、初速を犠牲にする 1 を選択するという事について、健全でない状態や、成長速度が犠牲になった状態がどの様なものかを、プロジェクトが走り出す前に十分に認識してもらう必要がある。 …と
技術的負債 - Qiita
この文章の目的 開発者とステークホルダーが「技術的負債」という言葉で正しくコミュニケーションをとれるようになることをゴールとする。技術的負債については色々な所で語られるが、実際の現場では技術的負債が管理されてない事が多いのでは無いだろうか。この場で技術的負債という言葉についての知見をまとめ、たたき台とする事で、ゴールに到達する第一歩としたい。 対象読者 開発者 責任者/見積もりに対して決定権を持つ人 技術的負債とは何か 技術的負債とは、コード・設計の状態を表す見積もりのための言葉である。継続的に開発を行う上で理想状態から離れたものを負債という比喩で表していている。 たとえば、省略可能なプロセスを飛ばす事で開発の高速化を行う事があり、初期開発を高速に行う開発者の中には意識的・無意識的問わずこれを行っている事例が多々存在する。このようにして抱えられた技術的負債は長期的に見た場合に問題を引き起こ
Oracle Cloud Infrastructure Container Registry
Container Registry Oracle Cloud Infrastructure Container Registry is an open standards-based, Oracle-managed Docker registry service for securely storing and sharing container images. Engineers can easily push and pull Docker images with the familiar Docker Command Line Interface (CLI) and API. To support container lifecycles, Registry works with Container Engine for Kubernetes, Identity and Acces
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
