techの最近のブログ記事

2010年4月 3日

PostTwiOauthでMTからtwitterに投稿を通知するプラグインを入れてみたんだけどね。

なんか今一ちゃんと動いてるかどうか心配っぽいんだけど、MTへの投稿通知をtwitterに対して行うプラグイン"PostTwiOauth"を入れてみました。

http://www.macminiosx.com/2010/03/movable_typeoauthtwitter_postt.html
Movable Type用OAuth対応Twitter投稿プラグイン PostTwiOAuth - BSDあれこれ

設定時に"oauth.cgi/(blog_id)"や"post_test.cgi/(blog_id)"という形式でCGIページを開く必要があるんだけど((blog_id)は数字)、そのときにパス末尾に/(スラッシュ)がくっついて"oauth.cgi/(blog_id)/"のようになって処理用のモジュールに渡って来てたようで、PostTwiOauthReq.pmとPostTest.pmが正常に動作しなくなってしまって大変往生しました。orz 何だっけこの挙動は...。PATH_INFOの末尾にスラッシュがくっついて来てるっぽいからなんだけど、何かの設定いじって云々とかだっけ...?

あと、途中でMT::I18N::decode_utf8を使うようになっていたのがうまく働いていなかったようなのでEncode::decode_utf8に変更evalで囲ってみた。詳細は追って調べる予定。

2008年4月13日

今週の置いて箱に従え

こんなエントリ書いたすぐ後にまたこれだと、よっぽど俺ってきたみ氏watcherなのかな(苦笑)。まあ、学ぶところの多いひとだとは思うけど、そのまま受け入れちゃいかんな、というところも相当あると思ってます。

http://gihyo.jp/dev/feature/01/kitami/0001
きたみりゅうじの「4月の風景」:第1話 ホントにデキるの? 新入社員|gihyo.jp ... 技術評論社

やる気まんまんなのはいいことながら、その場はその場なりに培ってきたルールってもんがあるわけで。
俺ルールを持ち出すよりも、まず知るべきはその場のルール。どんな工夫も、その心なしには単に暴走となってしまうのです...ってことでありますな。

違うよ。全然違うよ。

その「その場のルール」が、維持するに足るだけの実際の、真の価値があるかどうかは常に検証されなければならない。新卒/中途の別を問わず、新人の参加とはそのルールを検証するための絶好のタイミングである。それをこのように単なるダメ出しで片付けてしまうとは、ああなんともったいない

私がこのM山氏の立場なら、(ヒマさえ許せば)この新人に↓のような質問をしたと思うよ。

  • 当機能追加の分をカバーするテスト項目の策定
  • 新規UI画面・部品の設計意図
とか何とか。他にもあるかな。未来のビートルズはこういうところに眠っているかもしれんですしね来年には別のレコード会社に居るかも。。まあその上で、元の要求仕様に戻すよう促すか握りつぶして自分で書き直すかは判断のしどころかな。

だいたい、新卒はその場のルールを「壊してなんぼ」なんですけどね。まあ会社や案件の事情やら何やら色々あるにしても、そんな新卒がちょっと好き勝手やったがために面倒が起こるような作業、しかもモジュール単位で出来上がるまで待つとか、そもそもいきなり任せちゃいかんでしょ。ねえ。

2008年4月12日

今週の桃栗三年柿八年

http://rikunabi-next.yahoo.co.jp/tech/docs/ct_s03600.jsp?p=001301
SE2年目って、先輩ヅラできてうれしいよね?/Tech総研

それこそ専門の学科で学んで、
趣味もプログラミングで~
って奴が入ってきたら、
そんなん鼻でフフンと笑われちゃうぞ?

なんてのがそこそこの打率で出現するような業界だったら、みんなもうすこしいい顔して働いてそうですけどね。(にっこりと)

まあそういう野暮なつっこみはおいとくとしても、たった1年であっても「先輩面」できることは、少ないけれどもちろんある。「コーディングなんてのは"last one mile"でしかない」という真理の一面をもって得意満面な鼻をへし折ってやる程度には。それが出来れば先輩面したっていいよ、けど出来なければもう一度後輩と机並べて勉強しなおしてほしいな。

