子供乗せ自転車
今回は育児ネタです。
子供も首が座ってしばらく経ったので自転車に乗せたいなと思うようになりました。これまでは抱っこ紐、おんぶ紐、ベビーカーを使い分けてきましたが、いずれも親は徒歩なので疲れやすく、移動範囲はかなり制限されてしまいます。
そこで子供乗せ自転車を検索しましたがどれも似たり寄ったりで、あまり欲しいと思えるものが見つかりませんでした。女性向けのデザインばかりだったり、電動アシストが付いているものが多くそれらは価格が高過ぎるんです。選択のポイントとしては以下のような感じです。
- 安全設計（事故や転倒から子供を守れるか。具体的には子供の乗るシートの形状、低重心、3輪以上。）
- 整備がしっかりしてあるか
- 電動アシストはあった方がいいけれどなくてもOK
通販での購入は安いことが多いですが、 整備が不十分だったり配達中に不具合が起こることもあるので、届いた後は自転車屋さんでしっかり点検してもらうべきです。
ちなみに、子供乗せ自転車でなくても子供と一緒に自転車に乗ることは可能です。その条件は
- 子供はヘルメット着用
- おんぶ紐などでしっかり背負うこと（抱っこはダメ）
- 子供は4歳未満
- 運転する人は16歳以上
などです。詳しくは道路交通法で決められていて、変更もちょくちょくあるので最新のものを各自ご確認下さい。
あと、大人もヘルメットをすべきだと思います。いざという時には自分の安全よりも子供の安全を優先した行動を取らなければいけないので、そうするためにもヘルメットはしていた方がいいです。カッコ悪いとかメンドクサイなんて気持ちは、安全に比べればどうでもいいほど小さなことなので是非。
普段乗っているクロスバイクに子供と一緒に乗ってみました。普段以上に周囲に気を付けて安全運転をしています。おんぶしたら子供から景色は見られないかなと思っていたのですが、斜め前方や横の景色は見られるようで楽しんでいる様子です。安全に神経は使いますが、徒歩よりずっと楽でこちらとしても楽しいです。
日付表現のありかたについて
先日ネット上で「△△が24年度末までに○○を目指す」のような記事を見ました。
最初タイトルだけを見て、平成24年のことを指しているのかと思ったのですが、2014年現在は平成でいうと26年だ、と少し考えてから気付きました。どうやら24年度というのは2024年を指しているようです。この件をきっかけに、日付表現はどうあれば理解しやすいのか（人間にもコンピュータにも）を考えてみました。
西暦を省略しない
省略せずに全桁表現した方が間違いが少ないですよね。（24年→2024年）
西暦と和暦の統一
別にどちらでもいいのですが、複数の表現が混在していると混乱の元です。まあ海外とのやり取りを考えれば西暦への統一が現実的でしょうか。
あるいは西暦の場合はアラビア数字を、和暦の場合は漢数字を必ず使うなどの差別化を図れば混乱が少なく共存していけるかもしれません。
月日はそれぞれ2桁に
月と日は「01月」「02日」のように2桁表現に統一したらいいのではないかと思っています。これについては反対意見もかなりあるでしょうし、自分自身にもまだ迷いがあります。メリットとしては複数の日付が縦に並んだ時に長さが統一され綺麗に見えるとか、文章中の日付を変更してもレイアウトに変化が起きない（起こりにくい）というあたりでしょうか。あと、日付でソートするプログラムが少し書きやすくなるというのもありそうです。（ライブラリを使わず自前で実装する前提なのが既に間違っているかも）
年度って…？
2024年度末というのは、おそらく2025年03月のことなのでしょう。日本では入学、入社が04月からというのが標準のようですが、会計年度に関しては04月スタートでないケースはそこそこあるようです。ということで年度末という表現には不正確さが残るので「～年○○月」と表現した方がよいと思います。
後書き
「03月」「04月」と表現してみたらやや不自然さを感じるのでこれはやっぱり違うかも…うーん。
システム開発に必要な設計とは何か
今まで参画したシステム開発のプロジェクトでは、作成する設計書の種類や書式はほとんどが既に決まっていて、それをベースに設計内容を考えていけばよいといった状況でした。最近、ゼロに近い状態から始まるプロジェクトにリーダー的な立場で関わることになり、作成する設計書の種類、書式を決めていく必要が出てきました。
設計書作りについてはこれまで「面倒な作業だな」くらいにしか感じていませんでしたが、今回改めて設計とは、設計書とは、を考えることになりました。その気になれば設計書を全く作らずにシステムを開発することも不可能ではないでしょうし、逆に、考え付く全ての情報を設計書として残すという選択肢もあり得ます。実際には投入できる人員数と時間、設計書作成で得られる効率性や保守性の向上度合、顧客との契約内容、プロジェクトの特性などの要素からバランスを取りつつどのような設計書を作成するのかを決定していくことになるのでしょう。改めて考えると結構奥が深いと感じます。
まだ答えは見つかりませんが、なんとか考えていきたいです。
Google App EngineのDatastore Adminページが正常に表示されなくなった
Google App Engine管理用ページの一つ、Datastore Adminですが、このページの本来Datastore情報が表示されるべき部分が真っ白になる現象が発生しました。
とりあえずの解決策としては、この時のページのHTMLソースを表示し、iFrameタグの中のURLに直接アクセスすることで目的の情報を表示できました。根本的な原因、解決策は不明ですが、何もできない状態では困ってしまうため同様の問題が発生した時には試してみる価値があるかもしれません。
ブログを書かなくなる理由
この記事は、怠惰 Advent Calendar 2013 25日目、最終日の記事です。
先日、ブログを書くことについてという記事を書きました。今回は、自分がブログを書かなくなるパターンについて書いてみます。
ブログを書かなくなる理由
理由1：自分が書かなくても既に書いている人がいる（だろう）から
世の中には沢山の人が情報発信していて、自分よりも詳しい人、説明の上手い人なんかはいくらでもいます。そう考えると、自分なんかが改めて書くことなんかほとんど無いのでは思い、書くことを止めてしまいます。
理由2：見る人がいないから
当たり前のことですが、宣伝でもしない限り作ったばかりのブログを見に来てくれる人なんてそうそういません。しかし、がんばって記事を一つ書いてみてアクセスがほとんど無いことを確認すると、続けて頑張ってみようという気持ちはかなり薄れてしまいます。
それでも書いてみようかな？
詳しい人や説明の上手い人からの情報発信は確かに頼りになりますが、どこか一つくらいは自分にしか書けないようなところがあるかもしれません。他の誰も見てくれなくても、自分自身は読者になることができます。なので気が向いた時くらいは書いてみようと思っています。
プログラマの三大美徳
この記事は、怠惰 Advent Calendar 2013 23日目の記事です。
プログラマには必須の三大美徳というものがあると言われているようです。小飼弾氏の「404 Title Not Found」によると*1 、その3つとは「怠慢」「短期」「傲慢」で、特に「怠慢」はこの記事で参加しているAdvent Calendarのテーマである「怠惰」と似ていますので、定義を引用してみます。
怠慢
全体の労力を減らすために手間を惜しまない気質。この気質の持ち主は、役立つプログラムを書いてみんなの苦労を減らしたり、同じ質問に何度も答えなくてもいいように文書を書いたりする。よって、プログラマーの第一の美徳である。
「怠慢」と「怠惰」がどう違うのかわかりませんが、Advent Calendarを作る際に、ここで書かれている怠慢とほぼ同じ意図で怠惰という言葉を使いました。怠慢の方が適切だったのかもしれません。
せっかくなので、残り2つも引用させていただきます。
短気
コンピューターが怠慢な時に感じる怒り。この怒りの持ち主は、今ある問題に対応するプログラムにとどまらず、今後起こりうる問題を想定したプログラムを書く。少なくともそうしようとする。よって、プログラマーの第二の美徳である。
傲慢
神罰が下るほどの過剰な自尊心。または人様に対して恥ずかしくないプログラムを書き、また保守しようとする気質。よって、プログラマーの第三の美徳である。
3つの美徳が、 自分自信に当てはまるかどうかを考えてみます。「怠慢」は、全体の労力を減らすために手間は惜しまずというのは当てはまると思うので○。「短期」は、今後起こりうる問題を想定したプログラムを書くというのは、程度の問題はあれ一応意識しているつもりなので○。「傲慢」は、人様に対して恥ずかしくないプログラムを書き保守しようとしているつもりですが、結果として実行できているかは自信はありません。また、業務以外のプライベートで書くプログラムはあまり人に見せたくないなぁという感じなので、「傲慢」は△もしくは×でしょうか。
プログラマとしての力を付けていくには「傲慢」さを意識するのが近道なのかもしれません。あなたはどうでしたか？
ブログを書くことについて
この記事は、怠惰 Advent Calendar 2013の21日目の記事です。
決して勤勉とはいえない自分にとって、ブログを続けて書くのは大変です。もう10年以上前から何度もホームページやブログを作っては更新を続けられず放置、ということを繰り返してきました。三日坊主という言葉がありますが、三日すら続かないことがほとんどでアカウント登録だけで終わってしまうことだってあります。生み出した本人もがその存在を忘れ、ネット上の廃墟のようになっているであろうブログ達のことを思うと、罪悪感を感じます。
では何故それでも書こうと思うのか。書いたら楽ができるかもしれないと考えるからです。自分の困っていることを書いたら何らかの形で答えやヒントをもらえるかもしれません。解決できたことを書くことで同じように困った人を助けると同時により良い方法を教えてもらえる可能性もあります。自分で調べたことをまとめておけばたぶん自分にとっても役に立つでしょう。本当に効果があるかどうか、自分にはまだ分かりませんがとりあえず試してみようと思っています。
