ソフトウェアの思想が設計にもたらす影響
Emacsは死んだ Emacsの設計は、思想上の理由から、わざと貧弱であるという話。 Emacsの内蔵言語であるelispは、貧弱だそうだ。私はLisp系の言語に詳しくないが、少なくとも今まで出会ったLisperは皆elispは貧弱だと答えている。それにも関わらず、今まで出会ったLisperは全員、LispのコーディングにはEmacsを利用しているのは不思議だ。おそらく、Emacsとその資産を再実装する手間を考えたら、Emacsを使ったほうが得策なのだろう。 elispが近年のLispの進化を反映していないというだけではない。Emacsのelispはマルチスレッドに対応しておらず、ちょっと重い処理をしようとするとユーザーに応答できなくなってしまうし、共通の処理は共有のライブラリとしてまとめるという普通のことが難しく、ファイルI/Oなどの低級なAPIも不足しているという。 自然として、Ema
エクスコムの情報流出はシステム設計というより業務設計がだめな件 - aike’s blog
そんなわけでクレジットカード再発行しました。そうです流出です。今年の3月にアメリカ行ったときに海外旅行者向けWiFiルーターレンタル業者を探してたらエクスコムが安かったので申し込みました。まさかこんなことになろうとは、という感じでくやしかったのでブログのネタにしてみました。 申し込みから返却まで経緯はこんな感じでした。 ■3月5日 申し込み エクスコムのウェブフォームから住所氏名とともにクレジットカード情報を入力して申し込んだら、こんな確認メールが返ってきました。一部省略、伏字にしています。 Subject: レンタルお申し込みありがとうございます Date: 5 Mar 2013 10:46:21 +0900 From: エクスコムグローバル株式会社 この度は、お申込みいただき、誠にありがとうございます。 ご利用に際しては、以下の注意事項をご確認ください。 （略） ━━━━━━━━━━━
悪いAPIは伝染していく（2）: 柴田 芳樹 (Yoshiki Shibata)
以前、「悪いAPIは伝染していく」という短い記事を書きました。 APIが悪いライブラリを使用する別のライブラリを設計する場合には、元のライブラリのAPIの悪さを、新たなライブラリでは修正することが可能です。しかし、よく見かけるのは、使用する元のライブラリのAPIの悪さをそのまま引きずったライブラリが設計されることです。その意味で、低レベルのライブラリのAPIの悪さは、上位レベルへと伝染していきます。悪さが伝染しないように新たにAPIを設計できるエンジニアは少ないようです。 きちんとしたAPIを持つライブラリを使用しているのにもかかわらず、出来の悪いAPIを持つ上位のライブラリが作成されることがあります。私自身がかなりレビューしてAPIを整備させたライブラリを使用して、その上に出来の悪いAPIを持つライブラリが設計されているのを見ると、がっかりしてしまいます。 どんなAPIでも、最初のバージ
綺麗な設計を身に付けるためのSandi Metzルール
Webアプリやモバイルアプリの受託開発やコンサルティングを行うthoughtbot社のブログにて、Sandi MetzルールというRubyプログラマ向けのルールが紹介されていました。 Sandi Metz’ rules for developers このルールは、プログラマーでありPractical Object-Oriented Design in Rubyという書籍も執筆しているSandi MetzさんがRuby Roguesポッドキャストに出演した際に紹介していたものです。 そのルールは以下の通りです。 クラス内のコードが100行を超えてはならない メソッド内のコードが5行を超えてはならない 4つより多い引数をメソッドに渡すようにしてはならない（ハッシュによるオプションもパラメーターとみなす） コントローラーではただ1つのオブジェクトだけをインスタンス変数化できる ビューは1つのイン
(小ネタ)本番のみロードバランサーがある場合の注意点
方式設計小話。 webシステムを開発し、本番運用に至る過程で、下記のうち最低２つの環境があるのではと思います（所属している組織によって呼び方は色々変わるかと思いますが)。 ・個人開発環境 ・結合環境 ・ステージング環境 ・本番環境 上記の様に複数の環境があるにも関わらず、予算の都合上、「本番のみ複数台の冗長化構成。フロントにロードバランサー」という構成が多いのではと思います。そしてこの事実の与えるインパクトを過小評価してしまいトラブルが起こる場合があります。 ロードバランサー＆冗長化というキーワードを聞いた場合は、下記を必ず早期に確認しなければいけません。 No.1 セッション情報の引継ぎ。ロードバランサー担当者にお願いする事項は無いか No.2 SSL通信の解除はどこが行うか？ No.3 どうやってhttp/httpsを見分けるか？ No.4 サーバ名は正しく返せるか？ No.5 ファイ
一貫性を確率でおきかえる？ - winplusの日記
InfoQの記事、12年後のCAP定理: "法則"はどのように変わったかの最後(現金自動預け払い機の補償問題)が切れていたので、原文CAP Twelve Years Later: How the "Rules" Have Changedで該当個所を読んでみた。で、追加されたので日本語訳を読んでみて、さすがだなあ。でも、気になったところがひとつ。「通常、この不変式侵害が外部に発覚するのはATMがお金を分配するときです」というところですが、セクション「処理失敗を補償する」にある「外部化された処理失敗」と対応しているので、「通常の場合、ATMは金銭を払い出し、処理失敗は外部化されます」ってことだと思います。 ついでに、原文CAP Twelve Years Later: How the "Rules" Have Changedにあるコメント(著者のEric Brewerさんが回答しているもの)を適
CAPの解決策（Brewerが間違っているって証明しよう） - winplusの日記
ついでにもうひとつ、AtomikosのCTOであるGuy Pardon氏のブログから。こちらも誤訳もいっぱいあると思うが、参考までに公開しておく。 Guy's Blog Sunday, September 07, 2008 CAPの解決策（Brewerが間違っているって証明しよう） コンピューターサイエンスの最新の挑戦のうちのひとつは、CAP定理だろう。それは、大規模でクラスタ化された（ウェブ）サービスのアーキテクチャを構築するにあたって、明らかに不可能なことについて述べている。それが（おそらく）真実だと証明されたという事実があるので、私がここで書くつもりことは、ほとんどありえないことになってしまう。そうだしても、読んでほしい。というのも、私が正しくて、最終的にはCAPが不可能でないことを証明するつもりなのだから...。CAPの不可能性の証明は数学的には正しいけれど、それはあまりに厳しすぎ
ACIDからBASE（勝手に後半） - winplusの日記
先日の記事で触れたL'eclat des jours(2008-11-20)の続きを、勝手に試みた。調子を合わせようとしたけれど無理。全然こなれないし、誤訳もいっぱいあると思うが、参考までに公開しておく。 BASE：ACIDの代わりをどうぞ ■Consistency（一貫性）のパターンいくつか ブルーワのいうとおりなら、BASEは、分散と可用性をとるかわりに、どこかで一貫性を諦めるしかない。これは難しい。というのも、ビジネス関係者も開発者も「一貫性がいちばん重要だ」というんだ。一時的な矛盾であってもエンドユーザに見えてしまうので、ビジネス関係者と開発者の両方で、どこで一貫性を諦めるかを決める必要がある。 図2はBASEが考える一貫性を説明するための簡単なスキーマだ。userテーブルは、売上総額と購入総額も含めたユーザ情報をもっている。売上総額と購入総額は現時点での合計額だ。transact
１時間ごと更新なのにリアルタイムとは、これいかに。 - winplusの日記
http://tanoapp.tworks.jp/2009/09/25/%E6%A5%BD%E3%81%97%E3%81%84%E3%82%A2%E3%83%97%E3%83%AA%E5%88%B6%E4%BD%9C%E3%81%AE%E4%BC%9A-8/に参加して思ったこと。 報告１：クラウドの一般的なご紹介 => 分散DBが新しい。 報告２：Google App Engineでのアプリ開発 => BigTableが使いこなしのキモ。 報告３：Windows Azureでのアプリ開発 => SQL AzureではSQLが使えるよ。 報告４：オープンソースのMapReduce/分散ストレージ実装、Hadoopの紹介 => RDBはスケールしない。やっぱり分散だね。 端折りすぎですが、やっぱり分散DBというのが大きなポイントになっていると思いました。SQLが使えない => JOINが使えな
デザインパターン？なにそれ？おいしいの？ - winplusの日記
楽しいアプリ制作の会 #07（終了）テーマ「デザインパターン（続）」に参加して思ったこと。 最後の方で、WEBフレームワーク Struts の ActionServlet がリクエストを振り分けるところは、Strategyパターンの適用例だという発表者に対して、参加者からCommandパターンに見えるという発言があり、結局、見かた次第、複数のパターンを同時に適用することもあるし、という流れになった。WEBアプリケーションを考えるとき、リクエストをレスポンスへ「変換するもの」と見なせば、Strategyパターンの適用例というのが妥当だと思える。リクエストを「処理の指示」と見なせば、多様なパラメータを同じように扱うためにCommandパターンを適用しているようにも思える。この「見かた次第」というところを、もう少し考えてみたい。 ところで、そもそも、なぜデザインパターンを使うの？という参加者から
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CSVというフォーマット
トレードオフ - winplusの日記
ACIDのBASEとCAPのBASE - winplusの日記