もちろん、本当に"last one mile"であるかどうかなんてことはこの際どうでもよくて、その新入りがデマルコを読んでいればあるいは意気投合できるかもしれない(けど、学生時代にピープルウェアあたりを読みこなせるかと言ったらまず無理だろうしな)くらいにとどめておいてほしいな。まあ、ともあれ高々1年くらいで後輩に偉そうに何かふるまってやれるようなことなどそもそもないし、その"last one mile"加減を肌身を持って理解できて話せるくらいになるには1年やそこらじゃ足りないしなあ。あとはまあ、「先輩面」なんてできたところで何の役にも立たないし、そもそもそんだけの器量に足りてんのかしらワタクシ(俺も俺も)、と疑いつつ日々精進を重ねるのがよろしいんじゃないかと。どの業界においても。ええ。

逆に言えば、そうなれるように新人教育を行うことが古参の採るべき道筋なのかもしれんですね。

2007年7月13日

引っ越しのサカイちょっとこい

そうそうそろそろ引っ越しの時期やねんな。

…いやいやいや。

http://rikunabi-next.yahoo.co.jp/tech/docs/ct_s03600.jsp?p=001108
SEって、めっちゃ勉強家だよね?/Tech総研

んー? それだけでも、普通に「勉強家」と呼んで然るべきもんじゃないんですかね? それとも、

 SEさん、特にプログラマ職は、多くの場合「効率のよさ」を重視する傾向があります。ここで言う効率のよさとは「いかに素早く目的の情報にたどり着くか」であって、なんでもかんでも頭に詰め込んで雑学大王を気取ろうなんてのは、その真逆であると見なされます。技術者的に言えば「リソースのムダ遣い」となるわけだ。

 あ、リソースってのはもちろん脳みそのことね。なので「この本にはどんなことが書いてある」と理解してしまえば、必要なときにそれを開けばいいとなる。確保はしておくんだけど、読まないまま並べてる……という背景には、そんな心理が見え隠れいたします。よーするに、読書するために買ってるんじゃなくて、自分専用の資料を取りそろえておくために買ってるんでありますな。

 個人的には「勉強」というよりも、「投資」というほうがしっくりくるように思えます。技術者としての引き出しを多く持つための自己投資。資料に金を惜しまない点で「勤勉さアリ」とは言えるでしょうが、「本を買うから勉強家」というのはちと違うよなぁと思うのでありました。

としているように、世のSE/PG方の「不勉強」ぶりを挙げて批判したいだけなのかもしれませんけども。

全部読もうと、一部を読みかじろうと、そこから「何かを得よう」という意識のある限りそれは「勉強」でありそうした性向を持つ人は「勉強家」と言っていいんですよ。謙遜するこたーない。そしてそれは、分野の選択を間違えたりレベルを取り違えたりしても何らかの糧を掬い取ることができる点で、「投資」とは根本的に異なるものだ。失敗しても身ぐるみ剝されたりしないしな(笑)。

あと「無駄遣い」的にいろいろ知ってる奴は強いですよ。もちろんその使いどころ(のなさ加減までも含めて(笑))をきっちり押さえてる前提においてですけれど。街中でスープラのアクセルべた踏みなんかしてたらぶん殴られるでしょ?そういうこと。

2007年6月 6日

玄関開けたら二分でS-in

http://www.atmarkit.co.jp/im/ces/serial/system01/system01a.html
「インターネットショップ」はすぐには作れない - @IT情報マネジメント

これを書いていて思い出したのが今日見つけたこれ。

いやこの記事の論旨は一応ちゃんと理解した上でですけども。しかしてそれをシステム担当者が頭から信じ込むほどであってはいけない。あえてあまのじゃくに言うならば、どうにかして「すぐに作れる方法がないものか」探{す,してやってみる}のも、システム担当者の力量というもんじゃないすかね。

http://www.asahi.com/business/update/0521/TKY200705210291.html
asahi.com:日本のIT投資、自前主義が弊害 経産省が効率化提言 - ビジネス

お前が言うな>経産省、ってのはさておいて。

