SSHの鍵ペア生成サービスの是非について - y-kawazの日記
なんと、秘密鍵、公開鍵を自動生成してくれるWEBサービス！！ http://d.hatena.ne.jp/daigaku-syokuin/20100905/p1 このエントリがはてブコメントで批判され気味のようだが、本当にそこまで非難されるべきサービスなのだろうか？ 僕も最初はこれ駄目だろｗと直感的に思ったんだが、よくよく考えてみたらちょっと条件がつくけど鍵ペアの生成自体には別に問題なんじゃね？と思い直した。 追記：（注意）このエントリの前半部は「ある閉じたシステム利用の為の鍵生成サービスの是非」について考察しています。後半部では違った結論もあるので読むなら最後までちゃんと読んでね。 鍵生成自体は問題ないんじゃね？ 僕が思うにキーペア生成WEBサービス自体は以下の条件がクリアされていれば問題ないと思うのよ。 通信路がちゃんとした証明書付きのhttpsであること。 生成された秘密鍵がサーバ側
Pros and Cons of Listener/Observer approaches to notify Model changes
In my own experience: Delegation: PRO: use only when you have a single object to notify; PRO: using an explicit protocol you can document clearly your intentions; CON: can be the source of crashes and memory leaks if wrongly used (tip: don't retain delegates, assign them, and remember to deassign delegates when / if they are released!) I wrote about memory management problems generated by delegati
iPhone Development: Downloading Images for a Table without Threads
Monday, May 24, 2010 Downloading Images for a Table without Threads It is common practice in many networking libraries in many languages to spawn threads to handle asynchronous communications in the background while the rest of the program continues to function. Although this approach does work on the iPhone, it's really not the right way to do it. I've recently run across two different blog posti
こんなURI設計、どう？ - 岩本隆史の日記帳（アーカイブ）
先日書いたように、作りたいWebサービスがあります。当然ながら、まずは設計から始めなければなりません。 設計にあたっては『Webを支える技術』の第15章で紹介されているサービス設計手法を用いることに決めたのですが、URI設計のステップで、はたと考え込んでしまいました。 以下、第15章に掲載されているURI例で違和感の原因を探ってみます。 郵便番号リソースのURI http://zip.ricollab.jp/1120002これは違和感ありません。 検索結果リソースのURI http://zip.ricollab.jp/search?q=小石川ここで若干の違和感を覚えます。郵便番号データのキーである「1120002」と「search」が同列に並んでいるのが原因です。 いや、とくに気にする必要はないのかもしれません。「search」という郵便番号は今後も現れないでしょう。もし現れたとしても、ク
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
