Struts1職人の朝は早い - きしだのHatena
Struts1職人の朝は早い。 「毎日毎日DBとアプリサーバーが違う。機械ではできない」 「このstruts-config.xmlはダメだ。ほら、すぐ裂けてしまう」 ここ数年はLLとScalaに押されているという。 下町Struts1の灯火は弱い。だが、まだ輝いている。 「やっぱりアレですね、たいていの若い人はすぐやめちゃうんですよ」 「それを乗り越える奴もたまにいますよ。そういう奴が、これからのStruts1界を引っ張っていくと思うんですね」 今日も彼は、日が昇るよりも早くstruts-config.xmlの整形を始めた。明日も、明後日もその姿は変わらないだろう。 そう、Struts1職人の朝は早い。 夜も遅い。
社会人が勉強するときに知っておくべき３つのこと - きしだのHatena
某社の社員の人が始めたというAdvent Calendarが、13日になっても13日分の担当が決まってないという状態だったので、空気よまずに書いてみました。 「新人／若手向け、これだけは知っとけTips25 Advent Calendar 2012」 http://www.adventar.org/calendars/37 これだけは知っとけTipsということですけど、これTipsじゃないなーと思いながら、でもまあ知っておいたほうがいいよなということを書いてみます。 13日担当分ですが、もう一件Advent Calendarがあるので、このエントリの日付は12日にしています。 本は読み進むと必ず読み終わる まず、勉強するときに知っておいてほしい一番大事なことは、「本は読み進むと必ず読み終わる」ということです。 どんなに厚い本でも、難しい本でも、本という体裁になっている以上は有限のページ数し
誰かが亡くなった - きしだのHatena
朝。 訃報を聞いたという人がいた。 それが確かかどうかもわからない。 だれかもぼくにはわからない。 ただ、訃報があったと知った。 気になった。 昼。 数日前に会った友達が亡くなった、と嘆いてる人がいた。 その人は知り合いも多いだろうし、ぼくと興味の範囲も違っているので、あまり面識がない人なのだろうと思った。 少し年下の人が、年も近いのにと嘆いていた。やはり、あまり知らない人かなと思った。 それでも、気になった。 夕方。 福岡の人が、また来ると言ってたのに、と嘆いてた。 お会いしたかったと言っている人もいた。 案外、知っている人なのかもしれないと思った。 夜。 亡くなった人の名前を聞いた。 知ってる人だった。@akhkさん。 Twitterでは、初期から知っていた。やりとりしたこともある。 実際に会って話したこともあった。ただ、会話がはずんだわけでもなく、単に社交辞令的な挨拶だった。 構築し
品質が求められる部分のテストはエキサイティングだ - きしだのはてな
どうも、テストを書きたくない人という認識がされているのだけど、ぼくが書きたくないのは退屈で割にあわないテストで、品質が求められる部分のテストを書くのは、楽しいし、かなり好きです。 それは、たとえば品質について理解してないお客さんのプロダクトだとしても、やっぱり間違ってちゃいけない部分は、せかされても待たせて時間とってテスト書くわけです。金額計算とか。 そのかわり、商品一覧に削除済み商品がでちゃったとか、そういうところは見つかったら直せばいいかーとかで、機能見せれる早さ優先でやったりするわけです。品質対策にかかるコストのほとんどはバグの発見のためのコストで、見つかったバグを直すのは時間かからないし。そもそもそういうのは「言ってなかったけどそこは対応するメーカーがない商品も削除扱いだから」みたいなことをあとから言われることが多いわけで。 でも、まあ、結局１年間は見つかったバグを直しますよってい
Twitterが面白すぎるその理由は、意外なほど簡単＆シンプルだった - きしだのHatena
先日Twitterは特にリニューアルしてもいないけど、Twitterについて思ってることをここにまとめておこうと思う。 僕はTwitterが楽しくて仕方がない。 何でこんなに楽しいのか？とふと考える。これまでも何度か考えてきたんどけど、気がついたその答えは意外なほど簡単で、シンプルなものだった。 自分の好きなことを自由に言えて、それに関心をもってくれるたくさんの友だちがいる そう、気軽にそして素直に語り合える仲間がいるからだと。 ローラがいるとか芸能人がいるとかは全く関係ない。その証拠に僕は彼女たちをほとんどフォローしてないし、たまに共有して流れてくるものがあっても、それは一時的な面白さでしかなかった。 考えてみたら当たり前の話だ。世の中、友だちと話すことより面白いことなどありはしない。 信じられないかもしれないが、ここでいう「友だち」は、Twitterの場合実際会ったことも、そして話した
ネットワークに自信のない人は東大講義の情報工学概論Ａを見よう - 2012-01-28 - きしだのはてな
東大にUTオープンコースウェアというのがあって、いろいろな講義資料が公開されています。 http://ocw.u-tokyo.ac.jp/ その中には動画授業があるものもあって、そのほぼすべてがおもしろいです。ただ興味がもてるかどうかという違いだけ。 その中で、情報工学概論Ａというのがあって、授業内容としてはネットワークの概論になってます。まだ全部見てないけど、ネットワーク全般の話からTCP/IPの話、セキュリティまでの講義が公開されてるみたい。 こういう一貫した話がちゃんと語られてる講義というのはなかなか公開されてない、公開されてたとしてもネットワーク設定程度だったりするので、これは貴重だと思います。 http://ocw.u-tokyo.ac.jp/lecture?id=11314&r=609526321 ネットワークの勉強をしたことがない人は、テレビのかわりにこの講義を流しておくとい
SwingアプリでホットリローディングできるJaveleonが便利 - きしだのHatena
Webアプリだとホットリローディングできるフレームワークがあったり、NetBeansが勝手にビルド・デプロイしてくれたりして、ソースコードのビルドなどを気にしなくてもいいようになってきてるんですが、Swingアプリではホットリローディングができるというのはなかなかなかったわけです。 で、このJaveleonというのが、Javaアプリケーションでホットリローディングできるようにするツール。 http://javeleon.org/ ライブラリじゃないので、普通に作ったSwingアプリなどでホットリローディングできます。 ここではNetBeansプラグインとして使いますが、javaコマンドにパラメータ付加するだけなので、Eclipseなどでも使えるようです。 インストール NetBeansのアップデートセンターに、次のURLを追加します。 http://javeleon.org/javeleo
九州大学医学部のほうから来たKさんの開発した「ゴーストfor文」がものすごい - きしだのはてな
九州大学医学部のほうから来たKさん*1が開発した「ゴーストfor文」がものすごい。 普通の大人なら、1分で指定回数繰り返すfor文が書けるようになる。 やりかたは下の図を見てね。 変数iを使って5回繰り返す場合 ・iを①、②、④に入れる ・5を③に入れる ・答えは for(i = 0; i < 5; i++) これでインド人に勝てます！ なお、普通に書いてるだけじゃないかという批判にKさんは Cなどでfor文の書き方を知っている人はいっぱいいます。でも、Cをやってこなかった文系学生だって一杯いるのです。そういう人がお魚のイラストで簡単にfor文が書けるようになればそれでいいじゃないですか。 などと反論しているようです。 参考：東大医学部現役合格生の開発した「ゴースト暗算」がものすごい - Togetter *1:東京からみた場合
「プログラマ」とは別に「バインダー」という職種名を思いついたのだけど 2011-12-15 - きしだのはてな
よくアルゴリズムの話とかすると「アルゴリズムとか業務で使わないから。ライブラリあるから」みたいな話が出ますね。今日もTwitterでkumagiさんが「競技プログラミングが業務で役に立たないって言ってる人は・・・」って話してたわけです。 でもまあ、アルゴリズムの勉強ってのは、実装したい問題をいかに効率のいいプログラムに落とすかっていう話なんで、プログラムを組むっていう業務をしていたら必要ないとは思わないはずなんで、「アルゴリズムいらない」っていう人がやってる業務はプログラミングじゃないんじゃないのかと思ったりするわけです。 で、noritunaさんが「コーダー」を挙げてて、こういう文脈でよく出るんだけど、これはちょっと違和感あって、「コーダー」は誰かが書いたプログラムをコンピュータに入力するだけくらいの語感で、別に「プログラマ」という職種が必要になるサポート的業種で、でも実際は「プログラマ
「創るJava」で勉強してるところをUst配信しても文句いいませんよ？ - きしだのHatena
書籍での演習を著者に無断でUstすることが問題になるかどうか。 まず、あらかじめ、これは法的な正しさは保証しないことをお断りしておきます。 書籍のサンプルは著作物か まず、書籍のサンプルが著作物になるかどうか。 これは、単体では著作物にならない可能性もあると思います。APIの使い方を示しただけの、誰が書いても同じようになるプログラムは著作物にはならないと思います。 「創るJava」に「ボタンを押したらテキストフィールドの入力がテキストエリアに表示される」というサンプルがあるのですが、このサンプル単体に著作権を主張するのは難しいと思います。 スレッドのサンプルは結構独自性あると思うので、そこに関しては著作権を主張できる気はするのですが、「電車」を「トイレ待ち」に変えてレイアウトを変えたものに著作権侵害と言えるかというと、難しくなる気がします。 ただ、サンプル単体が著作物ではないとしても、それ
変数名、関数名とコメントでは表現する内容が違う - きしだのHatena
先日Twitterにこんなことを書いた。 なにやってるかはコード見ればわかる。なにやろうとしてるかはコードみてもわからんからコメント書け。 そうしたところ、変数・関数(メソッド)に適切な名前をつければ改めてコメントの必要はないんじゃないかという指摘をうけた。 そんで、しばらくやりとりをしたのだけど、その中で結論として変数名・関数名やコメントで表現する内容が違うということに気づいた。 やはり、変数名・関数名には、その機能を表すものをつけることになる。一方で、コメントにソースコードで表されていることを書くのは意味がない。 if(a==0){ //aが0のとき } のようなコメントは、意味のないコメントとしてよく例にあげられる。 if(a==0){ //パラメータが渡されなかったとき } のように、判定の意図を書くべきだ。 ここで、変数をaじゃなくてまともな名前にすればいいんじゃないかという話で
難しい本、分厚い本を読んでいて挫折しそうになったらどうするか - きしだのHatena
そのまま挫折しましょう。 難しい本、分厚い本を読んでいて挫折してしまうのだけどどう読み進めればいいかという質問をもらいました。 今回、一連のエントリーでかなり分厚い本や前提知識が必要な本をとりあげたので、そういう本を読んでいるとくじけることも多いんじゃないかと思います。 そういうときは、そのまま挫折して、次の本に行きましょう。で、気になったころに読み返せばいいと思います。 挫折するということは、必要性が出てないか、まだ実力が足りないか、その本が面白くないかだと思います。 必要性が出てないなら、ほっておきましょう。いつか必要性が出たときに読めばいいです。 実力が足りないとしたら、自分の実力にあった本を探して、挫折した本が読めるような力をつけましょう。 面白くない本もほっておきましょう。ほんとは面白い本なのに、面白さがわかってないだけかもしれません。面白さがわかってきたら読めばいいと思います。
アルゴリズムの勉強のしかた - きしだのHatena
この記事で、アルゴリズムの勉強はアルゴリズムカタログを覚えることじゃないよということを書きました。 プログラムの理論とはなにか アルゴリズムの勉強というのは、スポーツで言えば腕立て伏せや走り込みみたいな基礎体力を養うようなもので、「ソートなんか実際に自分で書くことないだろう」とかいうのは「サッカーは腕つかわないのに腕立ていらないだろう」とか「野球で1kmも走ることなんかないのに長距離の走り込みいらないだろう」とか言うようなものです。 Twitterでアルゴリズムの勉強とはなにかと尋ねられて、「アルゴリズムの基本的なパターンを知って、それらの性質の分析のしかたをしって、いろいろなアルゴリズムでどのように応用されているか知って、自分が組むアルゴリズムの性質を判断できるようになることだと思います。 」と答えたのですが、じゃあ実際どういう本で勉強すればいいか、ぼくの知ってる本からまとめてみました。
画像を出力するだけのWebサーバー - きしだのHatena
適当に画像を生成する必要があったので、JDKのHttpServerを使って画像を出力するだけのWebサーバーを作ってみた。 「http ://localhost:6780/HOGE」にアクセスするとこんな画像が得れる。 ソースはこんな感じ package imageserver; import com.sun.net.httpserver.HttpExchange; import com.sun.net.httpserver.HttpHandler; import com.sun.net.httpserver.HttpServer; import java.awt.Color; import java.awt.Font; import java.awt.Graphics; import java.awt.image.BufferedImage; import java.io.ByteArr
システムはどのくらいのデータを扱うか。 - きしだのHatena
ちょっと気になったので調べてみたら、営業のためのデータはどんな業態でも一社だいたい月10億件くらいで頭打ちっていう感じになった。 追記 2011/9/17 15:54 業態を比べたいので、国内の最大シェアっぽい企業で比べてます。 世界に広げたとしても、実業にからむなら、だいたいは会社が分かれてシステムも分けるだろうし、トヨタの販売台数が世界770万台、国内130万台でせいぜい6倍というのを見ても、一体だとして10倍の差は出ないし。 トヨタの2011年国内販売台数、130万台の見通し | ロイター 追記ここまで コンビニ 最初にたくさんデータが発生しそうだと思って考えたのがコンビニ。 フランチャイズ協会のデータによると、全国の店舗数が43690店舗、月間客数が13億人で、客単価が600円。 http://www.jfa-fc.or.jp/particle/42.html 一番でかい7-11の
Redmineで作業管理すると仕事をサボりにくくなった話 - きしだのはてな
会社に出勤して他の人と作業するなら、一日何も作業しなかったということはあまりないんだろうけど、家でひとりで作業してると、せっぱつまってるのに結局だらだらして一日なにも作業をしていないということが多くあって、それをとても問題に思ってました。 やらないといけないのにやってなくて、作業が遅れて気が重くなって、気が重くなるから作業も遅れてという悪循環。 作業の効率をあげるためにはRedmineなんかの管理ツールを使うことが不可欠だということはわかっていました。ただ、問題は作業にそもそもとりかかれないというものでした。 それが、Redmineの設定する気持ちの余裕がなくて後回しにしていたのを、ちょっとどうにもならないと思って作業用Ubuntuに入れて使い始めたら、作業が効率よくなるだけじゃなく、ちゃんと作業にとりかかるようになったことに気づきました。 Redmineじゃなくても、TracでもBack
プログラマになるための勉強をしている人の前で話をしてきた - きしだのHatena
イデアルITスクールというところで、１時間ほど話をしてきました。 プログラマとしてやっていくために大事なことというテーマ。 資料を作らずに、というか構想すら練らずにやってしまったので、ここで整理とまとめと補足を。実際にこれをしゃべったというのではなくて、だいたいこんなことをしゃべろうとしてたという内容をかなり盛って書いてます。 当然ですが、プログラマの仕事はプログラムを書くことです*1。 プログラマとしてやっていくためには、どこで動くプログラムを書くか、なにをするプログラムを書くかということを意識することが大事です。 ということで、まずはプログラムが動くところがどう変わったかという話。 1970年代ころは、デバイスを動かすためのプログラムが多かったのではないかと。 あと、ここには書いてないけど、業務アプリはほぼメインフレームで動いてたと思います。 それが、1980年代くらいからパソコンが出
どのプログラム言語を選ぶべきか・・・ - きしだのHatena
PHP-erはダメな言語でいかにまともなものを作るかっていうマイナスからのスタートだし、 JavaScript-erは何もないところで何か動いて楽しいっていう０からのスタートだし、 Ruby-erはRuby好きって言ってるだけだし、 Java-erはJavaの仕様にしか興味がないし。 Scala-erは生ぬるいこと言うと狩られるし、 Smalltalk-erは過去の栄光語ってるだけだし、 COBOL-erは苦労話しか出ないし、 FORTRAN-erはプログラムに興味ないし、 Perl-erは同窓会みたいだし、 Python-erは仲間探すの大変だし、 Erlang-erはどこにもいないし、 C-erは目先の仕事にしか興味ないし、 C++-erはC++の復興にしか興味ないし、 C#-erはWindowsにひきこもるし、 ActionScript-erはAdobe税はらうのに大変そうだし、 O
テスト駆動開発が嫌いだ - きしだのHatena
テスト駆動開発が嫌いだ。 ただし、ここでの「テスト駆動開発」は日本で今TDDと呼ばれてる多義的なものじゃなく、「テスト駆動開発入門」にかかれている「テスト駆動開発」。 もっと正確にいうと「テスト駆動開発入門」がミスリーディングをわざと誘ってて有害で嫌い。 テストは、プログラムが正しく動くことは検証できるけど、プログラムが正しいことは検証できない。そのようなテストに設計を依存してしまうと、正しく動くプログラムは作れるけど正しいプログラムは作れない。 設計も含めてテストによって駆動しましょうという「テスト駆動開発入門」のやり方では正しいプログラムが作れない。プログラムの正しさを別のやり方で担保しつつ、そちらを中心に開発を駆動して、あくまでも開発作業だけをテストで駆動するという考え方のほうが、正しいプログラムに近づける。 そして、TDDをいまがんばってる人たちも、それは当たり前にわかってると思う
構造化されたGoogle+のストリームと半構造のTwitterタイムライン - きしだのHatena
半構造 最初に半構造という言葉について。 半構造というのは、完全には構造化されない構造です。 構造化というのは、事前にデータの形式がどのようになるか決められているような構造です。半構造は、ある程度の構造を事前に決めておき、構造を決めない部分を残すような構造です。 構造化データとしてわかりやすいのはCSVで、各行ごとにデータがあって、カンマで区切られた項目は何番目がどのようなものになるかといったことが事前に完全に決められています。 半構造データとして代表的なのはスキーマなしのXMLで、タグの書式やツリー構造ができることはきまっているけれども、どのようなタグが入るかは決められいません。 一般のテキストデータのように、まったくデータ構造がきまっていないものは無構造ということになります。 Google+の構造 Google+の場合は、ユーザーはいくつかのサークルを持ち、そこに他のユーザーを追加しま
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