何か面白いサービスはある日突然飛び出してくる。
後追いでもいいからそれを追いかけるならば、あとになればなるほど損が増える(手遅れになるとは言わないが)。
ありふれたサービスならば、そこらじゅうに車輪が転がっている。

それを考えれば、「すぐにはできない」と尤もらしく語ることがどれだけの意味をもつか。ちょっと立ち止まって考えておく必要はある、と思うんですよ。

ただしもちろん、あまりに拙速に事を運ぼうとしたり、簡単にできるとおもってあれやこれやと無理難題をふっかけてくる顧客や営業に対しては話は別だ。「すぐにはできない」と言っておけ。そして、「すぐにつくって」しまえ。「すぐにはでき」あがってないように見せつつあまった時間を研究開発やネタ探しにこっそり充てるといい。

2006年10月 5日

SEの条件

いやあの。
「実態としてどうなのか」と「あるべき姿としてどうか」ってのは区別せんならんよ。当たり前でしょ?

http://rikunabi-next.yahoo.co.jp/tech/docs/ct_s03600.jsp?p=000901
SEってみんな、パソコン改造するの好きだよね?/Tech総研 [リクナビnext]

天真爛漫に「好き」なだけではどんな仕事もやってけない。そりゃ当然。だけど、手前の得物を自分で手入れできないような奴は結果的に弱いよ。とはいえ今のエンジニアが知っておくべき・興味を持つべき分野があまりに幅広くなりつつもあり(コンピュータの構造から人月計算から顧客の商習慣からetcetc...)、各自の置かれた状況に合わせて得意分野をそれぞれ伸ばす中で、PCの中身をよく知らなくてもいいチームメンバーが増えてきた、ということなだけだけどな。チームの中で何人かPCに詳しいor好きな奴がいるチームは強い。けど、そういうコマが居ないところは憂慮すべき状況だよ。

前居た会社にそういう詳しい奴がチームに自分以外(苦笑)誰も居なくてそういう奴らはenbugばかりしまくってて別の意味で楽しい環境だったけどな。java.util.LinkedListとjava.util.ArrayListの使い分けすら分からないステキPGのおかげでどんどん処理が遅くなっていく濃密なプロジェクトだったなあ。

「結局のところSEの多くは雇われの会社員なわけなので、仕事として必要だから使っているだけ。だから、別にそれが『好き』とイコールではない。」

この「仕事として必要だから」を結局どう解釈できるかによるね。仕事だから嫌々…だったらそのステキPGみたいなことになる。そうではなく、仕事として必要な知識を自発的に汲み取りに行く…だったら十分「好き」と呼べる範囲だよ。その「好き」がPC改造(笑)に結びつくとは限らんよ。そもそもなんか設問おかしくね?

なんか、内情を知った気になってすれた見方をするエンジニア崩れのニオイがそこはかとなくしてくるなあ。そういうの俺は嫌い。…そうじゃないといいけど。

2006年9月14日

factory method

http://www.itmedia.co.jp/enterprise/articles/0609/12/news024.html

地方都市とソフトウェア開発――変革するアプリケーション開発~「ソフトウェアファクトリー」という考え方 [ITmedia エンタープライズ]

特に、大規模な案件を1人あるいは小さなまとまりで開発するソフトウェアセル生産方式によって、スキルを持った技術者や地域といった「個」の存在がクローズアップされるようになれば、エンジニアの地位改善や地方都市のIT産業振興に大きく寄与できる。そうなれば、地方といった地理的な問題に左右されることなく、都市部と連携した活動や産業の活性化が可能となる。現在の下請け構造から脱し、日本で一番競争力の高いファクトリーを沖縄で実現することが一つのゴールとして見据えられている。成本氏は、この仕組みを国家全体的なプロジェクトとして各地に適用し、日本の産業構造全体の変革を目指したいと語る。

ここで言われていることの大部分は私も大いに同意するところなんだけど、同時に懸念であることも確か。スキルを持った技術者が「個」として認められることの大きな要素のひとつは、他の「個」に認められること、なんだと思う。それはつまりスキルフルな技術者(やそれを目指す若者)が多く集まりやすい土地ほど有利=都市に集中しがち、という事情が絡んでいてなかなか一筋縄には行かないところがあると思うのです。

