はてなブックマーク

Facebook上の「シェアさせて頂きました」の意味がわからない。以下、いくつかの意味解釈を検討していく。 パーミッション？ 「させて頂く」の意味がわからない。許可や承認が必要だとは思えないからだ。 そもそも投稿者がシェアされたくない場合は、シェア可能（公開 public）なパーミッションで投稿しないはずだ。例えば「友人のみ」(friends only)な設定にするだろう。 シェア可能な設定で投稿されているということが、すでにシェアの許可を意味している。「シェアしてもよい」ないしは「シェアしてほしい」といった意図があるからこそ、シェア可能な投稿にしているはずだ。 だから、わざわざ「させて頂く」という意味が分からない。敬語が過剰で、誤用だと感じる。「シェアしました」でいいだろう。 感謝の表明？ あるいは「シェアしました、ありがとうございます」ならわかる。しかし、感謝の言葉なしに「シェアさせて

いっときPR配信サイトのフィードを購読して、ウェブ業界のあらゆるニュースリリースをウォッチしていた気持ち悪い人は私です。 10年くらい前の話です。 いろんな学びがありましたけど、端的に言えば昨今「グロースハック」と呼ばれてるような手法の重要性に気づきました。 人はウェブページを開いて1秒以内に「自分には関係ない」「理解できない」という意思決定をして去るよなあ、という当時ヤコブ・ニールセン博士が言ってたことを実感したんです。あらゆるニュースリリースを大量に読みまして。 さて、昨今「グロースハック」が流行っております。たいへん結構なのですが、問題は「10年前にウェブ業界がとっくに通り過ぎてきたノウハウ」を、またやりなおしてる感があるんですね。 まずは歴史に学んだ上で、その上に構築していったほうがいいのにね。残念です。 大橋ぜんたろう氏が開発したプロパテンション指数とか、知らんでしょ、最近のグロ

「やぁ、ビル・ゲイツだけど何か質問ある？」ということで本人が降臨して次々と回答した全問答まとめ - GIGAZINE 原文：Hello Reddit – I’m Bill Gates, co-chair of the Bill & Melinda Gates Foundation and Microsoft founder. Ask me anything. : IAmA 09：スティーブ・ジョブズはアシュトン・カッチャーが演じました。ビル・ゲイツは誰に演じてもらいたいですか？ サミュエル・Ｌ・ジャクソン というやりとりを見て、「黒人俳優の名前をあげるなんて、ビル・ゲイツさんはシャレがきついなあ」と面白がっていたのだが、原文で裏を取ろうとしたら、GIGAZINEに騙されていたことが分かった。 誤訳というかなんというか DepartmentOfWorks: Steve Jobs had As

ネイティブとHTML、その決定要因としてのプッシュ通知 現状、「単にスマホに情報提供したい」だけでもネイティブ・アプリを作りがちですが、その主要な理由の一つがプッシュ通知。 iOSもAndroidも、端末にプッシュ通知したければネイティブ・アプリを作らなければならない。 サードパーティ「通知センターアプリ」 そこに目をつける人は当然いるわけで、この問題を解決するスタートアップがあります： Boxcar Pushover これらを「通知センターアプリ」と呼ぶことにします。この仕組みによって、ネイティブ・アプリを作らなくても、ウェブサイトから端末にプッシュ通知を送信できるようになります。 発想としては「端末へのプッシュ通知のためにはネイティブ・アプリが必要」「でも、たかがウェブサイトが、いちいちネイティブ・アプリなんか作るのは…」「そうだ、ぜんぶまとめて一つのアプリにすればいいじゃん！」という

同じ「部品」の意味で、英語には “component” と “module” がある。その違いを考えた。なお、オブジェクト指向、ドメイン駆動設計の観点である。 （以下の定義や解説は個人的な見解に過ぎないのであって、「言葉の意味の押し付け」と誤解されないよう願いたい） 定義 component は object の部分集合である (object ⊇ component) module は component の部分集合である (component ⊇ module) module は「元の context を離れて再利用できる component」である（実際に再利用したかどうかではなく、可能性の問題である） 解説 ドメイン駆動設計における「ドメイン」の特徴は固有性にある。汎用性ではない。 “module” には standard （標準）や dettach（取り外し）の意味が含まれる。 ゆ

最近、ScalaとSmalltalkを触っていて思ったこと。 一見すると、関数型は「データ」より「処理」を重視しているように見える。 関数型プログラミングパラダイムそのものは「副作用のない関数」の合成による演算の恩恵を最大限に享受するパラダイムだ。副作用がないので並列演算の高速化に向いている。 昨今のマルチコア化やクラスタ化のメリットを最大に活かすには関数型プログラミングパラダイムの導入が鍵だろう。プロセッサ単体での性能向上が頭打ちになってきたのだから、並列演算に対応したプログラミング方式へのシフトは不可避だろう（ただし高性能が要求されない分野は除く）。 関数型プログラミングパラダイムは、データよりも処理を重視したパラダイムのように見える。 一見すると、オブジェクト指向は「処理」より「データ」を重視しているように見える。 オブジェクト指向プログラミングパライダムは、（Smalltalk的に

