Twitter に入って 1 ヶ月が経ちました。現在研修やらでサンフランシスコに来ています。小さいながらも自分が書いたコードが Twitter 上で動いているのを見るのはとても不思議な感じ。 Twitter の Username は @higepon なのでぜひフォローしてね。
![Twitter に入社しました - higepon blog](https://cdn-ak-scissors.b.st-hatena.com/image/square/430421c19792df56203f8e04b23a72eb897d102a/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fh%2Fhigepon%2F20120206%2F20120206052741.jpg)
多摩川サイクリングロードを通って自転車で多摩川の上流の方に行ってきました。 走行距離は往復でだいたい70km〜80km。(迷子になった分も含む) まずはスペックから。 基本的にのび太 運動嫌い 小中学生のころはずっとクラスで走るのが遅いNo.2だった(No.1は体型がとてもふくよかな人) 体育の成績で真ん中よりも上は一度もとったことがない 個人責任の重い球技とか大嫌い。狙われるのでw。(バレーボールとか野球とか) 昨年 自転車で山手線1周した 限界を越えて大きくなるぜとかではなくて、まあやってみよう的な軽いノリです。 8:40に出て19:00に帰宅。 楽しかったです。 以下レポート ふと。昨日の夜思いついたので多摩川の上流に行ってきました。 荒川とも迷ったのですが家から近いという理由で多摩川へ。 天気は微妙に曇りで午後から雨が降るかもという予報。 深く考えないことにした。 スタート 旧山手
勉強方法を勉強して分かった僕に足りなかった3つのこと。 それは 時間割 マインドマップ 復習 の3つ。 1.時間割 勉強をコンスタントに長期的に続けるならば時間割は大変有用。 時間割を作り実践してみて分かったが「次に何をやるべきか」に迷う時間は振り返ればとてももったいなかった。 時間割を作ればほぼ迷わない。迷うとすれば超イレギュラーな事が起きたときだけ。 時間も節約できるしペースもつかめる。 また時間割を家族と共有していれば「20:00になったから勉強してくる」と言うだけで理解してもらえるようになる。 ただし時間割は時が経ち「見慣れて目に入らなくなる」「実態に合わなくなる」事があるので注意が必要。 僕は毎週手書きで描き直している。 時間割の有用性についてはレバレッジ勉強法が詳しい。 2.マインドマップ 正直 マインドマップ を馬鹿にしていた。何で皆あのようなものに踊らされているのかと。それ
ライティングソリッドコード―バグのないプログラミングを目指して。 この本は同僚のkaorun さんからお借りして読んだ。 Code Completeの興奮が冷めぬうちに某氏に本書も読むと良いよとすすめめられた。 さすがに某氏のすすめだけあって間違いはない。10年以上前の古い本だが多くの教訓が得られる。 この本では具体的なテクニックよりも、筆者の大切な主張 3つ学ぶべき。主張というかプログラマとしての態度かな。 どうしたらこのバグを自動的に検出することが出来ただろうか? どうしたらこのバグを防ぐことが出来ただろうか? この考え方はバグのないコードを書くために役立つだろうか?それとも妨げになるだろうか? これら3つを徹底的に意識し実践してコードの品質をあげるという話である。これらの教訓がいまいちピンと来ないならば一読の価値がある。 ここまでやるからこそ、結果的に手数も時間も節約できる。マイクロ
ダシにして申し訳ないが、典型的なLisperからみたかつてのid:higeponや、現在のid:amachangの「知力」は高いとはとても言えない。例えば遅延評価のことは、SICPを読めばちゃんと書いてある。そしてこれはまともなComputer Scienceがある大学なら、一番最初に使う教科書の一つなのだ。「まとも」に教育を受けた人なら、「遅延評価童貞が許されるのは、小学生までだよねー」とか言うかもしれない。 しかし、彼らの知的生産力は10倍どころでなく高い。その過程を逐次晒しているからだ。その過程で「知力」豊かな人々の助言も得られるし、彼らの「失敗」を通して彼ら自身だけではなく、彼らのblogの読者もそこから学ぶことができる。もし読者の知的生産力の向上も彼らの知的生産力の方にカウントしたら、知的生産力の差は十倍どころか数千倍、いや数万倍のオーダーだろう。これを繰り返しているうちに、今度
そういえば昨日の飲み会で誰かが言っていて同意したのがプログラマの机の話。 机の上に紙とペンをどれだけ広げられるかで勝負が決まる。 せまい机に押し込まれて隣の人と触れ合うほど、近かったりするともうだめ。 デュアルディスプレイで得られる効率はコーディングの効率なのだけど、机に広げたノートで得られるのは考えをまとめる効率。 脳の中に展開できない何かをノートに展開ですよ。 紙とペンとか言うと、うげー古いぜとか思うかもしれないですが僕より若い優秀なエンジニアは良く紙に何か描いているなあ。(上の世代は言うまでもない)。 今使っているノートとペンを教えてくれたのは僕よりずっと若い id:kambara氏 だし。
まずはこの日記を読んで欲しいid:hyoshiok:20040909 エンジニアとしてのキャリアを考えさせられる。 もちろん自分と比較するのは大変恐れ多いのだが、今の自分のだめっぷりは改善しなければいけないと思う。 私はプライベートでは2002/11月ごろからMona(http://sourceforge.jp/projects/mona/)というオープンソースプロジェクトでカーネルを書いている。 仕事ではシステムエンジニア(プログラマ寄り)だ。もちろん仕事の方がかけられる時間はMonaよりもはるかに長い。 でも仕事は技術的にも内容的にも、まぁ自分でなくてもできるような内容だし、カーネルに関わる知識も一切使わない。 職場の人は私がカーネルを書いていることなど知らないし仕事内容は本当に平凡だ。 Monaと仕事にギャップを感じ続ける毎日だ。これで良いのかと。 例えばMonaをはじめてから、自分
Linux といえば、オープンソースプロジェクトの旗手であり、最も成功したプロジェクトと言っても過言ではない。 今まで Windows や Solaris の領域であった部分に踏み込み、Microsoft や Sun に脅威を与える存在になっているのは間違いないだろう。 またPC産業のコモディティ化が急速に進んだの理由の1つとして、Linuxの普及によるソフトウェア調達コストの低下が挙げられると思う。 そんな猫も杓子も Linux の万歳の状況が続いているので Linux = 新しい・オープンソースだから優れている・速い・クール Windows = 古い・駄目なOS というイメージを持っていないだろうか? だがそれは必ずしも正しい認識とは限らない。 例えばLinuxは、フリーのUNIXを作ろうという動機で開発が開始されており、BSDやSYSTEM Vといった比較的、古い歴史のあるOSをお手
Installation:Ubuntu - IEs4Linuxの手順を参考にすると簡単にIE6をインストールすることができます。 あっさり動いてびっくりしました。これからCSSやJavaScriptの確認に重宝しそうです。 速度も十分実用です。 日本語が入力できないってのがクリアされれば完璧ですね。 追記 ひげぽん OSとか作っちゃうかMona- - Ubuntu Edgy Wine Internet ExplorerでSCIMを利用して日本語入力 追記 Wine 0.9.3xではうごかないようです。 0.9.22に落とすとよいでしょう sewashi% aptitude show wine -v |grep Version Version: 0.9.34~winehq0~ubuntu~6.10-1 # => current Version: 0.9.22-0ubuntu3 # => ol
本日*1をもちましてはてなを退職することになりました。 お世話になったみなさん本当にありがとうございました。 僕は、はてなRSSや Rimo などまとまった大きなサービスから、ダイアリーのメール投稿機能など小さな機能まで、はてなのいろいろな部分に関わらせていただきました。 その過程で 実際にサービスを使ってくれるユーザーのみなさん はてなアイデアを通じてアイデア投稿や不具合報告をしてくれるみなさん 告知日記のブックマークコメントで喜んでくれるみなさん 日記で感想や要望を書いてくれるみなさん など、本当に多くのユーザーの方といろいろな形でコミュニケーションをとらせていただきました。 そのみなさんとのやりとりが、より良いサービスを作りたいというモチベーションになったり、日々の僕自身の楽しみやはげみになったりと、たくさんの力をいただきました。(本当はユーザー id を挙げてお礼が言いたかったので
オフラインでコードを書いていて何気なく man fputc としたら、man がなかった。 sudo apt-get install manpages-ja manpages-ja-dev で OK。 そして引数の順序を間違えて覚えていたことが発覚。
最近一部で盛り上がっている「末尾再帰」について自分の理解を確認するのも兼ねて書いてみます。 (そもそも自分がふったのがきっかけっぽいので)。 上級者の方は間違い等に厳しくつっこんでもらえると助かります:-) 背景 自分が末尾再帰を知ったのは多分Schemeの勉強を始めた頃だったと思います。 例えばSICPという本では20ページあたりにこっそりと出てきます。 そのころの理解はかなり浅いもので「ふーん。」程度でした。 さて後日Schemeの処理系を実装することになりR5RSというSchemeの仕様書を読んだところ Scheme の実装は真正に末尾再帰的(properly tail-recursive) であることが要求されている。これは,たとえ繰返し計算が 構文的に再帰的手続きで記述されているときでも,定数空間 でその繰返し計算を実行することを可能にする とあり末尾再帰のことを詳しく知る必要性
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く