駄文 - rb -> sh -> vi - IT戦記
いやあ。マジでいい道選んだね http://d.hatena.ne.jp/dropdb/20071106#p6 vi でも vim でも emacs でもいいんだけど、途中で挫折しないで、頑張ってほしい。 最初は信じられないかもしれないけど、それを使いこなせるようになるまでの時間は、それを使って節約できる時間と比べると圧倒的に短い。 つまり、早く使いこなせるようになればなるほど、プログラミング学習の本質的な部分に触れられる時間が増えるということ マジで、いいモデルケースになることを期待しています。 余談 僕が秀丸から vim に以降したのも 2005 年だったなあ。2005 年は転機だったのか。
2006-12-12
windows XP*1 colinux putty screen vim zsh *1:mac欲しい。近々買う railsを使った何か。 高田馬場 とりあえず、さらしてみる。 いろんなところを参考にしたので、どこが元かは忘れた。 set nocompatible syntax on set bs=2 highlight LineNr ctermfg=darkyellow highlight NonText ctermfg=darkgrey highlight Folded ctermfg=blue highlight SpecialKey cterm=underline ctermfg=darkgrey "highlight SpecialKey ctermfg=grey " highlight ZenkakuSpace cterm=underline ctermfg=lightblue
ＫＯＮＡＭＩ、スクウェア・エニックス、セガ、バンダイナムコの大手4社が“技術部”のあり方を討議
【10月10日】 カプコンブースイベントレポート 今度の「モンハン」はオフラインでも2人で遊べる!! SCEJブースレポート PS3「リトルビッグプラネット」、「Flower」ほかDL専用PS3タイトルその1 (開発者インタビュー付き) マイクロソフトブースレポート サードパーティータイトルを中心に24タイトルをプレイアブル出展 マイクロソフト、東京ゲームショウ2008 Xbox 360スクリーンショット集 セガブース、イベントレポートその1 期待の3プロジェクトの記者発表会を開催! セガブース、イベントレポートその2 2日目もイベント盛りだくさん。「PSU」の追加アップデートも発表! ＫＯＮＡＭＩブースレポート 「サイレントヒル ホームカミング」、「ワールドサッカー ウイニングイレブン2009」など続編タイトルが豊作 スクウェア・エニックスブースレポート
プログラマなら人月なんかさっさと超えろ - 矢野勉のはてな日記
Java, プログラミングノリノリで書いてみる。 人月というのは「人月の神話」以来、現場の技術者にとっては「お金の計算にしか使えない単位」なのですが、発注者側に分かりやすいということでいまでも大はやりしています。というか受注者側もまじめにこの単位で計算しています。 そしてJavaの世界というのは、私のようにJavaが大好きだからやってる、という人間はすごく少数派で、「そろそろJavaでもやっとくか」「Strutsの使い方覚えたからもういいか」「できればJavaなんかいじりたくないなー。俺も早くプログラマに『これやっといて』って言えるようになりたい」という人のほうが多いのが実情なんですね。その点Rubyの世界は、今は「好きだからやってる」人が圧倒的でしょう。プログラム能力の高いJavaプログラマを探すのは、プログラム能力の高いRubyプログラマを探すよりずっと大変だろうと思う。 Javaの世
人月を超えるとプログラムしている暇が減る : 404 Blog Not Found
2007年09月26日16:15 カテゴリArtMoney 人月を超えるとプログラムしている暇が減る 人月が銀の弾(たま)ではないことが知られて久しいのに、「人月伝説」が衰えないのは、誰が悪いのだろうか? 矢野勉のはてな日記 - プログラマなら人月なんかさっさと超えろ 人月というのは「人月の神話」以来、現場の技術者にとっては「お金の計算にしか使えない単位」なのですが、発注者側に分かりやすいということでいまでも大はやりしています。というか受注者側もまじめにこの単位で計算しています。 実は、プログラマー自身なのではないだろうか。 実は人月というのは、発注者側だけではなく、プログラマーにとっても楽なのだ。人月見積において、プログラマーが考えなければならないことは、「それを作るのにどれくらいの時間がかかるか」ということだけだ。「それを完了するのに何と何と何が必要で、それぞれこれくらいの手間がかかる
ハタさんのブログ : Javascriptによる大規模開発の覚え書き
未だに半年前のエントリにブクマされるみたいなので、もう少しjavascriptについて書いてみる。 今回は大規模化開発におけるJavascriptの注意点とかそういうの。当てはまらない環境の方もいます。(しかも基本的な事だらけで大したことは書いてないです) ほぼリッチクライアントを主目的としたjavascripterとコードを対象とします。 どちらかというと、ライブラリを提供する側の視点から 1.ログを出力せよ あなたが書いたコードは遅い、と必ず言われます。なので言われる前から、自分の書いたコードの処理時間をログするようにしましょう。 次のような処理時間を計測するロガーを作ります。 var TraceLog = function (){ this.startTime = -1; var outer = document.getElementById('_outer'); if(oute
ウノウラボ Unoh Labs: 携帯のエラーメールの種類
harukiです。 メールを送信するサイトの場合、メールアドレスのクリーニングは定期的に行うべきです。 そのためにはエラーメールを解析しなければなりません。 そこで、エラーメールの種類をまとめてみました。 SMTPエラー 存在しないメールアドレスや、正しい形式でないメールアドレスの場合は、 DoCoMo,au,SoftBankの3キャリアともSMTPエラーになります。 例として、以下の条件でメールを送信したとします。 From: sender@example.com Return-Path: bounce@example.com To: アドレス＠docomo.ne.jp MTAにより異なりますので、ここではPostfixを例にします。 Postfixではmultipart/reportのメールがbounce@example.comに届きます (※ 必要な情報のみに省略しています
marsのメモ - 開発環境に関わるメモ
今月で今やってる仕事の契約が切れるので，ここで培ったノウハウなどをメモしておこうと思う。 しかし，今後この手の開発系の仕事ができるとは限らないってのが悲しいところ。 プロジェクトポータルまわり とりあえず，Subversion(SCM), Trac(ITS/Wiki), Hudson(CI)は必須。この３セットがないプロジェクトなんてうんこ。 とにかくTrac-Subversionの連携が強力なので，Subversion以外のSCMは無視していい。HudsonはCIつうよりプロジェクトダッシュボードとして使うのが吉（数あるプラグインを有効利用しよう）。 marsのメモ - Trac marsのメモ - MacroBazaar - The Trac Project marsのメモ - 角谷HTML化計画(2006-04-25) marsのメモ - trac-post-commit-hookが
COBOL屋の呪縛 - masayang's diary
今回の日本出張ではいくつかのプロジェクトの状況をみてきた。で、思ったこと。 「COBOL時代のデータ構造を引きずることで、生産性や保守性が落ちている」 フラグだらけのマスター 本物のコードをだすわけにはいかないので、すごく簡略化した例で説明したい。あるシステムを利用できるユーザのマスターテーブルがあるのだけど、そいつには「なんちゃらサービス利用可否フラグ」みたいなのがたくさんついているのね。 この方式の問題は以下の通り。 テスト負荷 フラグがあるということはそれをチェックするif文があるということ。 if文があればテスト件数は最低２件は増える。 入れ子になれば、４件、８件...と増えていく。andやorでも同じ。 コードの冗長性 「あるユーザがサービスAを使えるか」を調べる処理と「あるユーザがサービスBを使えるか」を調べる処理はほぼ同様になることは明らか。 「サービスAを使えるユーザ」を調
開発スタイルの違い
日本のベンダーとの打ち合わせのときのことだ。 パフォーマンスが出ない件で、それについて議論していた。 ベンダーの開発リーダーと、私とアーキテクトとでのやりとりである。 開発リーダー「...という設計になっています。」 私「ということは、ここがボトルネックになっている可能性がありませんか」 開発リーダー「少々お待ちください」 電話をかけに行く。 暫くして、 開発リーダー「すいません。先ほどの説明は間違っていまして、ｘｘでした。」 アーキテクト「では、なぜここにキューが二つもあるんですか」 開発リーダー「ちょっと待ってください。」 また電話。 開発リーダー「ここは、担当者が換わったので、それぞれでキューを設けてたみたいで」 アーキテクト「なるほど。これは無駄ですよね。」 開発リーダー「そうですね。」 という調子で、説明も二転三転するし、確認の電話が多い。 うーむ。典型的な展開だ。 全体像を把握
18 til i die - ライセンスをちゃんと理解して使え
[実装編]ソースを流用してはいけない：ITpro という記事に同意できない。 PCの周辺機器メーカーであるエレコムは2004年，同社製ルーターの利用者からファームウエアのソース開示を求められた。そのファームウエアには，GPL（GNU GENERAL PUBLIC LICENSE）に従う「Linux Kernel」のソースが一部流用されていた。GPLの効力はオリジナルを流用したソフトにも及ぶので，ソース開示の要求に応えなければならない。だがソースを開示すると，ネットワーク越しにルーターの設定を変えたりファームウエアを更新したりする社外秘の保守機能が“公知の脆弱性”と化す。同社はGPLに従いソースを開示するとともに，保守機能の削除に追われた なんでその話の結論が「ソースを流用してはいけない」になるのか分からない。Linuxカーネルのソースに変な機能を組み込んだせいで、ライセンスの効力が組み込ん
Changelogのための英文テンプレート集 - ぴょぴょぴょ？ - Linuxとかプログラミングの覚え書き -
Changelog を英語で書く際に参考になるようなテンプレートをまとめてみました．git や svn のコミットログにも使えます． このエントリは今後も逐次更新を続けます（最終更新2018/11/01） リリースノートの英文についてはRelease note のための英文テンプレート集 - pyopyopyo - Linuxとかプログラミングの覚え書き -に分離しました git等のcommit メッセージにも使えます 以下，例文． バグ修正した場合 修正した場合 → fix を使うのが定番です Fixed a performance regression. （パフォーマンスが低下するバグを修正しました） Fix possible memory leak Fixed an issue where some devices would display the wrong image. (いく
Life is beautiful: 私のとっておきのプログラミングスタイル
404 Blog Not Found の「LiveCoding に学ぶプログラミングの三原則」を読んでいたらどうしても書きたくなったので。あくまで私のスタイルなので、参考にするもしないもご自由に。 1. スタードダッシュでできるだけはやくめどをつける 学生時代から夏休みの宿題は７月中に終わらせていた私とすれば、ラストスパートよりはスタートダッシュで勝負する。どのみち、どこかで思いっきり頑張らなければならないのであれば、締め切り間際ではなく、スタート間際に頑張るべきというのが私のポリシー。十週間のプロジェクトであれば、最初の二週間が勝負。そこで八割がたのめどをつけておき、後は流す。最初の二週間がめどが立てられなければ、十週間で完成できる可能性は低いと考える。常にそういう姿勢でいれば、締め切りぎりぎりになって致命的な欠陥が見つかって痛いめにあったり、本当は大幅な設計変更をすべきなのに応急処置で
(ひ)メモ - 行末の無駄なスペースなどを強調表示 - develock.el
エディタで行末に存在するスペースを強調表示する設定。 今流行の.emacs & .vimrc - グニャラくんのグニャグニャ備忘録@はてな Emacsだと、 Elips is just a typo of Elispのdevelock.el.gz がよさげです。 こんな感じ： こんだけ目立てばインデントおかしなコードを書くのを防げます。が、副作用として他人のコードをかたっぱしから直しなくなるので注意が必要です。 ついでにそのほか色関連のを晒します。 (defun recenter-and-fontify-buffer () "comment..." (interactive) (recenter) (font-lock-fontify-buffer)) (define-key esc-map "\C-l" 'recenter-and-fontify-buffer) ;; カーソル位置のfa
2007/08/29 - memo - unknownplace.org
昨日twitterでつぶやいていたのだけど、 みんながそれぞれ作って公開してる公開レポジトリを一緒くたにしちゃいたい。参加してる全員がどのファイルもみたり変更したりできるような。 パッチ送られてくる代わりに「後で見とくからコミットしといて」とかいえたりとか、つくりかけで放置したもので他の人が興味もったら続き作ってもらうとか、メンテするのめんどくなったのだれかにやってもらうとか、突発的に誰かと一緒にプロジェクト始めたりとか、できる！ で、それやりたくてとりあえずgoogle codeにレポジトリ作ろうとしたんだけど、あそこはなんかレポジトリ全体でライセンスをひとつ決めないといけないようなのでだめだ。 誰か信用できる人ホスティングしてくれないかなー。shibuya.plの人とか、yappoさんとか。
個人レポジトリを共有しよう！ - Yappo::タワシ
http://coderepos.org/share/ いちおう作ったお！ commit権いる人はhtpasswdのデータ送ってくだしあ。 見逃さなければついかするます。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Editors List - Dprogramming.com - The D programming language
Build Tools List - Dprogramming.com - The D programming language
チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー (2007-09-07)
僻地のプログラマkmt-t - わりとどうでもいい日記 1.0