404 Blog Not Found:プログラミングとアプリ開発の違い プログラミングしたい人々は、物が出来るまでの過程を楽しみたい人である。だから、「DBにクエリーをかけてHTMLにぶちまけるだけの簡単なお仕事」が退屈で仕方がない。しかし、アプリ開発したい人々にとって、物ができるのは出発点にすぎない。彼らが楽しむ過程というのは、それを公開し、それを人々が使ってみるところにある。それがただのハッシュなのか人工知能なのかというのは、はっきり言っておもちゃの材質程度の意味しかない。 「DBにクエリーをかけてHTMLにぶちまけるだけの簡単なお仕事」と「コンピューター・サイエンス全開のハイソなプログラミング」の二択ではなくて、第三の道があります。 それは「モデルの持つ概念の力を活かしてビジネスをモデリングするアプリケーション・エンジニアリング」です。 『エリック・エヴァンスのドメイン駆動設計　ソフ

オブジェクト指向も、MVC (Model-View-Controller) も、アジャイル開発 (XP: Extreme Programming) も、テスト駆動開発も、Smalltalkから生まれた、っていうことについて、徐々に体得的に実感できつつある。 現代のエンジニアリングの潮流がSmalltalkに由来するということは、そこに何か非常に重要な本質が潜んでいる可能性がある。 また何か書きたい。 とりあえず現時点でほとんど確信しているのは、現代のエンジニアは教養としてSmalltalkをやっとくといい、ということだ。仕事でSmalltalkを書くかどうかは関係なく。 関連情報 Smalltalk入門 (全16回) - プログラミングならドットインストール オブジェクト指向９つの簡単なルール 読解いやな法則: にわかな奴ほど語りたがる PharoCasts: Display Picasa

【これはとてもひねくれた文章なので、「実用的な情報を速やかに収拾したい忙しいビジネス・パーソン」は読まないほうがいい。警告はした】 【役立つ部分をさくっと読みたい方はシンプル版を用意しました】 fladdict氏の『スマホUI考（番外編）　顧客やユーザーの要望に全て対応すると、アプリは99%破綻する』は素晴らしい記事だ。 その記事のコメント欄でのやりとりが気になった。 【某氏】　先生！　設定画面で全てのUI機能要素を　ON/OFFしたり、configファイルの編集でボタンのレイアウトを変更できれば良いと思います！ 【fladdict氏】　その思想をつきつめると、設定オンオフで音楽プレイヤーからFacebook閲覧までユーザーが自在に切り替えられる万能アプリへの道に進むのです・・・ 【某氏】　やりたいことが何でもできる万能アプリの複雑性と、デフォルト設定のシンプルさは両立しますからね。初めて

第1回SEMATカーネル勉強会に参加しました。 SEMATカーネルとは、SEMATというプロジェクトの核(kernel) SEMATとは、ソフトウェア工学(software engineering)を「再建」しようとする試み 詳細は省略しますので、平鍋氏の『SEMAT.org にて「ソフトウェア工学再建」運動が開始：An Agile Way』という記事や、SEMATの詳細をご覧下さい。 ※ちなみに"SEMAT"の発音は「シーマット」(sea-mat)でいいようです。SEMAT創始者Ivar Jacobsonのスピーチによると。 品質・テストの重視は日本の独自性 さて、第1回SEMATカーネル勉強会の内容については、最後の課題共有ワークショップが面白かった。参加者から提出された課題のなかで、一番多かったのが「個人のスキル」で、二番目が「品質・テスト」でした。 たしか『ソフトウェア企業の競争戦

意外とこういう話を聞かないので、ぼくの理解が間違っているかもしれないという前提で、書いてみますが。 概要 ふつう「CEO」という肩書きは米国型のコーポレート・ガバナンス（企業統治）を示唆します。それと異なる統治形態の企業が「CEO」という肩書きを使うと、受け手に誤解させる可能性があります。 本文 中小企業の社長が「CEO」って名乗ることが増えましたよね。これがいわゆるオーナー企業でワンマン企業だったりすると、けっこう違和感あるんですよ。本来「CEO」は「社長」の英訳ではありませんね。「CEO」という言葉の背後には、コーポレート・ガバナンス上のいろいろなものが示唆されます。 具体的に言うと、外部資本、社長以外の取締役、社外取締役、取締役会の開催などのいずれもが欠けているような会社で、"Chief Executive Officer" って、ちょっと意味が分からないんですよね。 コーポレート・

