どうも、やりたい事が多過ぎて消化不良気味のながたかです！
時間のやり繰りが大変ですが、なんとか納得のいく毎日を過ごせたらいいなと思うのですが、手の広げ過ぎで、一つ一つの密度が薄くなってしまう事が心配な最近です。。
やれりゃいいというわけではなくて、やっぱり自分が納得いくレベルでやってこそだと思うので、多少優先順位をつけて選択と集中が必要だなと痛感しております。
けど、そんな中でも「忙しい忙しい」を連発する人にはなりたくないですね。
それじゃせっかく入ってくるチャンスも目の前で逃げてってしまいます。
はぁ、「『忙しい』って言わない」とココロの中で決めたのはいつの事だったか、ワタシの周囲のみなさん、もしワタシが「忙しい」って言ってたら注意してくださいw
さてさて、今日バイトの時給が上がりました！
雀の涙程ね(笑)
けど、額はいいんです、どうでも。
「年収は給料 - 授業料だと思え」という土井英司さんの言葉が自分の中の仕事観としてあるから。
あまりプログラミングに対して熱心でなかった自分が大学時代を通して出来ていなかった沢山の経験をさせてもらっている上、給料をもらっているのだから、時給が上がったという事実だけでもうお腹いっぱいです。(ま、もちろん、もしUP額が多かったらそれはそれだけ嬉しかっただろうけどねw)
今の自分が出来ている貢献なんて、現在もらえている時給分だってないかもしれない。。
謙遜でもなんでもなく、まだまだ自分は大した価値を生み出せてはいないので、あとこのバイト先で働けるのも四ヶ月ほどしかないけれど、もっともっと精進しようと思った。
学べる事は学び尽くして来春四月から新たなステージへ！
プログラミングの話。
ちょっと社員さんとのやり取りでSingletonというのを教えてもらったので、研究室にあったデザインパターンの本でシングルトンの部分だけ読んでみた。
シングルトンというのは、そのクラスのインスタンスが一つしか作られないようにしてある実装の事だそうな。
サンプルコードをそのまま記載すると以下
public class Singleton {
private static Singleton singleton = new Singleton();
private Singleton(){
System.out.println("インスタンスを生成しました");
}
public static Singleton getInstance(){
return singleton;
}
}
privateなコンストラクタとprivateかつstaticなインスタンス、そしてpublicなゲッタが用意されていますね。
これだと、外部からコンストラクタを呼ばれて新たなインスタンスを作られる事を不可能にできるんですね。
社員さんから教えてもらった時は「ほぇ〜なるほど」と思いました。
で、後で本で確認をした時に、その本の説明文が印象に残りました。
インスタンスは一つしか作らないし、作りたくない(システム中に一つしか存在しないものを表現したい時)
「プログラマが注意しているからインスタンスが一個しか生成されない」のではなく
指定したインスタンスが絶対に一個しか存在しない事を保証したい
インスタンスが一個しか存在しない事をプログラム上で表現したい
場合に用いるパターンだと。
プログラマが注意してnewしないようにすれば、コンストラクタをprivateにする必要は無いのだけど、そうではなくて、どうしたってインスタンスは一つしか生成されないという事を保証する。
この大事さ。
スキルも経験もバラバラな大人数で協力して開発を進めて行く上で、こういう「保証」って凄く大事なんだろうなと思った。
弾さんが
「頑張らなきゃいけないシステムなんてクソ。頑張らないでも回るのが本当に良いシステム」
と言っていたのを思い出した。
ここで言うと、「絶対に二回以上newしないようにプログラマが『頑張って』注意する」というのは明らかにクソな運営だと。
こういう工夫一つで、そういう無駄な頑張りを不要にできる。
そんな知恵を見ました。
デザインパターンって面白いカモ！もっと読んでみようかな。
丘の上の松がむりならば
谷間の低木になれ。ーーだが、小川のほとりにあるもっとも美しい低木に。
木になれないのなら、やぶになれ。
やぶがむりならば、一握りの草になれ。
そして、大通りを楽しくしてやれ。
カワマスがむりならばクロマスでよい。
ーーだが、湖の中でもっとも生きのよいクロマスに！
われわれはみなが船長にはなれない。水夫になるものもいよう。
ひとりひとりに何かすることがある。
大きな仕事もあれば、小さな仕事もあろう。
そして、しなければならない務めは手近にある。
大通りがむりならば、ほんの小路でもよい。
太陽がむりならば、星になれ。
成功と失敗を分けるのは大きさではない。
何になろうと最上のものになれ！
---ダグラス マロック
人間皆、それぞれの趣向があって、さらにそれぞれの置かれた状況がある。
それらを踏まえた上で、自分が何になりたいのか／なれるのかを考えてそれに向けて歩いて行くわけだけれど、それぞれの趣向の中での最上になれたら最高ですね。
最上の演奏家が集まって、最上の空間が出来上がる。最上の指揮の下で。
そこには変な嫉妬とかつまらない争いなんてなくて、最上が最上同士尊敬し合っている。
そんな生き方が出来たらいいのにね。それに足る最上の何かになれたらいいのにね。
自分はまだまだ本当に小さ過ぎて。。
そういう事を考えると、一つ一つの事柄に対してめっちゃファイトが湧いてきます！
この気持ちを忘れずに毎日いられたらいいのだけど。。
さて、明日バイト頑張ろっと！
はい、おーわり！
どうも、最近は沖仁さんというフラメンコギタリストにハマっているながたかです！
フラメンコギターは以前から気になっていたのですが、沖さんの曲はポップなフラメンコという感じでとてもとっつき易くて大好きです♪
軽快なメロディーとテンポの中、どこか影のあるメロディーがフッと入る瞬間にグットきます！
下にYouTubeの動画を貼るので是非聴いてみてください＾＾
今度ライブもありますよ！！
あぁ、何度聴いてもエェのぅ、フラメンコギター習いたい！！
ところで、今日は
Japan Linux Symposiumの基調講演(無料)を聞きに行ってきました！
会場はANAインターコンチネンタルホテル。
某インターン最終日に社長の有り難いお話を拝聴させていただいた思いでのある場所でございます(笑)
以前たまたまネットでこのイベントの事を発見し、即研究室のメーリスで参加者を募り応募したのでした(付き合ってくれた三人ありがとう＾＾)
梅田望夫さんの本でLinuxの話しを読んで、「凄いなぁ」と漠然と感じていたのが三年くらい前、今やあの頃とは比較にならない程LinuxやOSSにお世話になっている自分がいます。
「リーナスってどんな人なんだろうなぁ？」という漠然とした興味もあり、せっかくの生リーナスが見れるチャンスとあって、こりゃ参加するしかないだろう！となったわけです。
講演はもちろん英語だったのですが、同時通訳を聴くためのイヤホンが配られました。
けどワタシは「英語のトレーニングだ！」と同時通訳を聞くのを拒否w
結局、それが仇となり四割程しか聞き取れませんでしたwww
まぁ、部分部分大事な単語は聞き取れているし、色々な書籍でLinuxの話しは読んでいるので、どういう事を話しているのかは大方想像はついたので良しとします(笑)
その後、Rubyのまつもとさん、Wikinomicsの著者のAnthony Williams氏と講演を聞きここで撤収。
まぁ、Linuxについてや、リーナスの過去のインタビューに関して、またRubyやまつもとさんに関して色々な書籍やウェブでこれまでも沢山読んできたし、まつもとさんはブログを読んでいるし、Wikinomicsは読んであったので、今日の講演で何か得に真新しい発見というのは見つけられなかったのだけど、まぁ生の声が聞けた貴重な機会だったし良しとします＾＾
一つ、リーナスの発言で一番頭に残った事を挙げるなら、「興味を持ってコミット出来る事に、１日10時間、10年間コミットし続けるんだ、あるとするならそれが成功の秘訣かな」といった旨の発言。
これ、相当好きな事だとしても10h/d×10年って相当キツいぜ。。
俺の場合ギターだって、最長で高校生の夏休みに毎日最低五時間って決めて練習してたのがmaxですわ。。
これまでに無いくらい多くのある一定以上の生活水準にある世界中の人達が、コンピュータとウェブを初めとするテクノロジーで興味のある事をどんどん自分の手で形に出来るようになった現在、「自分」という存在がユニークな存在になるためにはそれくらいのコミットが必要なんだろうな。。
いつかそういう境地に達せられたらいいな、分野はなんであれ。
アンテナは張り続けて、動き続けるバイタリティも持ち続けなきゃな、と思ったのです。
あとそういえば、受付付近に、これまたブログをチェックさせていただいているミラクルリナックス社の吉岡ひろたかさんが普通に立っててちょっとドキっとしたw
そんな１日でした〜
どうも、最近はバイト先で自社製品のiPhone対応に関する作業をやっていますながたかです！
この度、我がバイト先の主力製品でもiPhone用のページを作成する事になったようです。
で、そのためにデザイナーさんが作ってくれたテンプレートを従来のモバイル用レイアウトに代わり適用していく作業をしたりしています。
その作業を始めて最初に学んだのですが、クライアント毎にUserAgentというものが決まっていて、それを利用して、サービスの提供者はクライアントが何であるかを判別しているんですね。
iPhoneのユーザエージェントを調べ、それによって表示するページを変えるようにコードを変えたりといった事をやっています。
けれど、その仕事をワタシに頼んだ社員さんとは別の社員さんから仕事をチョイチョイ振られたためiPhone対応は未だあまり進まず(笑)
仕事を振られるのは嬉しいのですが、ちょっと今はiPhone対応に集中したいかも...
ちなみに、ワタシはiPhoneユーザではないのでどうやってテストをしているかというと、IBBDemoというwin用iPhoneブラウザシュミレーター！
http://labs.blackbaud.com/NetCommunity/article?artid=662これを起動していると、ワタシの後ろを通り過ぎる社員さんから「おぉ〜なにこれ」とか反応されたりしてちょっと気分がいいです(笑)なんか自分が凄いモノを扱っているようなねw
あぁ、これいじってたら自分もiPhone欲しくなってきた。。
今日は池袋のジュンク堂書店まで、「ソフトウェアアーキテクトが知るべき97のこと」という本の刊行記念トークセッションを聞きに行ってきました！
いつもチェックしているはてなの伊藤直也さんや、アプレッソの小野和俊さんのブログで知り申し込みました。(このイベントのページで鈴木さんのブログを知ったので、以降チェックさせていただきます！)
この本は購入していないので、特に本に関して何も知らずにいったのですが、全然そんな事は関係無くお三方の経験ベースのとても貴重な話しを楽しめました＾＾
なおやさんのお話で印象に残ったのは、二つの勉強をバランス良くしましょうという趣旨のお話。
もっとザックリ言うと、サイエンスとエンジニアリングという事ですかね。
エンジニアは、「ココをこうするとちょっとパフォーマンスが良くなる」とか、「こういう使い方をすると便利」とか、そういったより日常の開発に密着したエンジニアリングの部分に関するノウハウや情報を日々膨大な量学んで行くわけですね。
そして、それだけでもなんとなく業務はまわせてしまうし、それなりに自分で色々と開発が出来るようになると。
ただ、それだけだと、どこかでとても難しくてチャレンジングな問題にぶつかったときに、その壁を突破する事が出来ない。
そこでのブレイクスルーを生むのがコンピュータサイエンスの専門書や論文から得られる理論など陳腐化しづらい本質的な知識ベースだというお話。
日々の業務に必要となる技術情報にしか触れずに日々過ごすのではなくて、重厚な理論ともしっかり格闘していかなきゃなと思いました。
自分の現状に当てはめてみると、バイトで必要になった技術の習得に100の時間を使うのではなくて、20くらいはしっかり論文を読んだりしっかりとコンピュータサイエンスと向き合いましょう、というトコロでしょうか。
どうしても、やっぱり論文を読んだり、専門書で理論やアルゴリズムなんかを学のって、バイト先で色々と調べながら手を動かして開発をしているのに比べて、「自分が何かを出来るようになった達成感」みたいなものの即効性が少ないんですよね。
仕事を振られ、それを実現するために必要な技術をネットで調べ実際に自分で手を動かして実装出来た時ってなんだか自分が一歩前進した感覚があるのですが、論文を読んだりしている時って、やはり目の前に成果物が出来るわけではないので前進感が少ないのです。
なので、ともすると前者ばかりやってしまいがちな自分がいます。
直也さんの話しは、こういう自分に対する良い教訓になりそうです。
小野さんの話しで一つ頭から離れなくなった事は
「三つの問題をつぶす事に追われていると、実はそれらの原因が一つの根本的な問題にある事を見落とし、それを解決する事に目が向かなくなる事がある。それを避けるためにも、全体を俯瞰する役目の人が必要」という事。
これってなんだか凄く自分の頭の中に残りました。
「トラブルだ〜」→「火消しだ〜！」→「収まったぁ、あ〜良かった＾＾」
「またトラブルだ〜」→「火消しだ〜！もっと火消し要員を！！」→「なんとか収まった、やれやれ＾＾」
「よし、火消し要員を増員しよう！！」
っていう対処をしてしまうともう思考停止のままガンガン走り続けて、完全に体力勝負みたいになってしまいますよね。
ここで考えるべきは、「トラブルが起きてる原因ってなに？」なわけで、目の前のトラブルはもちろん解決しなきゃなんだけど、その一つ上のレイヤに目を向けてみることがとても大切。
わかっちゃいるけど中々出来ないかなと思います。
目の前の問題を解決してホッとして思考停止してしまいそうな自分です。
これからそういう意識を持ってバイトを、そして来年四月以降はシゴトが出来たらなと思います。
(あと、小野さんがイケメンでビックりしたw)
そして、鈴木さんのお話。
鈴木さんはSIerに勤めているという事で、おそらく四月以降の自分が体験するであろう様々な事を体験されている先輩かな。
その鈴木さんから発せられた言葉は、自分もそういう気持ちでシゴトが出来たらなと思う言葉でした。
「システムではなくコミュニケーションをデザインする」
システムというのは、そのシステムを使うに至った理由があり、それを使ったらユーザがどのように幸せになり、そこにどういうコンテキストが生まれるのか、そこを押さえていないと、システムの意義というのは100%発揮されないんだなと。
システムの「ユーザ」ではなく、コミュニケーターが存在しているのだよ、と。
ここで直也さんが発した言葉もとても印象的でした。
「エンジニア側からすれば3秒で実装出来る事柄でも、そこで発生し得るコミュニティへの影響という事を考えると慎重になります」といった事を言っていたのがとても印象的でした。
自分達が作ったシステムが、どういう影響を及ぼすのか、追加した/削除したたった一つのリンクがそのコミュニティの住民に与える影響って何か？
そう考えると、ITって結局人間だなって思いました。
なんか、トークを聞いていて自分のモチベーションが凄く上がるのを感じました。
三人のように、技術と、一歩引いて全体を俯瞰する目。その両方を持ち合わせたエンジニアになりたいな。
※トーク終了後にサイン会があったのですが、自分はあまりお金が無かったので(笑)そそくさと退場...
本の内容自体はウェブで読めるので(日本人の方々の文は読めませんが...ま、自分は今日資料として配布された三人の分で一先ず十分ですw)
http://97-things.near-time.net/wiki/97-things-every-software-architect-should-know-the-book著者名明記の上での原稿使用可、という事なので、直也さんの一節を紹介してこのエントリーを終わります。
プログラミング作業の80%、いや90%は経験やノウハウが要求される作業です。ですから、手段的な知識の量が、効率的に開発を進めるための助けになります。この90%をいかに積み重ねるかで、ユーザにとってのソフトウェアの魅力が決まります。しかし、残り10%では本質的な知識が要求されます。そして、その10%で何をしたかで、ソフトウェアの革新性が決まってしまいます。
