ときどきの雑記帖'

I'd just be the catcher in the rye and all. I know it's crazy, but that's the only thing I'd really like to be. I know it's crazy.

The catcher in the rye
J. D. Salinger

著作権保護期間の70年延長に反対

検索エンジン経由でこられた方へ

このページの内容は日々更新されます。 そのため、検索エンジンに引っかかったものがここに残っているとは限りません。

最新エントリ (何日分あるかは不定)

2014年04月19日

■_

あ、今週も別のところでやるのかアレ。 千葉県千葉市のQVCマリンフィールドに全高約8mの「実物大イングラム」登場 | マイナビニュース

ちょっやってみようかなという気になっている。 Build Your Own Lisp

■_

安全なソフトウェアシステムを実現するための新たなアプローチ | SWE iPedia このリンク先にあるpdfを読んだのだけど面白かった (対談のひとりは「セーフウェア」の人)。

■_

近刊でこんなのを見つけたんだけど… Amazon.co.jp: 超高速開発が企業システムに革命を起こす: 一般社団法人ICT経営パートナーズ協会, 関 隆明: 本

Amazon.co.jp: 超高速開発が企業システムに革命を起こす: 一般社団法人ICT経営パートナーズ協会, 関 隆明: 本

内容紹介

必要な情報システムをスピーデイに開発し、柔軟に変えていくことのできる手段として、超高速開発という考え方とそれを
支える超高速開発ツールが注目を浴びています。ここでいう「超高速開発」とは、単にプログラムを自動生成する機能だけ
ではなく、業務のデザインから運用・保守工程をも含めたシステム・ライフサイクル全般にわたる生産性向上と継続的品質
改善のやり方を意味します。ユーザ企業はもちろん、今までプログラミングの知識がないという理由でシステム開発を対象
外と考えていた経営指導の専門家の人達にとっても、経営や業務知識をベースに情報システム開発が行える有力な方法にな
る可能性があります。2013年8月にソフトウェアの生産性を高める超高速開発ツールベンダ13社が集まって、「超高速開発
コミュニティ」が発足しましたが、本書はそのコミュニティのまとめ役であるICT経営パートナーズ協会(会長は元NECソフ
ト社長・会長、元ITコーディネータ協会会長の関隆明 氏)のメンバーが分担して原稿執筆にあたりました。また付録には、
ベンダの寄稿による各社のツールの概要をまとめています。


推薦のお言葉
以下略

