ブックマークしました ここにツイート内容が記載されます https://b.hatena.ne.jp/URLはspanで囲んでください Twitterで共有
好奇心が旺盛な人は、目の前にある物事について反射的に考えてしまいます。わたしもそうです。暇でしょうがないときはそれでもいいのですが、いろいろ思案した挙げ句、何も得られなかったということも多いのではないでしょうか。学校で「考えたり、議論することはいいことだ」という刷り込みをされたせいか、考えること、議論していることで、何かやった気がしてしまいますが、やはり考えるべきことと、そうでないことがあるように思えます。 要領のいい人というのは、わりとオンオフがあって、優先順位の低いものについては考えずにさらっと流してしまいますが、今日は、どうやって「考えるべき問題」と「考えてもあまり意味のない問題」を分けるかについて考えていきたいと思います。 たとえば、「超能力によるスプーン曲げ」は本当かどうかという問題だと… よく、中学生のときに超能力はあるかないかについて話し合っていたものです。スプーン曲げが本当
会社によりけりですけど、個人と立場が違うから、いくらかは考えてね。IT業界なのに自由にインターネットを使えないのはちょっとね、と思うかもしれないけど、業界だからなおさら、というのはあります。僕らはユーザーである以前に専門家であると自覚しなければ。 基本的に、エロは禁止。どこアクセスしたかバレてますよ mixiとかもあまりよくない。普通私用だから。 普通のblogは微妙。技術ネタ収集ならいいかも。書き込みは控えよう。 昼休みなら私用OKでも攻撃はやめよう 2ちゃんへの書き込みは自宅でどうぞ。特に会社でVipperとかしてたら怒るよ。 アクセス履歴にドメインが残るのを忘れずに。アンテナやRSS経由だとrefererからアカウントが会社バレするからね。 会社からの書き込みは会社の名前を背負うことを自覚して。おかしなことを書いたときに新人だからと言い訳できるのは社内だけです。 作ったものを勝手に公
2024-04-272024 32% (117.2/366) April 87.4% (26.2/30) Week 17 74.8% (5.2/7) Day 27 Sat 24.2% (5.8/24)
<あらかじめ描いた物語>というのは、どんなときにもどんなものに対しても持っているもので、そこで多様なシナリオを持つことが、理解力とか、現実を受け入れる許容力を表すようにみえる。反対に、その物語をまったく持たない場合は、対象と出会うことはできなくなってしまう。好き嫌いを判断するだけの単純な物語から、複数の感情が入り混じったもの、ペーソスやアイロニーを感じ取ることのできる物語、もっと繊細で、比喩で語るほかない名前のない感慨を語る物語もある。 それがあまりに個人的な幻想に属する場合、人間関係(対幻想)では齟齬をきたすことになる。ふたりの関係は、つねに、自分の物語を相互に押し付け合っている。強弱のない対等な関係にあっても、許容力のある方が、より多く押し付けられて、それを受け入れる(あるいは反発する)、そういう関係が作り上げられる。私たちは、違いによって出会い、その違いを残したまま、違いの上に均衡を
泰介も憤慨してるようで… 多くの人と同じように、セルフのガソリンスタンドを利用していますが、レースをしていると、ガソリンスタンドを利用する機会が一般の人よりちょっとだけ多い感じがします。レース用のバイク(レーサー)は公道を走れないので、車に積んだ状態で運ぶ(Transport)わけで、給油もスタンドでバイクを降ろしてタンクに給油するってわけにもいかないので、携行缶に給油して、主にコースのピットで給油するわけです。 この「携行缶」に給油しようとセルフスタンドでノズルを缶に突っ込んだとたん、店員が飛んできて 「ガソリンタンク以外への給油はお断りしています」 とのたまうわけですよ。こちらも「危険物乙種取扱者免許」とゆーのを所持してる身分ですから、相当強気に 「消防法に準拠した携行缶なので問題はあるまい」 と反論するも、ダメの一点張りで、必死に食い下がったり、暴言を吐いたりするのは大人気ないと思う
先日学生に聞かれたんですよ。 「下流工程は大変って聞きますが、上流は楽なんですよね?」 よろしい、君はよく勉強している。でも根本的に間違っている。下流工程が辛いのは、上流工程でちゃんと仕事ができなかったからだ*1。 というわけで、主に学生向きに話を単純化して語ってみます。これが普通だとか、一般的だとか言うつもりはなく、違う視点もあるかと思いますが、一つの考え方として。 SIでのシステム開発は、建設業にたとえられます。が。 顧客の希望を聞き、設計し、施工し、引き渡す。こういった工程を踏む仕事ということで、システム開発はよく建設業にたとえられます。実際に工程管理の手法なども似通っています。ところが、大抵の場合、耐震偽造をした建築物よりもシステムのほうが脆弱に仕上がります。何故でしょうか。 一つには、建物の図面を引くには建築士の資格が必要ですが、システムの設計に資格は必要ありません。 もう一つ、
ひがさんの記事「「誰が書いても同じコード」は大事なことなのか」を読んで思ったことを書いてみる。 大手SIerは独自の重量級の開発プロセスを持つ。 それは多分、メインフレーム+Cobol時代の開発プロセスを最近のオープン系に焼き直したものに過ぎない。 その現場のプロジェクトは大規模で人数も多いから、少数精鋭チームで自由に動くわけにはいかない。 その開発プロセスの意図は、誰が作業しても同じような品質を保つ所に重点を置く。 つまり、属人性を排除しようとする。 だから、できない人もルーチンのような作業までレベルアップするが、できる人は、無駄なドキュメント作成やマネジメント、そして古臭くなったコーディング規約などの運用ルールに縛られている。 彼らのプロジェクトはタンカーのように、一度動き出したら進路を変えるのは凄く難しい。 現在の特にWebシステム開発では、頻繁なリリースによるバージョンアップが多い
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く