タグ

ブックマーク / nakagami.blog.ss-blog.jp (11)

  • 谷津干潟自然観察センター: ある nakagami の日記

    これは、俺の子連れおすすめスポット Advent Calendar 2014 の15日目の記事です http://www.adventar.org/calendars/681 今日のお勧めは、「谷津干潟自然観察センター」http://www.yatsuhigata.jp/ です。 (徐々にネタ切れなので、だんだん東京から遠くなります。だ、誰か・・・) 観察センターに入るには、高校生以上 370円、中学生以下は無料。 ちなみに、センター内にちっちゃな喫茶軽のできる喫茶店(鳥を見ながら事できる)がありますが、谷津干潟周辺には、それ以外何もありません。 観察センターに入らなくても干潟周辺の道から観察し放題なのですが、観察センター内から観察すると実際見やすいです。 (入場料は自然保護のために使われるようです) 電車だと、駅から少し遠いので小さいお子さんといくのはつらいかもしれません。 http

    谷津干潟自然観察センター: ある nakagami の日記
  • 江戸東京博物館: ある nakagami の日記

    これは、俺の子連れおすすめスポット Advent Calendar 2014 の14日目の記事です http://www.adventar.org/calendars/681 今日のお勧めは「江戸東京博物館」です http://www.edo-tokyo-museum.or.jp/ 施設的には典型的な「ハコモノ」です。 これで、江戸や東京の近代の生活がわかる、、、といえばわかるのですが学術的な意味とか、かけたコストに対する効果とか考えたら、こんなの作るのいいのかなーと言う感じです。 バブルの産物だと思います。 施設と来場者数(体感)からして、ひょっとしたら、赤字のため廃止ということもあるのではないでしょうか。行けるときに行っておきましょう。 見どころは、博物館自体の、外観、内観の変わった建物であると言う点と、その建物の中の立体的な間取りの中に物のサイズの建物や橋が展示されているダイナミッ

    江戸東京博物館: ある nakagami の日記
  • 地下鉄博物館: ある nakagami の日記

    これは、俺の子連れおすすめスポット Advent Calendar 2014 の9日目の記事です http://www.adventar.org/calendars/681 私がお勧めするのは、地下鉄博物館です http://www.chikahaku.jp - 安い →大人:210円、こども:100円 (※満4歳以上中学生まで) http://www.chikahaku.jp/contents/about/ - シミュレーターあり http://www.chikahaku.jp/contents/facilities/enjoy.html#simu - パノラマあり ちょっと手狭ですが、いろいろあって、大人も子供もあきません 企画(イベント)も時々やっているようですのですが、そういうのなくてもいくらでもいられます。 都内からもアクセスしやすいですし(そして駅を出てすぐの高架下)、交通博物

    地下鉄博物館: ある nakagami の日記
  • Pillow の Python3 porting に関する思い出をメモっておく: ある nakagami の日記

    python のイメージライブラリの ML [Image-SIG] に Pillow の python3 port を master ブランチにマージしたというお知らせが来た。 http://mail.python.org/pipermail/image-sig/2013-January/007143.html http://blog.aclark.net/2013/01/10/pillow-python-3/ そこで、ここまでのことを記録しておく PyCon JP 2012 の LT で、「Python3 のポーティングの勧め」みたいな話をした。 ポイントとしては「2.7 と 3.3 なら同じソースで動くようにするのは割と楽、そして今は python3 への移植でヒーローになるチャンス」ということ。 そのときに Pillow を python3 で動くように頑張ってますという話をした。ん

    Pillow の Python3 porting に関する思い出をメモっておく: ある nakagami の日記
  • デザインパターンとか、メソッド/関数の長さとか: ある nakagami の日記

    naka-06_18
    naka-06_18 2012/11/05
    はい
  • わたしの美しい設計が壊れていく: ある nakagami の日記

    僕が、20代の若手プログラマーだった頃、プライドの高い女性課長の部下だった。 美しくないマリッサ・メイヤーみたいな人。 どういう案件だったのか、まったく覚えてないし、多分課長は僕とは別の仕事をしてたんだと思うけど、ある時 「わたしの美しい設計がこわれていく」 って、不満そうに言ってるのを聞いた。 その時、僕が(あなたの美しい設計は知らんがな)と思ったことを凄く覚えている。 おそらく、その頃には課長の完璧主義に辟易していたんだろう。 あたりまえのことだが、そんな人のプライドほどには、ものごとはうまくいってなかった。 往々にして、完璧主義というか、よりよいプログラミングを目指す人というのは、最初に出た仕様で、重複を排除してキチキチのプログラムを書く。そして、お客さんがちょっとした追加の仕様を出すと不満そうにするし、「それは、仕様変更です」と一歩も引かない。そして、その変更を受け入れようとする

    わたしの美しい設計が壊れていく: ある nakagami の日記
    naka-06_18
    naka-06_18 2012/10/18
    「最初に出た仕様で、重複を排除してキチキチのプログラムを書く」。。。
  • 一番不幸だった仕事の話: ある nakagami の日記

    以前にも、同じ案件の話を書いた気もするが、もう10年以上も前のことなので、(かつ、関係者がこの日記を見てることはないと思うので)もう少し詳しく書く。 会社を辞めてすぐのときに、元の会社の同僚が仕事を紹介してくれた。非常に単価の安い仕事だったが、どうせしばらく無職の予定だったのでうけることにした。 その会社は、商社と大手IT企業の合弁で、話があったのは、生保とか証券の仕事をする部署だった。部署があるくらいなので、その会社の(少なくとも担当の)人達は業界のプロで初めての業種の業務アプリのバックエンドを書く僕は、言われた通りにコーディングすればいいと思っていた。 僕の最大の敗因は、その人達がまったくプログラムを書いたことがなくてマネージメントだけをする、所謂 SIer だということ、そして世の中にそういう人がいることを僕が知らなかった、ということだ。(その時の前職の会社は、プログラマーが歳をとる

    一番不幸だった仕事の話: ある nakagami の日記
  • 意識の高いエンジニア、低いエンジニア: ある nakagami の日記

    こないだのちょっとした酒席でのこと。 最近入社する人は、優秀で意識高いんだけど 「いや、これをやるにはこういう設計ではダメだ・・・」 とかなんとか言って、なかなかコーディングが進まない、との話。 詳細な話は聞かなかったが、僕のなかではやれテストを書かないとダメだとかそういうのなんだろうな、と理解した。 それで、「そういう人に限って、不具合多いんですよねー」とのこと。でも、そういう意識高い人に「なんでもいいからちゃっちゃとコーディングしてよ」とは言いづらいそうで、なかなかやりづらい職場である。 よくわからないけど、意識高くて不具合多いのは、既存のコードを読んだり、コードを書いたりすることに集中できないから?確かに、全てにテストが必要とかカバレッジが 100% とか言って人は、100% になることばっかりに気を取られて、来どういうコードを書けばいいのか?について集中できてない気がする。 以前

    意識の高いエンジニア、低いエンジニア: ある nakagami の日記
  • オウムは死なず(その2): ある nakagami の日記

    naka-06_18
    naka-06_18 2012/06/21
    菊地さんも、平田さん(をかくまっていた女性)も、貧しいながらも身分を隠して仕事していけるぐらいの緩さが、いまの日本にもあるのかと思うと、ちょっとほっとする。
  • デスマは死なず: ある nakagami の日記

    最近、デスマのことを考えている。 どんなにツールが高度化しても、開発手法が研究、一般化されても、世の中から全てのデスマを無くすのは無理らしい。 僕が職業としてプログラミングを始めた頃は、今普通に使われているものでは vi と emacs くらいしかなくて、 「vi がスクリーンエディタ?意味わからん。秀丸やMIFES のが便利ですよね」 という感じだった。 Eclipse/Git/Redmine といったツールや、プログラミング言語の多様化で道具は便利になった。 なにせ、僕が最初に仕事で書いたプログラムは ANSI C だったし、既存のプログラムは K&R の古い形式のものもあった。あの頃に比べたら、Java だって随分と効率的だ。 テスト駆動や、XP、スクラムという開発手法も認知されてきた。 開発効率という点では、格段の進歩があったはずだ。 でも、道具がどんなに便利になってもデスマはなく

    デスマは死なず: ある nakagami の日記
    naka-06_18
    naka-06_18 2012/04/02
    「・できるだけ近寄らない・間違って遭遇してしまったら、最大限可能な妥協点を全力で探る」
  • BPStudy #55: ある nakagami の日記

    naka-06_18
    naka-06_18 2012/04/02
    「一括請け負いでなく、毎月決まった人月単価をいただき、お客さんの最も価値あるところから開発していく」、ここをめざしたい
  • 1