意外と忘れがちな優秀なプログラマーになるための10のコツ - jfluteの日記
月並みなものは、ここでは話題にしません。よく「忘れがち」なものにフォーカスします。 コツ1. 土日という概念を捨てる 土日は、土日ではなく、たまたま仕事に拘束されない平日です。自分を高めるトレーニングに時間を使えます。 とはいえ、普段の生活もありますから、土日を全部使うのはさすがに厳しいかもですね。なので「半分だけ」とかが現実的でしょう。 半分なので24時間。土曜12時間、日曜12時間。もしくは、土曜16時間、日曜8時間。これなら日曜日はけっこう生活に時間を費やせます。 常にパソコンの前じゃなくても良いでしょう。出かけながらプログラミングしたっていいです。トレーニングになっていればいいので、書くプログラミングだけとは限りません(コツ6を参照)。 ... 「そっか、あのプライベートの用事を削れば、あの機能その日にうちに実装できるかも、よし！」 常に "削れるプライベートを探す" 習慣を。 コ
まず何より、目の前の道具を使いこなしてください - jfluteの日記
チャーハンまだ？ あなたが中華料理屋の料理人になったとします。まだ料理は初めて、これから学びます。 さて、少しだけ学んだので、チャーハンを作ってお客さんに食べてもらいます。もちろん、お金をもらっています。まだあんまりおいしくはないです。評判も悪くクレームも来ます。 チャーハン自体に画期的工夫が必要とか、お客さんの好みが変わったとかではなく、単純にまだ普通のチャーハンすら、まともに作れてないだけです。先輩が作ればちゃんと喜んでもらえます。 「色々な料理を作ったほうが良いから、ショートケーキを作る練習しよう」 ... ... 「いや、お前チャーハン作れよ」 「いやいや、ショートケーキを作ることで、また違った世界の味覚や調理方法を学べて、別角度からチャーハンを見つめ直すことができて、チャーハンがおいしくなるかもしれないし、画期的工夫でチャーハンがおいしくなるかも!?」 「いや、まずはチャーハン作
驚きのDBFluteフェス2017終わり - jfluteの日記
終わったー どーびーふるーと？ キャストの新卒の方が細工してくれたようです笑 ... 11年経ったDBFlute, 驚きのフェスでした。 (ブログは11/29ですが、フェス自体は11/26です) // DBFluteフェス2017 | Connpass https://connpass.com/event/70648/ ... ... ☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★ まずは、今年も会場を提供してくれました、 ビズリーチさんに感謝。 素敵なガーデンでフェスができることのが幸せです。 ... そして、今回もバーガー支援をしてくださいました、 N2SMさん(Fess, sugayaさん) に感謝。 (金銭的に)個人運営のフェスなのでめちゃありがたいです。 ... そしてそして、 RemoteApi, RemoteApiGen をコントリビュートしてくれました、 U-NEXTさん
成長するかしないかは選べる - jfluteの日記
ただ、選んだだけ できる人は... できる人になったことを選んだだけ。 できない人は... できない人になったことを選んだだけ。 ... 実際に、多くの成長を見てきて、 本当にその通りだった。 単純に、選んだだけだった、選んでないだけだった。 気付いたら年をとっていく 大抵の人は「できる人になりたい」と言って行動しない。 そして、成長するチャンスをどんどん逃して年とっていく。 気付いたら体力も気力もない。 もちろん、様々な都合でそうもいかない例外はあるだろうが、 進む道が選べる人は選んだだけだよ。多くの人が選べる。 能力はあんまり関係ない、 頭がいいとか悪いとかそんなに関係ない、 進む道を「真摯に」選んだだけ 大胆な行動はなに？ ただ、 効率の良い努力をする努力をした人が成功する ... 「こんな仕事したい」 「こんな自分になりたい」 そのために... 行動って何をすればいいんだろう？ …
技術的負債の返済プロジェクトが失敗する 11 のワケ - jfluteの日記
ワケ一覧 序の口: フレームワークだけが負債だと思ってる 序二段: ビジネスサイドに理解してもらう努力がない 三段目: 技術で遊び過ぎてしまう 幕下: 太り過ぎアーキテクチャ 十両: 過去に目もくれず、現状だって見ない 前頭: 技術に詳しいだけでアーキテクト 小結: アーキテクトの知識と覚悟が足りない 関脇: スパンが長く、モチベーションが続かない かど番大関: スパンが長く、人の入れ替えでチグハグ 大関: アーキテクチャデザインはどこへ？ 横綱: 実は人間的負債だった 序の口: フレームワークだけが負債だと思ってる みんな、フレームワークが大好き。とはいえ、さすがにみんな、「フレームワークが古いことだけが負債」だなんて思ってないはずだが...なのに多くの人が、あたかもそのような振舞いと判断をしてしまう。潜在意識の Big Issue だから？ o 信用できないテストデータ も負債 o 現
レビューしやすいコード (Reviewable Code) - jfluteの日記
れびゅーわぶる!? レビューしやすいコード よく、jfluteが現場で掲げるコーディングテーマです。主に、事業会社でのサービス開発における、スタートアップの時期から少し経ってチーム開発し始めた、インクリメンタル開発が続いてきた時に適用します。 色々とたくさんは言わず、とにかくこれだけは心がけよう、とディベロッパーにお願いしていることです。 インクリメンタル開発に大切なこと インクリメンタル開発の現場をデザインする上で、大切にすべきことが大きく二つあります。 ビジネス貢献の向上 もうさすがに言わずと知れたことですが、事業会社ではビジネスとプログラミングが非常に密接です。ディベロッパーもアーキテクトもビジネス貢献を忘れて、的外れなものを作っても自分が苦しむだけです。 スタートアップ＆インクリメンタル開発の特徴がよくわからない方は、こちらの資料がオススメです。 => LastaFlute Fir
破片プログラマーの悲しみ - jfluteの日記
はへん 破片プログラマー 大きなシステムの改修、 巨大に積み上がったプログラムの上での実装、 難度の高い仕事、 ただし破片 巨大な破片 画面を０から 二年、三年、五年と経験を積み、 開発スキルを身に付けたディベロッパー、 だがしかし、 ０から画面を作ってみると... ... あれ!? できない。 画面を０から作ったことがほとんどない。 あったとしても、隣の画面の真似ごとをしてただけ。 考えて０から作ったことがない レールのないところ歩いたことがない。 クラスやメソッド クラスを作る。 どうやって？どういう単位で？ 決められた中でしか作ったことがない。 その決めがないと何もアイディアが浮かばない。 「どこに何を実装するか？」って、 白いキャンパスの上で考えたことがあるかい？ ... メソッドを作る。 どうやって？どういう名前で？ どういう引数と戻り値で？ メソッドの修正はたくさんしてきたが、
エンジニアのモチベーションを下げる方法 - jfluteの日記
モチベーションの高いエンジニア... ガンガン働いてくれそうで、放っておいても安心でしょうか？ 安心してください。 簡単に下げられますよっ！ o 序の口: ディスプレイを小さくする o 序二段: 毎日スーツを着させる o 三段目: 椅子を固くして、机を狭くする o 幕下: 簡単に作れるでしょ？って上から目線で言う o 十両: 打ち合わせ一杯で連続した集中時間を与えない o 前頭: 情報共有しづらい、風通しの悪い現場に o 小結: 引き継ぎなしで人をどんどん入れ替える o 関脇: 背景わきまえず、コード汚い、仕組みひどいと言う o 大関: 仕事を突然終了させて無意味感を与える o 横綱: 本質的でないことに時間を取らせる仕組み 序の口: ディスプレイを小さくする エンジニアの仕事の多くはパソコンの中にあります。そのパソコンの中を覗く唯一の手段はディスプレイです。そんな狭い中で、色々な資料をみ
思考力DBFluteハンズオン - jfluteの日記
「DBFluteハンズオン」と呼ばれるコンテンツがあります。 環境構築から ConditionBean の実装、dfpropの設定からDB変更の実施まで...と、実際に手を動かハンズオン形式で体系的にDBFluteを学べるコンテンツです。DBFluteに必要な要素が一通り揃っていて、これを完遂した人は DBFlute を自由に扱えるかと。 また、DBFluteの大きな特徴の一つである、 「DBFluteを学びつつ、DBのエッセンスが学べる」 ハンズオンでもこれを意識して前面に出しております。 極端な話、DBFluteを使わない人だとしても、これをやるとDB周りの実装レベルがレベルアップ！ そしてまた、Javaのプログラミングが学べるように。 Eclipseの基本、Eclipseのショートカットキー、Eclipseのコード補完、Eclipseの設定... (って、Eclipseばかりがつい先
若い人がいきなり便利なものを...ぜひ使って！ - jfluteの日記
いきなり便利！ 「若い人がいきなり便利なものを使い始めるとダメになる」 ということがよく言われます。ほとんどの人が確かにそうだと考えるでしょう。 実は自分はそうは考えません。 便利なものをいきなり使い始めてください と言い切ります。 心配なのは間違った使い方をすることだけ。 そこはしっかりフォローした上で使ってもらう。 便利に慣れたい なぜそう考えるのか。 逆に便利なものを知らずに育つと、それが便利であることを理解できなくなるから。 便利であると気付かなくなるし、便利であるとわかっても、いざ手を動かそうとすると二の足を踏むことがある。 不便なものから使い始めると、「手」も「思考」も不便なものに合わせた形で凝り固まってしまい、そして人はそこが居心地の良いものと捉えてしまう。要は「クセ」がついちゃったと。 その状態でいざ便利なものを目の前にしたとき... 便利であるがゆえにどうしても必要な習得
デバッグ手順(スタックトレース重要) - jfluteの日記
よくある会話 こないだ久しぶりにある方とお会いして、色々情報交換したのですが、「StackTraceをみないでデバッグし始めてしまう人」はだいぶ少なくなってきたように思っているのですが、まだまだ結構こういうことがあるようです。 X「例外がでてるのですが一時間かけても原因がわからなくて...」 Y「お、じゃあStackTraceは見た？」 X「いやみてないです」 Y「ちょっと見せてみて」 X「これです」 Y「(StackTrace見てすぐに)ああもう原因わかった」 X「...」 Y「...」 ポイントは二つ 大きく二つのポイントがあると考えました。 A. 例外発生時のデバッグ作業が手順化されてない B. スタックトレースの見方がわからない A. 例外発生時のデバッグ作業が手順化されてない 例外が発生したら、まず何をするべきか！？ A-1. 例外クラス名・例外メッセージを読む A-2. スタッ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
