01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
http://www.slideshare.net/nekoruri/20130301-twitter-oauthvulnerability
今回の名言
(malaさんのgist:5062931より)
ユーザーの自衛策として「怪しいリンクをクリックするな」というのは無茶なので、
そういった対策が必要なものはバグです、セキュリティホールです。
怪しいリンクをクリックできない世界のほうが間違っている。
たしかに。
http://www.atmarkit.co.jp/ait/articles/1402/27/news021.html
要求者と作成者のギャップを埋めるために、マインドマップを使おう、という話。
開発者の中では常識となった便利なツールを別の業界とのコミュニケーションにも活用しよう、
という流れは、どんどん進むんだろうな。
もちろん逆もあるとは思う。
他の業界の素敵なノウハウで、IT業界にも生かせそうなことはまだまだ沢山ある。
交流大事。
http://www.sponichi.co.jp/society/news/2014/02/26/kiji/K20140226007668140.html
新定理では、どんな大きな数でも、600個ごとに区切ると素数が
2個含まれる場合があると分かった。
必ず2個あるわけではないが、2個の素数が含まれる600個ごとの区間は無限に存在する。
今後の研究で、区間の幅は600個より少なくなる可能性もある。
素数の桁数がいくらでも増やせるのがわかったってことは、
暗号強度もどんどん上げられるってことかしらね。
http://gori.me/lifehack/47302
両端を剥いて息を強く吹きこむだけ。
生タマゴを混ぜておくと面白いような気がする。
http://brevis.exblog.jp/21721306/
トヨタと日産の生産方式は、用語は違うが、似ているところもたくさんある。
自動車という複雑かつ大量の機械製品を扱う以上、当然のことかもしれない。
そして両者とも、顧客の需要に合致したプル型生産を行っている。
トヨタはこれをジャスト・イン・タイム(JIT)と呼び、日産は同期生産と呼ぶ。
だが、同じプル型生産といっても、じつは根本の思想がかなり違う、というのが、
見てきた仲間が語ったことだった。
日産の場合、生産側でなんとか誤差を調整しようとするらしい。
ところが、トヨタのやり方は全く違う、という。
まず、トヨタは意図的にバッファー在庫を持っている。
...
いくつか、意図してバッファーを持っているところがある。
そして、受注が確定したら順序計画で引き当てていく。
まるで、デル・コンピュータのBTO(Build to Order)方式である。
「内示でPushして、かんばんでPullするのがTPS(トヨタ生産方式)だ」
と表現されている。
両者のどちらがベターかについては、議論もあろう。
ただ、生産側と販売側と、どちらが市場に近く、どちらが需要(の変動)
に敏感かといえば、やはり販売側ではないかと、わたしは考える。
だとしたら、敏感な側に、より責任を持ってもらう方が合理的なのではないだろうか?
システム開発においても、敏感な側、つまり発注側に、より責任を持ってもらうほうが
合理的な気はするなあ。
http://www.slideshare.net/chikayossy/janog-apricot2014
http://blog.livedoor.jp/ryoma307/archives/7575490.html
最も弱い立場の子どもらがどう扱われるかで社会の健全さが測られる。
社会の健全さがどんどん失われていってる気はする。
行政、司法、立方、マスコミ、ネット上の若者、コミュニティ、会社、
ありとあらゆるところで、弱者いじめが横行してるように見うけられる。
弱者にこそ、北風より太陽を。
創価学会の人々、朝鮮半島の人々、暴力団、は元々は社会的弱者だよ。
とりあえず手が届く範囲だけでも、健全さは保たないと駄目だと思うんだよね。
いじめはひとりひとりがちゃんと是正できるような風潮にならんかのう。
教育が鍵な気はするけど、教育現場の疲弊は半端じゃないしな。
ただ、外から見ると、弱者だと思ってる側が実は強かった、っていうケースもあるので、
第三者的介入はとっても難しい。
九州地方における伝統的な夫婦関係とか、SMプレイとかの強弱は、本人達以外はわからないので、
そこは生暖かい目で眺めてるのが正しいとは思う。
http://www.creationline.com/lab/3080
- 唯一の板前(Chef)がバスやトラックに轢かれたらどうする?
- 板前(Chef)はアプリケーションを設定します
-- 開発者は板前(Chef)よりもアプリケーションについて知っています
-- 開発者にCookbookを書かせたり管理させましょう
- そうすれば、みんなが製品に対して責任を持つことになります
みんなでやるのが一番大事ってことだよな。
先日職場で同じような話をしたばかりだ。
おさらい: 10のアンチパターン
- すべてのChefデータを1つの巨大なGitレポジトリに入れてしまう
- 会社名つきの巨大なCookbookを作ってしまう
- "Environments"を単なる論理的な「環境」以上の目的で使ってしまう
- Community Cookbookをフォークしてしまう
- Role内でrun_listを管理してしまう
- 無秩序なdata bagを作ってしまう
- chef-shellを知らない、使わない
- LWRPを怖がってしまう
- NIH症候群 (外部発祥だから利用しない症候群)に陥ってしまう
- 孤独なChef使いになってしまう
2021 : 01 02 03 04 05 06 07 08 09 10 11 12
2020 : 01 02 03 04 05 06 07 08 09 10 11 12
2019 : 01 02 03 04 05 06 07 08 09 10 11 12
2018 : 01 02 03 04 05 06 07 08 09 10 11 12
2017 : 01 02 03 04 05 06 07 08 09 10 11 12
2016 : 01 02 03 04 05 06 07 08 09 10 11 12
2015 : 01 02 03 04 05 06 07 08 09 10 11 12
2014 : 01 02 03 04 05 06 07 08 09 10 11 12
2013 : 01 02 03 04 05 06 07 08 09 10 11 12
2012 : 01 02 03 04 05 06 07 08 09 10 11 12
2011 : 01 02 03 04 05 06 07 08 09 10 11 12
2010 : 01 02 03 04 05 06 07 08 09 10 11 12
2009 : 01 02 03 04 05 06 07 08 09 10 11 12
2008 : 01 02 03 04 05 06 07 08 09 10 11 12
2007 : 01 02 03 04 05 06 07 08 09 10 11 12
2006 : 01 02 03 04 05 06 07 08 09 10 11 12
2005 : 01 02 03 04 05 06 07 08 09 10 11 12
2004 : 01 02 03 04 05 06 07 08 09 10 11 12
最終更新時間: 2021-03-02 14:20