ちょっとどんなんだか見てみたい(買うかどうかは微妙

■_

あとでよむ(んじゃないかな) Buggy Security Guidance from Apple | Random ASCII

Buggy Security Guidance from Apple | Random ASCII

In February 2014 Apple published their Secure Coding Guide. I glanced through it and noticed that their sample
code for detecting integer overflow was buggy – it triggered undefined behavior, could be optimized away, and
was thus unsafe to use.

■_

2014年04月18日

■_

ワタクシが勤務しているところの事業所の話なんでございます。 トイレは何ヶ所かにあるのですが、そのうちの一ヶ所の数台ある小便器のうちの二台が 長いこと(はっきりとは覚えていないのだけど少なくとも二か月くらい?) 「故障中」のまんまでありまして。 まあ個室の中のアレに比べれば緊急度は低い(満室になることもしばしば)のでしょうけれども それにしたって月単位で放置ってのはどういうことなのよ。と。 「経費節減」の一環なんですかねえ…

朝の出勤時。 雨が降ってたおかげで傘を差して自転車を運転して駅へ向かう人と(ry

■_

■_

■_

2014年04月17日

■_

transcompile。 という言葉を知った今日このごろ。

■_

Those Who Say Code Does Not Matter | blog@CACM | Communications of the ACM By Bertrand Meyer Meyer 先生の記事。 C のように、if の後なんかに「単文」か「複文」(compaund statement) が来るという構文は問題なんじゃないの? というお話。

Those Who Say Code Does Not Matter | blog@CACM | Communications of the ACM

The proper language solution is to do away with the notion of compound instruction as a separate concept, but
simply expect all branches of composite instructions to consist of a sequence, which could consist of several
instructions, just one, or none at all. In Eiffel, you will write

if  c then
    x := y
end

or

if  c then
    a := b
    x := y
else
    u := v
end

or

from i := 1 until c loop
    a := b
    i := i + 1
end 

or

across my_list as l loop
    l.add (x)
end

ふと、 null参照の考案は10億ドル単位の過ち? | スラッシュドット・ジャパン デベロッパー と対比してどうなのかなあと思った。 まあさすがにこれを越えるってこたあないだろうけども。

■_

2014年04月16日

■_

エンジニアリングの真髄―なぜ科学だけでは地球規模の危機を解決できないのか
エンジニアリングの真髄―なぜ科学だけでは地球規模の危機を解決できないのか この本を読み始めたのですが面白いです。 んが、科学と工学じゃなくて、科学とエンジニアリングみたいに書いているのがちょっと気になる。 タイトルにも使ってるからそうしてるのかなあ。 いやまあサイエンスとエンジニアリングみたいに書かれても色々むずがゆくなりますが。 ところでこの本、原題は Essential Engineer なんですね。 そのまま訳すと「理想のエンジニア」あたり? つまりは、原題では人(=エンジニア)を表すものなのに翻訳書のタイトルがこうなるのは面白いなあ。と。 ここまで読んだところでは翻訳書のタイトルでも悪くはないと思います。

■_

■_

R で。

> 1:10
 [1]  1  2  3  4  5  6  7  8  9 10

↑これを、このように↓書けるとは知らなかった (':' を関数として呼び出しているということらしい)

> ':'(1,10)
 [1]  1  2  3  4  5  6  7  8  9 10

■_

セーフウェアの著者の最近の本なのだけど、 PDF が Free Download って。 ありがたやー Engineering a Safer World | The MIT Press

セーフウェア 安全・安心なシステムとソフトウェアを目指して (IT Architects’Archive)
セーフウェア 安全・安心なシステムとソフトウェアを目指して (IT Architects’Archive)

2014年04月15日

■_

第1回 「データ解析のための統計モデリング入門」 読書会 - connpass この本買って読んではいるんだけどなかなか頭がついていかないんだよな ○| ̄|_ まあ会社に置きっぱなしで、会社でしか(必要なときに必要そうなところだけを) 読まない ってのもあるんだけど。 大学で統計学やったけどそんなに深いところまでやってないし。

色々知識不足(と能力不足)を感じるのだけどどうしたものやら。 特に数学 ○| ̄|_

■_

久しぶりに SRGM 関連。 なんというかうまいキーワードがなかなかないんだけど、 それでも英文記事をあたった方が面白そうなのが多いのはどうにかならないのかねえ。 IEEE Xplore Abstract - On the Trend of Remaining Software Defect Estimation

IEEE Xplore Abstract - On the Trend of Remaining Software Defect Estimation

Software defects play a key role in software reliability, and the number of remaining defects is one of most
important software reliability indexes. Observing the trend of the number of remaining defects during the
testing process can provide very useful information on the software reliability. However, the number of
remaining defects is not known and has to be estimated. Therefore, it is important to study the trend of the
remaining software defect estimation (RSDE). 以下略

これだけ見ると読みたくなるんだけど「payment wall」の向こう側なんだよなあ

■_

日本語のも一つ。 CiNii 論文 -  傾向曲線に基づいたソフトウェア信頼性モデルに対するパラメータ推定(システム評価・管理技術)

CiNii 論文 -  傾向曲線に基づいたソフトウェア信頼性モデルに対するパラメータ推定(システム評価・管理技術)

ソフトウェアのテスト工程において検出されるバグの累積総数を予測する方法の1つに,ゴンペルツ曲線やロジスティック曲
線などの傾向曲線を基本とした回帰モデルがある.しかしながら,本来は確率的な計数過程として記述されるべきこれらのデ
ータに対して,確定的な曲線とその観測誤差に基づいた回帰モデルを適用したとしても,バグ総数の推定精度がつねに向上す
るとは限らない.一方,ソフトウェアの信頼度成長現象を柔軟に表現する計数過程として,非同次ポアソン過程(NHPP)を用い
た確率モデルが提案されているが,そのいくつかはパラメータ推定に関する厳密な議論がなされていない.そこで本論文では,
ゴンペルツ曲線やロジスティック曲線などの回帰モデルと対応付けされるようなNHPPを用いて,ソフトウェア信頼性モデル
に対するパラメータ推定問題を再考する.

なんというか、発見される(「摘出」などとは意地でも言ってやらない)バグの数の 収束状況の(ある程度の) 判断、判定には使えるかもしれないけど 「バグ総数の推定」とかは当てにできないんじゃないかなあ。 というか世間一般(てなんですか)で SRGM がどれだけどのようにつかわれているか疑問に感じるんですが。

■_

「Design-Challenged」ってのは Design の方面に才能がないとかいうことですよね。たぶん。

10 Resources for Design-Challenged Programmers

10 Resources for Design-Challenged Programmers
Posted on August 29, 2010 by dhirschl —

When it comes to design, why do programmers tend to have difficulty in creating a simple and user-friendly
user interface?

Perhaps because programmers are traditionally left-brained and more focused on logic, analytics, objectivity,
etc. This type of thinking is encouraged in academics.

で、10個紹介されてると。「left-brained」ってのは「左脳型」かな。 この後の文章に Designer は right-brained だとかでてくるし。

■_ 解析機関

History of computing part 1 | Linux Voice 「階差機関」の方は「プログラムする」ようなものじゃないと思うんだよなあ。やっぱり。 それはさておきこの記事のコメント欄

History of computing part 1 | Linux Voice

I saw a TedEd video a few months ago on the Analytical Engine. It was a good watch and I recoment people search
for it on the TedEd YouTube channel. This artical does go a little further in explaining the operation very well.

え、そんなものが

おー、なんかたくさんあるぞ charles babbage analytical engine - YouTube

■_


過去の雑記帖

  1. 2014年4月(下旬)
  2. 2014年4月(中旬)
  3. 2014年4月(上旬)
  4. 2014年3月(下旬)
  5. 2014年3月(中旬)
  6. 2014年3月(上旬)
  7. 2014年2月(下旬)
  8. 2014年2月(中旬)
  9. 2014年2月(上旬)
  10. 2014年1月(下旬)
  11. 2014年1月(中旬)
  12. 2014年1月(上旬)
  1. 2013年
  2. 2012年
  3. 2011年
  4. 2010年
  5. 2009年
  6. 2008年
  7. 2007年
  8. さらに前
リンクはご自由にどうぞ。

メールの宛先はこちらkbk AT kt DOT rim DOT or DOT jp