チャーハンまだ？ あなたが中華料理屋の料理人になったとします。まだ料理は初めて、これから学びます。 さて、少しだけ学んだので、チャーハンを作ってお客さんに食べてもらいます。もちろん、お金をもらっています。まだあんまりおいしくはないです。評判も悪くクレームも来ます。 チャーハン自体に画期的工夫が必要とか、お客さんの好みが変わったとかではなく、単純にまだ普通のチャーハンすら、まともに作れてないだけです。先輩が作ればちゃんと喜んでもらえます。 「色々な料理を作ったほうが良いから、ショートケーキを作る練習しよう」 ... ... 「いや、お前チャーハン作れよ」 「いやいや、ショートケーキを作ることで、また違った世界の味覚や調理方法を学べて、別角度からチャーハンを見つめ直すことができて、チャーハンがおいしくなるかもしれないし、画期的工夫でチャーハンがおいしくなるかも!?」 「いや、まずはチャーハン作

いきなり便利！ 「若い人がいきなり便利なものを使い始めるとダメになる」 ということがよく言われます。ほとんどの人が確かにそうだと考えるでしょう。 実は自分はそうは考えません。 便利なものをいきなり使い始めてください と言い切ります。 心配なのは間違った使い方をすることだけ。 そこはしっかりフォローした上で使ってもらう。 便利に慣れたい なぜそう考えるのか。 逆に便利なものを知らずに育つと、それが便利であることを理解できなくなるから。 便利であると気付かなくなるし、便利であるとわかっても、いざ手を動かそうとすると二の足を踏むことがある。 不便なものから使い始めると、「手」も「思考」も不便なものに合わせた形で凝り固まってしまい、そして人はそこが居心地の良いものと捉えてしまう。要は「クセ」がついちゃったと。 その状態でいざ便利なものを目の前にしたとき... 便利であるがゆえにどうしても必要な習得

ズバリ 答えを覚えることよりも、答えを導くためのプロセスを学んで欲しい これが自分が若い人に伝えたいこと 前回の「知識を得るためのプロセスを」と似てます。 -> http://d.hatena.ne.jp/jflute/20110528/1306566854 つまり、どの領域でも同じ話なんですね。 答えを知っていれば、確かにあっという間に問題は解決します。でも、問題というのは千差万別、把握できないほど多く存在します。そもそも人が覚えられることに限度はあるわけです。 同じ問題でも姿を変えて目の前に現れることがあります。せっかく答えを知っていたはずなのに、その答えを思い付けない、よくあることです。 答えよりデバッグの手段を エラーを解決する答えを知ることよりも、デバッグの手順、デバッグするための手段を身につけましょう。 // デバッグ手順(スタックトレース重要) | jfluteの日記 htt

いまとむかし、比べると、 ずいぶんと覚えることが多くなった。 プログラマーのできることは少なく、 ただひたすらプログラミングをすることが多かった。 いまもプログラミングはたくさんするが、 多くのことをあらかじめ知らなければなかなか前に進めない。 高度になった分、その背景の概念を捉えないといけない。 漠然とWebサービスの開発を考えてみても、 Java, DB, JavaScript, HTML, CSS... 一つ一つがとても深いのに、 求められるのはこれらのコラボレーション。 「...さえ勉強したらいいよ」と言うことはできない。 「...から勉強したらいいよ」と言うこともできない。 好きなものから勉強したらいいよと言いつつも、 求められる実務がそれと一致はなかなかしない。 また、新人はそのスキルからしてどうしても、 つまみ食いのような仕事になりがちである。 それはそれで実践力と応用力が鍛