保存アイコン＝フロッピーディスクの時代は終わった…？ | MEMOPATCH を見て「保存ボタンとか無くしていこうぜ！」って書こうと思ったらすでに長谷川恭久さんが言及してた： 保存アイコンでみえてくるアイコンデザインの勘違い : could 別の議論で、そもそも「保存」という機能はいらないという意見もあります。私が愛用している Byword も保存という概念がなく、いつの間にか iCloud 経由で同期されているのが好きな点ではあります。しかし、すべての「保存」がこうした自動化がふさわしいのかというそうではありません。バージョン管理のようなコミットというアクションも含めた保存は自動化は適切ではないですし、保存というアクションがあることで利用者が自分で操作をコントロールしているという安心感もあります。 うん、「コミット」の意味論は、人の明示的な操作を要するよね。そういうのは単純な「保存」とは

DCIとDDD DCIアーキテクチャ - Trygve Reenskaug and James O. Coplien - Digital Romanticismを読んだり、DCI meetup w/ @jcoplien for Rubyistsに参加したりして、DCIアーキテクチャについて考えてきた。 DCIはメッセージパッシング指向だ。そのSmalltalk的なオブジェクト指向の原理はいいけど、実装が嫌だ。 そもそも、DCIアーキテクチャ提唱の目的は、メンタルモデルのセマンティクス・ギャップを埋めることだ。DDDの「ユビキタス言語」も、メンタルモデルのセマンティクス・ギャップを埋めるための要素であり手法だ。だから、ふつうにDDD（ドメイン駆動設計）をやればいいと思った。 DCIへの疑問 DCIでは、「オブジェクトのアイデンティティ」にこだわりすぎていることで、アーキテクチャが複雑になって

一般的に使われる "ID" は "identifier" （識別子）の意味であって、 "identity" （同一性）の意味ではない。ぜんぜん違う。 Conflict システムの実装上、 ID が衝突 (conflict) することはありえる。複数の別々のものに同じ ID を振ってしまう問題を、 ID の「衝突」という。 「本来異なるもの」を「同一である」と誤認することが起こりうる。それは「 ID が衝突した」という事態に気付かずにシステムを運用した場合に生じうる。 （それ以外にも、同定 (identification) のプロセスにおけるミスやバグなどといった理由も考えられるが、本題ではない） Equivalency ID の衝突は、存在 (existence) の「重複」などという意味ではない。そもそも存在は「重複」しない。「同じものが二つ存在する」ということはない。 二つ以上存在して

『社内LAN撲滅運動 - ISO27001(ISMS)認証を取得しました』という素晴らしい報告がありました。 私たちは、社内LANとインターネットとを区別するのではなく、クラウドを利用してネット上に仮想のワークスペースを作り、それを場所を問わず使えるようにするという方針でセキュリティと業務の両立を図りました。 テレワーク化を推進するために、こういう事例を参考にしています。 現時点での懸念は、「IPアドレス制限」という認証方法が使えなくなることです。 補足しますと、ウェブサービス開発をする場合には、 開発環境へのSSH, HTTP(S)アクセス 本番環境の管理画面へのHTTPSアクセス などを固定IPアドレスベースで制限することがあります。例えば「事務所のIPアドレス」で制限することにより、「従業員によるアクセス」であるという認証になっているわけです。 しかし、「事務所のLAN」がなくなると

これから述べる分散オブジェクト・アーキテクチャに近いフレームワークやアプリケーションの実装がすでにあれば教えて頂けると助かります。 背景：ゼロベースの管理会計システムを開発するよ。 （凡例：追記と削除） 目的 ドメイン駆動設計(DDD)を原理的に突き詰めたアーキテクチャによって、オブジェクト指向プログラミングの作業から、インフラストラクチャ層に関する配慮がほとんど不要になる。SQLもデータスキーマ設計も不要になる。 といっても、Ruby on RailsのActiveRecord的な話ではないので、誤解なきよう。むしろ正反対。リレーショナル・データベースを使わない。 ドメインのオブジェクトをシンプルに書けばシステムが実現するようになる。一言で言えば、「GOOS/DDD原理主義者のためのフレームワークが欲しい」という話。 ウェブ・アプリケーションの三層アーキテクチャ再考 ウェブ・アプリケーシ

『分散オブジェクト・アーキテクチャ／ドメイン指向アーキテクチャ』について考えるなかで、「永続化」への理解が深まった。というか、このアイデアについて人と話してもかみ合わない理由が分かった。とどのつまり、ぼくが独特な感覚を持つマイノリティだったのだ。 たぶん、ふつうのプログラマから見れば、おそろしくどうでもいいことにこだわっている、ように見えるだろう。 信仰告白 ぼくは現在主流の「データベースを使った永続化」が大嫌いだったんだ。ORMとか一体何なんだ。知らんわな。なんでプログラムを書くのにSQLを書かなきゃならんのだ。（※個人的な感じ方の問題です） 「RDBからSQLでデータをとってきてHTMLで整形して出力するPHPプログラミング」なんて二度とごめんだ。データベースのために働いてるみたいじゃないか。（※個人的な感じ方の問題です） 「データベースを使った永続化」が行き過ぎると「データベース中心