2002-07-13
_ 音楽
手もとにあるマリちゃんのアルバムを全部 mp3PRO にえんこど。けっこうな時間がかかったっす。
あと、music clipに COWBOY BOBOP のAsk DNAとO.S.T FUTURE BLUESを入れました。やっぱこっちのほうが落ち着くれす。
_ 飯
両親が昼間からどこかに出かけたんですよ。どこぞに出かけるのはいつものことだからいちいち訊かなかったんだけど。
夕方ころに「 飯はてきとーに食っててくれ 」と連絡があったんですよ。じゃ、てけとーに食うかなぁ とか考えてたんですよ。近所の定食屋かしらねぇ。溝の口あたりのラーメン屋かねぇ。とか。
そんなことをマリちゃんの歌をアルバム的に Pure から聴きつつマターリと考えながらちんたらしてた午後 7 時。両親が帰宅したぽいんですよ。なんかいつもと様子が違うんですよ。お客さんですよ。誰かと思ったら兄上家族ですよ。もうあれですよ。マリちゃんの歌は「 だいすきなうた 」に入って良い気分だったのに兄上家族は子連れでチラホラ。孫が居るからヲレの両親はデレデレ。その孫はヲレを見ると泣きだしやがるし。FreeBSD の buildkernel したら filesystem full とか言われるし( それは関係ない )。なんだってんだ。気分悪い。
たくみはどーしてるかなぁと聴いたんだけどどいろいろ用事があるみたいで、いのうえさんを IRC で呼んでみたんだけど反応が無かっただ。そんなわけで馬車道＠京王多摩川店。ひとり。
夏メニューでした。最後に馬車道に逝ったのは、ろみたんを迎撃しに逝ったときかな。そのときからメニューは変わってないのね。
ひとりでちんたらと過ごしながら終了。さくっと帰宅。
_ 月下美人
咲きました。どうですかお客さん。
2003-07-13
_ 機動戦士ガンダムREPREVIEW 0079 to 0083
再生しようと思ったが出来なかった。見ると手もとのWindows Media Player が 7.x だったので 9.x に版上げ。見れた。萌え萌え。
_ 読書
今日は「ジオニックフロント 起動戦士ガンダム」を読み。
_ ジオニックフロント
1 巻読み終わり。来ましたよ殺戮。
_ 買物
玉川高島屋ガーデンアイランドにてちょっとしたものを買物。
_ ジオニックフロント
2 巻読み終わり。全 2 巻なのでこれで終了。
敵どうしでライバルのような存在。0083 でいうコウ・ウラキとアナベル・ガトーみたいな。「 またしてもあいつか！ 」ていうの。いいね。
主役部隊「 フェンリル隊 」に都合良く進んでくのはちょいと物足りないけど、V ガンダムのシュラク隊みたいに全滅するよりはだいぶマシだろう。
ただ、なんだかんだで無敗のフェンリル隊にたいして、そのフェンリル隊にやられっぱなしのエイガーが役者として釣りあっていなかった。「最後の戦闘」でもエイガーは戦士としての未熟さを出してたし、だから結局「エイガーもフェンリル隊の敵ではなかった」という印象がある。
あと、最後のエイガーのセリフを吐かせるためにには物語としてもーちょい準備が欲しかった。「最後の戦闘」ではエイガーはフェンリル隊を仲間のカタキとして見てたのだが、その印象があるので最後のセリフをエイガーに言わせるためにはフェンリル隊とエイガーとの精神のつながりが欲しかった。フェンリル隊とエイガーで会話するとかなにか。
シャルロット萌え。
_ 起動戦士ガンダム戦記 Last War Chronilles
キャラクタの絵が WOLF's RAIN ぽいなと思ったら本文イラストが川元利浩だった。
_ ID
23 歳になった真綾が歌いなおしたということで 23 カラットらしい。
真綾「 右ほっぺのニキビですよ。そんな時代もありますよ。」
深い意味があるんだだろうか。
指輪 -- 23 カラット -- ♪
シマシマ♪
今週の目標「 たまには思い出の整理をしよう 」
2004-07-13
_ 朝
ぐでっと風呂掃除。
_ いけね
またコーヒー買おうとして誤って マミー買ってしまったよ。
_ MTB
近所をてきとーに走ってみた。
さすがに姿勢が慣れないので腰がひけてるかもしれない。
そおいや防犯登録してない。いつもは自転車を買った店で登録してるのだけど、友人から買った場合はどこで登録すればいいのだ。
警察？
_ FF10
シン。ギガグラビトンだかいうのやってくる。シンのオーバードライブゲージが溜る前に HP 14 万を削る必要がある。技を食らうとゲームオーバー。技を使ってくるときに召喚獣を犠牲にしようとしたけどやっぱりダメだった。全部の召喚獣のオーバードライブ技を炸裂させても召喚獣 1 体で HP 9999 削れるけど 14 万にはとうてい届かない。
こんなの倒せるかー。
飛空艇でちんたらサーチして遊んで 2 箇所発見。とくに対策を思い付かなかったのでそのままやめ。
_ ぐで
1930 〜 2300 昼寝。
2006-07-13 :-)
_ 仕事
0730 寒川。
_ 語彙
抽象的な言葉より具体的な言葉を使う。
そのほうが文章が分かりやすいからだ。
そのためには言葉をたくさん知る必要がある。語彙を増やす。
語彙が多ければ多様な文章を書ける。ひとつのことを表すためにたくさんの言葉を使える。
語彙を増やすためには書きたい分野にたいする知識が必要だ。
そうすれば
「 ノビヨの曲は FF 2 『 戦闘シーン 2 』や FF 8 『 Force Your Way 』や FF 10 『 シーモアバトル 』のような妙に音がつながってる曲が特徴だよね 」
などと意味不明な文章にならなくて済む。
_ ぴあデビューレビューVOL.121
IRC で話題になってたので Bahashishi は知らないんだけど申し込んだ。
当選した。
◆日程:2006年7月18日(火)
◆会場:duo MUSIC EXCHANGE<渋谷>
◆18:00開場／19:00開演
◆出演：Bahashishi
7/18 って通常の平日っすね。
厳しいな...。
_ 飯
派遣先の 10 周年記念イベントとかいう。
以前懇親会を開催してもらった 創作和食料理 天青 と同じく熊澤酒蔵のお店 [2005-12-15] 。
湘南ビター。
湘南リーベ。黒ビール。
すぐ目の前に釜があって、そこでピザを焼いていた。焼きたてのピザーとか。チーズケーキはみんな食べないのでもったいないからバクバク食ってた。
- サイボウズを使うと言っても人間対人間のコミュニケーションは大事だろ
- ホウレンソウ
- ブラックボックス化してはいかん
- skype いいよ、skype
デジカメがないのでケータイカメラでがんばる。
_ Mozilla Firefox 2 Beta 1 Release Notes
というわけでさっそくインストールしてみた。
Firefox 2.0 beta1 用のディレクトリにインストールしてくれるので Firefox 1.5 との共存可能。
Firefox 2.0 を起動する前に既存のプロフィールをバックアップしておく。Firefox から Firefox1.5 に名前を変更しただけなんだけど。
Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.8.1b1) Gecko/20060710 Firefox/2.0b1
起動が速くなったかな。
拡張機能は「 アドオン 」という名前に変わっていた。はてなバーなどのアドオンはまだ 2.0 に対応してないでとっととアンインストールした。
ref.
2007-07-13
_ [自由が丘][月の雫][送別会][歓迎会]送別会＆歓迎会
Mk さん「 これの名前なんていうか分かるかね？ 」
ヲレ「 あー、えーと、アレだアレ！視力検査コア！ 」( ref. グラディウスV攻略1面 )
Mk さん「 全然違います。帰ってぐぐれ 」
wikipedia 検索したら「 ランドルト環 」というそうです。へー
ref. 視力 - ランドルト環
2008-07-13 :-(
_ 髪切った
3ヶ月ぶり
_ 住吉
頭痛
_ [霜月はるか]Haruka Shimotsuki solo live LV.2 ～シモツキンはレベルが1あがった～
＠ティアラこうとう
初めての霜月はるかライブです。
コンサートホールでの歌手ライブはかなり久しぶりであり國府田マリ子ライブに通っていたころを思い出して懐かしい雰囲気を堪能するなどしました。曲リストはきっと熱心なファンたちが書いてくれるので省略( 私の隣の席にメモを書いてるひとが居ました )。2 階席でちんたら座りながら眺めてたんですが頭が痛いしなんだか眠いのでかなり寝てました。たまには生楽器の音を聴くのも良いですな。
ところで國府田マリ子で思い出したのだけど國府田マリ子はある意味 魔力があるよなあ。
2009-07-13 :-)
_ 朝ッ
0520 起床
_ 仕事
0830 出勤。
2010-07-13 :-(
_ 朝ッ
0520 起床
_ [NetBSD][翻訳]NetBSD Blog - Interview with Soren Jacobsen
Soren Jacobsen へのインタビュー
June 25, 2009 posted by Emile Heitor
A couple of weeks ago, Guillaume Lasmayous and I threw the idea of interviewing NetBSD developers through our website, NetBSDfr, to promote the NetBSD Project, and to make their work known to the widest possible audience. Today, we are discussing with Soren Jacobsen, snj@, NetBSD 5.0 release engineer.
2, 3 週間前 Guillaume Lasmayous と私は NetBSD の発展のために我々のウェブサイト NetBSDfr で NetBSD 開発者へインタビューしよう、というアイデアを思いつき、より多くのひとに彼らの仕事ぶりについて知ってもらうことにした。今回は NetBSD 5.0 リリースエンジニアの Soren Jacobsen( snj@ ) に話を聞いた。
NetBSDfr: First of all, let me thank you for this interview. We plan to run several interviews of NetBSD developers, I think, one every one or 2 months or so. You've been chosen as the first one. Thanks for accepting to answer our questions.
snj: Thanks for asking me, and thanks for your efforts to strengthen the community. It's great to see efforts like this. Sorry it took so long to get back to you. I wanted to take some time to think over my answers. Please let me know if you think anything needs clarification.
NetBSDfr: まず最初にインタビューに応じてくれたことに感謝します。我々は何人かの NetBSD 開発者へのインタビューを計画しており、2 ヶ月かそのくらいでインタビューする予定です。最初に選ばれたのがあなたです。質問に答えてくれてありがとう。
snj: インタビューありがとう。そしてあなたがたのコミュニティへの尽力に感謝します。これはすごいことです。でもあまりあなたがたへお返しできないかもしれない。ちゃんと答えるためにはもう少し時間がほしい。説明が必要なら言って欲しい。
NetBSDfr: For the readers who don't know you, can you shortly introduce yourself ?
snj: My name is Soren Jacobsen and I am a NetBSD developer and release engineer. I've been part of releng since late 2005, and was the lead release engineer for the 5.0 release.
NetBSDfr: 読者のみなさんへ自己紹介をお願いします。
snj: Soren Jacobsen です。NetBSD 開発者でありリリースエンジニアをやっています。2005 年からリリー作業に携わり、5.0 release のリリース作業を担当しています。
NetBSDfr: Why did you choose to run NetBSD ? How long have you been using it ?
snj: My first experience with NetBSD was 1.5.3, which I guess was around the second half of 2002. Compared to a lot of people, I was a bit late to the party. At the time, I was frustrated with Linux in a number of ways, and NetBSD was a solid operating system with a philosophy that made sense to me. There wasn't any one particular thing about NetBSD that grabbed my attention. It was more that there was nothing that bothered me. It just seemed right.
NetBSDfr: どうして NetBSD の作業をしようと思ったのですか？ また、NetBSD を使い始めてどれくらいですか？
snj: 最初に NetBSD に触れたのは 1.5.3 のときでした。2002 年の半ば過ぎくらいだったと思います。すでにたくさんのひとが携わっていました( 訳: I was a bit late to the party は「このビッグウェーブに乗り遅れた」といった意味か? )。そのとき私は Linux にたくさんの不満を持っており、NetBSD の哲学にもとづいた堅牢なオペレーティングシステムに ぐっときたんです。NetBSD への関心を妨げるものはとくに何もありませんでした。何か困惑することもありませんでした。これはじつに正しいことに思えたんです。
NetBSDfr: Do you have an idea of the time you spend working on the NetBSD project daily, weekly, monthly ?
snj: Like most volunteers, the amount I'm able to spend on NetBSD depends on real life and my motivation level. A year ago, at most I was doing 8 hours a week. More recently, 8 hours a day wasn't uncommon. The week leading up to the release was especially hectic; I put in a couple 16 hour days there.
NetBSDfr: NetBSD へどれくらい時間をかけるか何か考えてる？毎日とか毎週とか毎月とか
snj: まさにボランティアみたいなものですから、NetBSD にどれくらい時間をかけるかは、実生活とモチベーションに依存します。去年はだいたい 1 週間に 8 時間費やしました。最近は 1 日 8 時間も使うことはあまり無いです。リリース担当の週は多忙で、16 時間以上費やします。
NetBSDfr: How did you become a NetBSD developer ?
snj: When I started using NetBSD full time as my primary operating system, I became heavily dependent on pkgsrc, our framework for third-party packages. There were a number of packages I wanted to see updated, and I started sending patches against pkgsrc and various small things in the base system. At the end of 2003, I was offered an account, and became a developer in January of 2004.
NetBSDfr: どうやって NetBSD 開発者になったの？
snj: 私の最重要オペレーティングシステムとして NetBSD をフルタイムで使うようになって、サードパーティパッケージ向けの我々のフレームワークが pkgsrc にかなり依存するようになりました。いくつかのパッケージをアップデートしたくて、pkgsrc の基本システムへのいくつかの変更点のパッチを pkgsrc へ投げ始めました。2003 年末にアカウントを貰い、2004 年 1 月に開発者になりました。
To anyone out there who is interested in helping the project: pkgsrc is a great way to get involved. There are so many packages out there, and only a finite number of developers to import and maintain them. Consider submitting PRs against pkgsrc and joining the pkgsrc-wip project. We can use all the help we can get in this area.
NetBSD プロジェクトの手助けに関心のあるすべての皆さんへ: pkgsrc は NetBSD プロジェクトに深く関わるには非常によい手段です。ものすごい数のパッケージが提出され、ごくわずかの開発者がインポートし、メンテナンスします。pkgsrc へ PR を提出することを検討し、pkgsrc-wip プロジェクトに参加してください。我々が手助けします。
NetBSDfr: How did you become member of NetBSD release engineering team ? Are the members of the releng team elected ? chosen among developers ? Does this require specific skills ?
NetBSDfr: どうやって NetBSD リリースエンジニアリングチームのメンバーになったのですか？ リリースエンジニアリングチームによる投票？ それとも開発者から選ばれる？ 何かスキルが要る？
snj: The release engineering team is rather informal. There is no election process, and no strictly defined leader of the group, although people do step up to fill this position. When we feel understaffed, we put out a call for volunteers, and usually a person or two will join.
snj: リリースエンジニアリングチームはくだけてます。投票するということは無いし、ちゃんとしたリーダーというのも居ませんし、みんなこの位置に居座ります。人手不足だと思ったら人員を募集し、いつも 1, 2 人参加してくれます。
Release engineering is not as glorious as a lot of other activities, so we don't normally have people begging to join releng. It's hard to say about specific skills. Like in most other areas, having sound judgment and a good sense of perspective is essential. These are the only strictly required skills. Plenty of others are useful, though: patience, caution, attention to detail, etc. Pretty basic stuff, for the most part. Of course, the more technical knowledge, the better, but this is not as big of a deal as it might seem. I'll explain below.
リリースエンジニアリングは他の活動ほど名誉ある作業ではないので、他のひとたちに参加を勧めることはありません。ある技術については他のプロジェクトよりも難しいところがあって、判断力があり、先見の明があることが必須です。これらが求められる技術です。他にも技術があるほうがいいんですが、まあ、辛抱強さ、用心深さ、細部への注意深さ、とかいろいろあるといいです。基本的にスタッフはこれらが得意です。もちろんもっと技術的な知識があるほうがいいですが、あまり重要ではありません。そこだけははっきりさせておきます。( 訳: ???? )
NetBSDfr: Can you explain us more in details how does NetBSD release engineering process work ?
snj: There are two basic tasks:
- Pulling up changes into branches.
- Releasing.
NetBSDfr: NetBSD リリースエンジニアリングの作業についてもう少し詳しく教えてください。
snj: 基本的な作業はこう:
- current での変更をブランチに反映
- リリース
The first one is rather straightforward, and it is something we do constantly. Developers request that certain changes be pulled up to a given branch. If we agree that the changes should be pulled up, we commit them to the branch. To help track the status of a branch, we maintain a record of every change made to a branch over its lifetime.
最初のは単純明快だし、いくつか定期的におこなっています。開発者は変更点をブランチへ反映することを要求します。変更点を反映すると決定したら、ブランチへコミットします。ブランチの状態を追跡しやすくするために、ブランチの生存期間中はその記録をメンテナンスします。
Putting together a release is a much more complicated task requiring coordination with a large number of people. The main task is to decide the point at which the remaining bugs can safely be ignored. There are lots of other tasks involved here, of course: managing the build cluster, pulling up changes, preparing information about the release, testing, making sure that important fixes find their way to the branch, begging people to work on certain things, paying very close attention to the mailing lists, etc.
release の場合はたくさんのひとと調整することが要求されるのでもっと複雑です。おもな作業は、残っているバグを除去して安全にすることです。もちろんたくさんの複雑な作業があります: ビルドクラスターを制御したり、変更点を反映したり、リリース告知を準備したり、テストしたり、ブランチに重要な fix がされているか確認したり、あることについては誰かに作業してもらったり、メーリングリストへ細心の注意を払ったり、いろいろ。
NetBSDfr: How does the quality assurance process works ? Who decides to include this or that patch to a branch ? This is also linked I think to the following question: how does the releng team decide how many betas, RCs versions are required before declaring a branch is stable ?
snj: No one person can have thorough technical knowledge in all areas of the source tree. Therefore, it's sometimes hard for a person (or small group) to be able to say for sure whether a particular change should be pulled up to the release branch. This is where one of the most important qualities of a release engineer comes into place: the ability to get sound advice from the right people. To some extent, we trust that developers submitting changes for pullup have carefully considered the implications of the change. But at the same time, we try to be very cautious, and being able to effectively consult with other developers is of vital importance.
NetBSDfr: 品質保証についてはどうやってますか？ ブランチにパッチを取り込むことを誰が決めるのですか？ これは次の質問にも関連しますが、ベータ版をいくつ作るのかどうやって決めるのですか？ ブランチが安定したと判断するまでにベータやRCがいくつ必要かを、どうやって決めるのですか?
snj: ソースツリー全体について技術的な知識を持っているひとは誰も居ません。したがって、担当者( または少人数のグループ )がリリースブランチの主な変更点を反映し、それが問題ないということを告知する作業は、ときに困難になります。正式な担当者から信頼できる助言を貰うことは、リリースエンジニアがうまくやってのけるためには最重要の品質のうちのひとつです。じつをいうと、開発者は変更された部分をちゃんと反映してくれてると信じている。しかし、それと同時に、よく注意し、他の開発者にも効果的に相談することがきわめて重要です。
We start the release process when we think the tree is in pretty good shape. At this point, the branch is known as, e.g., 5.0_BETA. At this point, more users start running the code, and we are constantly watching for feedback (positive and negative). Intrusive changes are avoided during all stages of the release process, but they are most acceptable at this point. The general rule is that the further along in the release process we are, the more restrictive we are about changes. Unfortunately, it is impossible to have many hard rules about this. If big nasty bug comes up, you're faced with a choice between ignoring the problem or taking a risk on an intrusive change. Sometimes we take the risk, sometimes we don't. This is another case where no one particular person can have all the answers. To avoid one person making a bad judgment call, members of releng discuss these issues with each other and with other developers.
我々はソースツリーがじゅうぶん良い段階になったらリリース作業を始めます。このときのブランチは、たとえば 5.0_BETA などです。そして、よりたくさんのユーザーがコードを使い始め、我々は定期的にフィードバック( 良い点も悪い点も )を監視します。リリース作業の全体では変更点は受け入られづらいのですが、リリース作業開始初期は変更点を受け入れやすいです。。一般的な規則は、リリース作業について規定していて、変更点についてもっと制限をしています。残念ながら、たくさんの厳密に規則を実施することは難しいです。もし、ものすごく鬱陶しいバグが報告されたとしましょう。あなたはそれを無視するか、もしくはなんとしてでも変更し、そのリスクをとるか、どちらかを選ぶことができます。我々はリスクをとることもあるし、何もしないときもあります。これは、とくに誰もその答えを持っていないときの選択肢です。誰かが悪い意見を言った場合、それを回避するためにリリースチームのメンバーが他の開発者たちと議論します。
A release candidate, by definition, occurs when it is felt that the tree is good enough to release. In practice, this rarely happens. There is almost always a good reason to do at least one more release candidate. In some respects, they're more psychological than anything else. I admit I rushed a couple release candidates out with full knowledge that 5.0 could not be released without further fixes. But when important last-minute changes are made, putting out a release candidate is a great way to get those changes tested. Take 5.0_RC3, for example. At the time, we were aware of a few show-stopping bugs, but there were significant WAPBL changes that needed wider testing, so we felt that RC3 was justified.
release candidate は定義によると、relase するのに妥当だと判断されたソースツリーのことです。習慣ではたまに発生します。たいていいつも 2 回は release candidate を作ります。いくつかの点では、他の何よりずっと心理的です( 訳: ???? )。5.0 がいくつか fix されてないことを承知のうえで release candidate を出したことがあります。重要な点については土壇場で変更し、release candidate を出し、とてもすぐれたテストを得ることができました。たとえば 5.0_RC3 。このときはいくつかの致命的なバグを抱えていましたが、WAPBL の重要な変更があったので幅広いテストが必要でした。だから、RC3 は正しかったと思っています。
In the end, deciding when to declare a release stable comes down to compromise. You have a hard list of requirements that the release must meet. Beyond that, you just have to get to a point where you feel that the remaining bugs are outweighed by all the positives in the new release. This is a hard thing to do, because when you've been tracking every problem raised for months, you tend to be focused on negatives and can easily forget about all the people who are having wonderful experiences. Eventually you have to let go and realize that you'll never have a bug-free release. When you get to that point, you tag the final release and hope that you haven't made a horrible mistake :)
最後に、stable をリリースするのに妥当な線を決定します。リリース必須項目を拝むことが出来ます。それから、新リリースにあるバグのうちいくつかの重要なバグを抱えたリリースを取得するだけです。毎月 何かしらの問題が発生していることがわかるので、これはしんどい作業です。悪い面に目がいくようになり、すべてのひとびとが *不思議な体験* をすることを簡単に忘れます。そして、バグなしのリリースが出来ることは無い、ということを悟るでしょう。そして、最後のリリースにタグをつけ、恐ろしいミスが無いことを祈りましょう :-)
NetBSDfr: As a conclusion, can you tell us how you imagine the future of NetBSD?
snj: We've made a massive jump with 5.0, and 6.0 should continue this trend. NetBSD has been ignored by many people for years, but this is changing. As for more specific predictions, I think we're going to see NetBSD usage increase greatly in the server and embedded worlds. I don't envision any radical shifts in direction, but this is not a problem. NetBSD has always been a great operating system; we just need to get out there and introduce more people to it.
NetBSDfr: 最後に、今後 NetBSD はどうなると思いますか？
snj: NetBSD 5.0 へ向けて大きく飛躍し、6.0 はその流れを汲んだものになるでしょう。NetBSD は何年も間 たくさんのひとびとから無視されてきましたが、これが変わります。もっと予言をすると、NetBSD はサーバーや組み込み機器でもっとたくさん使われるようになるでしょう。急激にそのようになっていくとは思っていないけど、それは問題ではありません。NetBSD はいつだって偉大なオペレーティングシステムです。もっとたくさんのひとびとに使ってもらうことだけが望みです。
Many thanks to Guillaume for his hard work on preparing, conducting and translating this interview and rendez-vous in a few weeks for the next one. I;n the meantime, any names of developers to interview, or questions you'd like to ask, are more than welcome.
Guillaume には作業の合間をぬってくれたことに感謝する。このインタビューは翻訳されて、数週間後に rendez-vous に置かれる。その間にインタビューしてもらいたい開発者の名前や、質問を送ってほしい。
_ Pulling up〜 [current での変更をブランチに反映 (NetBSD 用語で pull up)]
_ how many betas, RCs〜 [ブランチが安定したと判断するまでにベータやRCがいくつ必要かを、どうやって決めるのですか?……安定したからとリリース..]
_ みわ [おお。ありがとうございます。最後のツッコミはspam扱いされてしまっていました。すいません...]
_ テキトーなのでそのまま使われると恥ずかしい [( 訳: they are はどれを刺してる? )they = Intrusive changes リリースプロセス..]
_ みわ [いえいえ。私が書いたほうもほとんど直訳だし誤訳だし。まあでも自分の言葉で置き換えて書くことにします。]
2012-07-13 :-(
2015-07-13 :-(
_ 「進捗報告」といった名目の定例会議が増えていく現象
いやまあ自分でも配下のメンバー(5人)と1ヶ月おきに「最近どうよ」といった場を設けているのでブーメランになりますが。
2017-07-13 :-(
_ HIGH OUTPUT MANAGEMENT を読みました
マネジャーのアウトプット＝自分の組織のアウトプット ＋ 自分の影響力が及ぶ隣接諸組織のアウトプット(p.5)
マネジャー(日本語で部長)向けの本らしいですが、部下が N 人居るひとならば参考になるんじゃないでしょうか。本の前提が私の今の業務とはかけ離れている(プロジェクトマネジメントしてない)ので、半分くらいはあまり理解できませんでした。
採用面接時の質問が面白いかったので。むしろ常に自分に問い続けなければならぬ？
- 自分の弱点は何か。それをどう除去しようと努力しているか。
- 我が社があなたをなぜ採用すべきかについて、こちらを説得してみてほしい。
- 現在の立場で直面している問題はどんなものか。その問題をどのように解決しようとしているか。問題が起こるのを防ぐんはどうすればよかったと思うか。
- なぜこの新しい仕事をこなせるといえるのか。
- あなたの一番重要な達成事項は何か。なぜそれがあなたにとって重要か。
- 何があなたにとって一番大きな失敗であったか。それから何を学んだか。
(p.295)
p.296 にこの質問の意図が書いてあるんだけど、ようするに
- 自分の能力と実績は何か
- 自分の理想と現実との差異は何か
- 問題が解決できるか。また再発防止できるか
などといったことを問われています。
4822255018
2018-07-13 :-|
2020-07-13 :-(
_ 父が亡くなった
2355 病院から電話。「お父様の心臓が急激に弱った。来てくれ。お母様に連絡しているが繋がらない」
0005 幡ヶ谷
途中母に電話するが出ず
兄に電話するが出ず。留守録だけ入れる。
0020 兄から電話。状況を説明。
0025 母から電話。状況を説明。
0117 病室。眠っているように見えた。
呼吸が浅いというか。呼吸しているのだろうか。
0120 母到着
0125 兄到着。兄の長兄に車で送ってきてもらったとのこと。
0130 看護師が見つかったので話を聞いた。すでに脈は止まっているという。
体が冷たい。
脈は止まっていた。
心臓も止まっていた。
0142 看護師が確認。右目を開く。瞳孔は開かない。左目を開く。瞳孔は開かない。
看護師から永眠を宣告。
オレ、母、兄、兄の長兄で看取り。
看護師いわく「徐々に脈が弱っていった。なので電話をした。その後 少しずつ脈がでなくなり、止まった。眠ったままだった」
眠っているようだった。
0240 霊安室
0415 帰宅
1000 起床
1130 病院
1230 死亡診断書を受け取る。
1440 葬儀の打ち合わせ。
1630 帰宅。
2022-07-13 :-(
_ 艦これ 2022 梅雨イベント 「激闘！R方面作戦」 終了
お疲れ様でした。
E5-4 まで順調でしたが最後は力及ばず乙に落としてクリアしました。むしろあのまま甲でクリアできても勝って兜の緒を締められず「勝てたからよし」となってしまい反省できず次へ改善できなかったかもしれません。
アンケートのお願い 2022春梅雨 ｜ ぜかましねっと艦これ！ にも書いたのと同じものですが。
感想全般
勉強になりました。E5-4 は甲で着手したけど結局 乙に落としました。
本イベントはよく「竹の輝き」と比較されますが、私は「竹の輝き」を甲クリアしたのは運が良かったから、ということが分かりました。「竹の輝き」以降も甲クリアできていたので天狗になっていましたね。E5-4 の編成を艦これが強い人に編成を相談しても、それでも甲クリアできなかったので、自分の力不足を痛感しました。めちゃめちゃ悔しいです。
今イベの反省点(あれば)
たくさんあります。
- 大口径主砲の改修
- 運改修
- 水戦改修
- 編成力 (ようするに艦これの基礎知識です)
- 戦闘を動画記録して次の戦闘のために改善点を見つけ出す (PDCAを回そう!)
E5-4 で敵第一艦隊を壊滅できなかったんですが、こちらの第一艦隊があまり弾着してなかったり連撃してなかった気がします。「気がします」ではなく動画記録して見返せるようにしないといけない。
第二艦隊の運をほぼ改修しておらずそれをカバーするための編成をしないといけないんだけど、それをやるだけの知識が無かった。第二艦隊に「夜戦セット」を持ち込む場合と、持ち込まない場合を数値として比較して判断できるようにする。
2023-07-13 :-(
2024-07-13 :-)
_ 日誌
部屋掃除。
買い物。
おひる。寿司を買ってきたので寿司。
だらだら
雨が降るらしいが結局降らなかった。
飯。ぶりカマの塩焼き。
Vulcano さんがリッジレーサー6 を始めたので見ていた。
2025-07-13 :-)
_ 横須賀軍港めぐりでズムウォルト級「マイケル・モンスーア」を見てきた
思わず二度見!? な米ステルス軍艦「マイケル・モンスーア」東京湾に突如来た！ 世界に3隻しかない異様なデザイン | 乗りものニュース
設計に 3 兆円、建造に 5000 億円かかったとかなんとか。
名前の由来となった軍人 マイケル・モンスーア - Wikipedia は手榴弾に覆いかぶさり被害を 最小限に 食い止め、犠牲となった、という軍港めぐり案内人によるエピソードがあった。 パイナップルアーミーの「手榴弾の爆発は人間の体を貫通しない。それはナチスの人体実験で証明されている。」 みたいな話題を思い出しがら聞いていた。
試験管「あすか」の後部に超電磁砲 (レールガン) が積んである。
2「くまの」
1「もがみ」
横須賀海軍カレー本舗 でカレーを食べて帰る。 メニューが 2, 3 品減ったのう。
_ さいき [シャルロットで思い浮かぶの侍スピリッツぐらいだな〜某ＣＤドラマだと声を当ててる声優さんの試練が(^_^)。あっナコル..]
_ のぶ [シャルロットと言えば「らんま1/2」(笑)]