実際、私もこれまで何社か体験してきて、今の環境が一番満足しているのだけれど、その根拠の一番の理由がそれだけの実績とスキルと雰囲気がたくさんあって、その中で「認められたい」というプラスのモチベーションがこれまでの環境の中で最も強く思う(それだけにプレッシャーもあるけど:-)。これから地方が魅力的な「ソフトウェアファクトリー」として機能するためにはただ職場や求人があるだけじゃダメで、技術者をどうモチベートできるかが肝なのでは、ないですかね。

このテーマはまとまったら思い切り書きたいな。

2006年9月 3日

privateとpublicしか知らないお間抜けPGに用はないよ(違)

http://itpro.nikkeibp.co.jp/a/biz/shinzui/shinzui0823/shinzui_01_1.shtml
http://itpro.nikkeibp.co.jp/article/OPINION/20060823/246177/

『株をやったこともない日経の記者が,経済とか市場がどうしたとか書いてもまったく信用できない』とか言われたらしいのがよっぽど癪にさわったんだろうか。自己責任がどうのとか、ノートPC持ち出しは情報漏洩だとか日経が日経らしく明後日の方向にすっとぼけかましてるのはさておくとして(苦笑)、/.の「オーケストラの楽団員」というメタファで始まるツリーはなるほどと思った。

http://slashdot.jp/comments.pl?sid=330399&cid=1007108

ただ、他のツリーでは「会社所有をやめる」即ち「私物」⇒「好き勝手やっていいPC(なんてアリなのか?いややばいだろ?)」という疑義が多く見えていて、これはこれで興味深い。

企業側からは補助(=権利)を渡すと同時にポリシー(=義務)も与え、企業と個人との間の双務的契約のような意味合いを持つことになる。この時、企業はもちろん個人側も「お互いの利益を最大化」するように活動しなければならない。そうなると、「(補助はどうあれ)自分のモノなのだから勝手に」なんてする訳にはいかないものなのだけど。何だろうね、「会社=公」でもなく、「私」でもない。「個」としての活動を意識した事がないと、「会社を離れたら好きにしていい」という意識に陥ってるとか、そういうことなんだろうか。自信ないけど。

私は常々こういう「オーケストラ」的な集団にこそ魅力を感じるし、自分自身そうした腕利きの「楽団員」であれたらと思い仕事をしている。...っていうことを納得させてくれた記事だった。そうだ。俺は自分の得物くらい自分で愛情込めて整備してやりたいんだ。会社の渡されたって何もできひんって。...ああ、つまるところそこなんだ、きっと。

2006年6月11日

codewriter

まぁ、笑ってばかりじゃ何なので、ちゃんとした指摘もしておきましょう。:-) 一番深刻と思われるところだけ。(他はお任せ:p)

http://blogs.itmedia.co.jp/tamaki/2006/06/post_57ab.html

「脱オブジェクト指向のススメ」 [雇われIT社長の乱心ブログ@ITMedia]

開発のスキルをUPさせるためには、とにかく、コードを書くこと。寝ても覚めてもコードを書くことです。そうしているうちに、いつの間にか、オブジェクト指向も身に着く(というか、その本質が何かに気づく)でしょう。

それは、ありえない。はっきり言いましょう、楽観すぎる。それに、この人は技術者ではないのだから(少なくともこの一連のblog記事を読む限り、技術トピックをいくつか知ってはいたとしても「こちら側」の人間では決してないよね)、そんな「向こう側」の人間がこの状況において「とにかくコードを書け」とは、一番言ってはいけない類の発言です。

続きを読む: codewriter

2006年6月 9日

偉い人はそこのところがお分かりでない。

http://blogs.itmedia.co.jp/tamaki/2006/06/post_57ab.html

「脱オブジェクト指向のススメ」 [雇われIT社長の乱心ブログ@ITMedia]

...哀れだなあ。

続きを読む: 偉い人はそこのところがお分かりでない。