焦りストーリー 焦りマクラー「Sが動かない！(or Sを実現したい)」 jflute「ふむ、したらそれってもともとは...(質問しようと)」 焦りマクラー「Aで動きますかね？(質問を遮る)」 jflute「いやぁ今のところそう言い切れないような」 jflute (ふむ、例外見ると落ちた元ネタはこうか) 焦りマクラー「じゃあ、Bで動きますかね？」 jflute「Bは動きそうだけど一概にそれでいいかは...」 jflute (ふむ、業務的にはこういうことが求められてて) 焦りマクラー「Cならいいんじゃ!? Cってどうしたらできます？」 jflute「本当にC前提で話を進めちゃっていいの？」 jflute (ふむ、この状況からするとBに加えてDが必要そうだな) 実は... ある程度の分析をするまで、 解決方法には興味がありません。 (No interesting about solution u

ここでのアーキテクトとは？ こういうのは明確な定義はない言葉ですが、 ここでは割り切った定義をしてしまいます。 サービス開発・システム開発の現場にて、 ディベロッパーの開発や運用効率を向上、 アプリが抱える技術課題の解決のために、 実装の開発環境やフレームワークに加え、 現場適合な共通部品に実装ポリシーなど、 アーキテクチャをデザインする人のこと。 ちょっと、大それた言葉かもしれませんが、 「実装現場のデザイナー」と呼びたいなと。 ここでは、ちょっと現場寄りなアーキテクトを定義しています。 一方で先進的なアーキテクト、最先端の高レベルな技術に長け、 非常に難しい技術的課題を先進的な方法で解決する人もいます。 この場合は、アーキテクトよりギークという言葉が似合うかも。 jfluteは、残念ながら後者にはまっったく及ばないので、 今日の内容は、ちょっと現場寄りのお話になるでしょう。 「リーンス

エンジニアの採用ジレンマ エンジニアの採用というのは難しいものです。 エンジニアがエンジニアを採用するのも難しく、エンジニアじゃない人がエンジニアを採用するのはさらに難しいと考える人もいるでしょう。 そこで頼られるのが、エンジニアの特定の技術に対する経験です。 Java言語を使っている現場であれば、Java言語を使った開発を何年やっているか？ まあ当然の自然なこととも言えます。 今日の焦点は... 「うちで使っているフレームワークの経験が三年あるらしい、これは良い人材では!?」 というような採用基準です。 ※ここでは、仕組みを構築するアーキテクトではなく「業務画面を開発するディベロッパー」を想定しています。とはいえ程度の問題で、どちらでも通じる話なんですけどね。 Emptyなんとかフレームワーク経験三年 人によって変わるので一概に言えず、断言できないからこそ声を上げづらいのですが、jflu

ホワイトボード大事 もともとホワイトボードが現場で大事なのはわかっていましたが、ここ最近若い人と触れ合ったり、色々な現場に回るようになってさらに実感しました。 なぜ大事なのか... 裏紙が消えた 昔々、パソコンのない時代...とまでなると自分もよくわからないので、パソコンはあってもパソコンの中であまり便利なことができなかった時代、デスクの周りには紙があふれていました。 そもそもメモを取るためのノートやメモ紙、表や文章などを印刷して見終わった紙 (裏紙) 当然ボールペンなどもすぐ手に取れる場所にあって、ちょっと隣の人とやり取りすることになれば、それらの紙に何かしら図などを書いてスムーズにやり取りをしていました。 時代は変わりました。 パソコンが優秀になって、パソコンの中でメモやらなんやらなんでもできるようになってきて、ノートやメモなどもパソコンの中でやるように。印刷して情報を見るってことも少

「正式会員で生年月日のある会員を除きたい」 っていう条件をCBで書きたいって言われて、 おいしいランチから帰ってきた途端の突然の質問で、 一瞬「おやっ!?」って思ったけど、 ホワイトボードでモデルを書いてみたら明らか。 実際描いたのはもちょい絵的だけど、まあこんな感じ： o 正式会員、生年月日あり // これを除外 o 正式会員、生年月日なし o 他の会員、生年月日あり o 他の会員、生年月日なし それって要は、 「正式会員以外か、生年月日のない会員」 ってことじゃん。 プログラマーならプログラムちっくに描く方がピンと くるかもね。これでもいい。これもモデルの一つ。 !(正式会員 && 生年月日 != null) => !正式会員 || 生年月日 == null 何も絵っぽいものがモデルとは限らない。 頭の中の思考を表現できればなんだっていい。 表現することで、思考に土台ができて考えがまと

知ることとやることは違う よく言われること。知っててもやってみるとなかなかできないもの。 そう、「知ることとやることは違う」違うこと... 「知識と経験は違う」これもよく言われること。 知識豊富な人と経験豊富な人をイコールで結ぶことはできないのは、言うまでもなく皆が知っていること。 「ミング」って...プログラミング (Programming) のミング。 プログラムを知ることとか、プログラムの知識を得ることではなく、プログラムを書くこと、一行一行書いていく行為。(ミングは、-ing形の部分に着目した造語です) プログラムに求められていることを理解し、その限られた時間を書く行為に適切に割り振り、オーダーメイドな「役に立つもの」に仕上げる。書いた後にもそれが生き続けることを念頭に入れて。 プログラマーは成長するために勉強をします。何を勉強するか？文法を覚える？APIを覚える？概念を覚える？シ

しろくじちゅー？ 「しろくじちゅう、プログラミング」 ではなく、 「しろくじちゅープログラミング」 です。 どういうプログラミングかって？ まあ...四六時中、プログラミングするんです。 妄想の分離独立 プログラミングって、文字を入力する作業と考える作業の繰り返しです。 考えては文字を入力して、文字を入力しては考える。 「考えるためにも文字を入力する」 ということもあるので、なかなか二つは分離した作業とは言えない。前もって考えてプログラミングの道のりを練っておくのは大事ですが(それが詳細設計書!?)、事前にいくら考えても書かないとわからないこと、やっぱりあります。 とはいえ、プログラミングの中をもっと細かくみていけば、じっくり考える必要がある場面もあります。 ただ、やっぱりそのときもコード(プログラム)を見ながら考える必要があったりして、パソコンの前にじっくり座っていないといけない...!

young「これ ConditionBean でどうやります？」 jflute「まあ、こうすればできるけど、どうしたの？」 young「これをこうしなければならなくって...」 jflute「ほう、でもなんでそうしないといけないの？」 young「それはこれがこういうことになってるから...」 jflute「ほう、なんでそんな風になってるの？」 young「それはこういう問題があるから...」 jflute「...」 young「...」 jflute「それ、こうしちゃえばいいね」 young「!?」 数え切れないほどのよくあるやりとりです。 結局、ConditionBeanのそのやり方は要らなかったし、 そのまえのやらなきゃいけないことも要らなかったし、 そのまえにそんな風になってる必要もなかったし。 もうDBFluteは完全に無関係だったり。 Seasar や DBFlute の ML

とある休みに、震災の影響で営業を中断していて ついこないだ再開したばかりの東京ディズニーシーに 行ってきました。 そもそも自分は家族とディズニーシーによく行きます。 -> ディズニーシーでベジライフ | jfluteの日記 そして、地震当日もディズニーシーにいました。 -> ディズニーシーで揺れた日 その一 | jfluteの日記 久しぶりのディズニーシー、色々と心配はありましたが、 十周年イベントは一旦延期ということになったようですが、 以前のような活気が戻っていました。 もともとパーク内は地震の影響はほぼありませんでしたから、 そういう面では難なく復活というところでしょうか。 (パークの外に出ると、歩道とか傷跡がちらほら見えますが) 節電の取り組み、実際に色々なところで見受けられました。 -> ディズニーリゾートの節電の取り組み 自家発電設備もともと持っていたんですね、そして、 さらに

今回の地震のとき、自分はディズニーシーにいました。 いつものように、東京で車を気にせず安心して楽しく 散歩できるところ、という感じでこの日も休みをとって シーを楽しんでいました。 結果的には、とても運が良かったと心の底から感じます。 家に帰ってからマスコミ情報をみると本当に 悲惨な状況が伺い知れます。それに比べればなんてことは ないことではありましたが、でも一つ間違えれば命を 落とす可能性はあったし、その後の生活に支障を与える 怪我や病気の可能性もあったし、これを書いてる最中でも 余震続く状況、またいつ似たような状況がやってくるとも 思えないので、自分の経験とそこから学んだことを しっかりまとめたいと思います。 大事なのは今後。 強い余震の可能性が非常に高いと予想される中、 その「今後」にはすごく近い未来も含まれますし、 その後の未来もあります。 朝から行っていたので、 午前中にハンガース

さて、ついこないだ元旦に、 DBFluteも1.0.1がリリースされましたが... -> DBFlute-1.0.1 Released @DisneySea ディズニーシーからリリースって、 違和感ありすぎでしょ！ って思われた方は、正常な感覚の持ち主です。 10万人とか規模の来場者数だと思われますが、 そんなことしてる人はまずいないでしょう。 まっ、ネタもありつつ本気もありつつ、 今日はそんなお話。 自分はわりと休日に休めないタイプでして、 仕事してるときは必死でつらいのを耐えて、 余暇はそんなことをすっかり忘れてリフレッシュ！ としたいところですが、仕事がわりと頭から離れない。 よくあるサラリーマンの悩みですかね。 ましてや、まだまだ未熟な自分が休んでると、 成長の「歩み」が止まっているかのようななんとも 言いがたいプレッシャー!? 恐怖感!? が頭の片隅に。 そんな状態で余暇を過ごす

ひさしぶりの実装風景にっき。 よっしゃー！ 難度高い壁を乗り越えたー！ DBFluteのDreamCruiseのケース対応。 あまりに複雑でレアなケース、でもバグっちゃだめ。 こういう、職人的な実装が求められるときは、 実装したいところで実装したい のですよね。 最高の集中力を出すために。 こかげに入るととっても気持ちよく涼しくって、 プログラミングに集中できました。 ... ... とはいっても、書いた行数はほんのわずか。 考える時間が50倍以上みたいな(^^

プライベートアプレンティス つい最近、 友人がプライベート運営してるサービスの開発に、 勉強のために若い方がお手伝い参加すると聞いて、 とっても良いことだなぁと思いまして。 色々な現場でよく言ってたんです。 「サービスを作りたい！」 って方は多いですが、 なかなか実力もきっかけもないときは、 開発環境の準備からいきなり手間取ったり、 そもそもの企画や画面設計やDB設計もあったり、 アーキテクチャ構築やプログラミングも 試行錯誤しながら...なんて感じで、 なかなか先に進みません。 その過程もすべて含めて楽しめるならいいですが、 あまりに期間が長いと人間だんだんモチベーションも減り、 しばらく止まってしまって挫折しちゃったり。 まだやり切る実力がないときに突っ込んでも、 なかなか効率も良くないから... 身の回りでそういうことをやっている先輩がいるなら、 一画面でも二画面でもいいから手伝って

わりとシンプルだった気がするんだけど... みな、色々な将来像を持って、エンジニアの世界に飛び込んできています。 jfluteの頃...まあ、jfluteがいい加減な人だっただけかもですが、「SEになるかプログラマーになるか」って、それぐらいしか見えてなくて、「ひたすらプログラミングを極めていくぞー」みたいな感覚しかありませんでした。 実際には、DBもインフラも学ばなきゃだし、仕事スキルも向上させるのは当然ではありましたが、HTMLやCSS、JavaScriptなんてあまりないし、デザインのことなんか考えないし、iPhoneアプリもないから「Swift勉強しなきゃ！」もない。そもそも使えるプログラミング言語が少なかった。マーケティングやプロモーションって言葉を聞いても...「お、音楽業界!?」ってくらいなもんでした。お金の流れなんて、そもそも単価とか見積もりの詳細とか、会社は若手にはなかな

定番レビュー getという名前のついたメソッドで、検索処理を書いているのをよく見かけます。 昔からできるだけ直してもらうように提案してきました。強いこだわりがあればしょうがないですが... o 単純に思いつかなかったから o 別段深く考えずにメソッド名を付けていただけ とかであれば、ちょっと違う名前にして欲しいなと。 get...は軽いイメージ 少なくとも Java で get...() というと、特別なイメージが刷り込まれているもので、 内部で持っているインスタンス変数をただ戻すだけのメソッド というイメージあります。 厳密にそうでないにしても... 少なくとも処理としては軽いイメージ でも、それで検索しちゃっていると... for (SeaBean bean : beanList) { ...いろいろな処理 Integer memberId = bean.getMemberId();

ちょっとした行動の違い 新しく現場に入ってきた方の、技術的なオリエンテーションを担当しています。技術的って言っても、そこに密接な「仕事の仕方」的な話もします。 やはり、ポイントとしては、 「SIとスタートアップ」 要は... SIerと事業会社でのプログラミング仕事するときのちょっとした行動の違い で、今まで何度も何度も話をしてきたので、さすがにちょっとブログにまとめようかと。 Lastaの資料がちょうど とはいっても、ここにつらつら書くの大変なので、まずはこちらの資料をご紹介。 LastaFluteの誕生 | Speaker Deck こちらの「A」の章をごらんください。 ケースバイケースではありますが、特徴をポイントごとにまとめてみました。 まあ、こういった特徴の違いがあるってことは、その分、プログラマーの行動にも、ちょっと影響があるわけで。 ここって、巷でよく話題になることはあります