意外と忘れがちな優秀なプログラマーになるための10のコツ - jfluteの日記
月並みなものは、ここでは話題にしません。よく「忘れがち」なものにフォーカスします。 コツ1. 土日という概念を捨てる 土日は、土日ではなく、たまたま仕事に拘束されない平日です。自分を高めるトレーニングに時間を使えます。 とはいえ、普段の生活もありますから、土日を全部使うのはさすがに厳しいかもですね。なので「半分だけ」とかが現実的でしょう。 半分なので24時間。土曜12時間、日曜12時間。もしくは、土曜16時間、日曜8時間。これなら日曜日はけっこう生活に時間を費やせます。 常にパソコンの前じゃなくても良いでしょう。出かけながらプログラミングしたっていいです。トレーニングになっていればいいので、書くプログラミングだけとは限りません(コツ6を参照)。 ... 「そっか、あのプライベートの用事を削れば、あの機能その日にうちに実装できるかも、よし！」 常に "削れるプライベートを探す" 習慣を。 コ
ワケもなく!?そろそろバージョンアップしようぜ - jfluteの日記
どういうワケ？ 最近、こんなツイートをしました。 フレームワーク周り、仕組み周りで挙動がなんか変だな？って思ったら、まず最新版で試してみましょうがお約束。古いバージョンでああじゃないかこうじゃないかってやっても時間の無駄になる可能性が大。実際にはアップできないって事情があっても、最新版との比較で回避策見つけるかもだし。 https://twitter.com/jflute/status/1046728446540300288 まあ、あれこれ相談されて分析して... 「結局、最新にしたらOKだった」そんなことよくあります。(まあ自分でも時にあります) 多少はしょうがないにしても、あまりにこういうのが多く、しかも長い時間ハマっているのを見ると、最初っから最新だったら良かったのに...ってどうしても思ってしまいます。 (もちろん、ハマること自体も改善が必要ですが) 切羽詰まってバージョンアップ
別にパソコンがなくてもプログラミングはできるよ - jfluteの日記
書く時間と考える時間 o 仕事を早く終わりにして帰りたい o スキルアップのためにプログラミングたくさんやりたい o オープンソース活動のための時間を確保したい こういう感じの様々な悩みがあるかと思いますが、 ズバリ！ 書く時間と考える時間を分離する をオススメします。 これができれば、通勤の電車でも、 用事があって歩いているときでも、 ご飯を食べているときでも、 お風呂を入っているときでも、 横になって休憩しているときでも、 ストレッチしているときでも、 ショー待ちしているときでも、 プログラミングができて捗ります。 書いて考えて書いての繰り返し 月並みですが、プログラミングは、ただひたすら書くだけの作業ではありません。 今の時代のプログラミングであればなおさら、プログラミング言語やフレームワークの進化により、書く量に対して考える量が増えていると思います。 もちろん、書きながらじゃないと
仲の良いチームじゃないと成り立たない技術がある - jfluteの日記
タイトルに迷いました。 技術？技術課題？問題解決？技術方式？少し広い意味に捉えてください。 jfluteの10年以上の、様々な現場での経験を元にしています。昔も今も全部振り返ってみました。 かぶストーリー かぶを収穫します！ resort「かぶを収穫しますよー」 sea「はーい」 land「はーい」 piari「はーい」 resort「seaさんはこのエリア、landさんはこのエリア...」 sea「はーい」 land「はーい」 piari「はーい」 resort (seaさん、landさん、piariさん、みんな仲悪いんだよねぇ。。。) sea「収穫できましたー」 land「収穫できましたー」 piari「収穫できましたー」 resort「よっし！」 収穫量が増えてきました resort「かぶを収穫しますよー」 sea「はーい」 land「はーい」 piari「はーい」 resort「か
サービス開発者は、それ必要？いつ必要？スキルが求められる - jfluteの日記
サービス開発でのアンチパターン ビジネスサイド「D という機能が欲しいです」 エンジニア「じゃあ実装します」 (その後...) 通りすがり「なんで D を実装してるの？」 エンジニア「"ビジネスサイドさん" が欲しいって言ったから」 通りすがり「なんで D をいま実装してるの？」 エンジニア「すぐ欲しいって言うからすぐ実装しないと」 ... ん？これがなんでアンチパターン？と思う人もいるかもしれませんね。 "ビジネスサイドさん" の言うことを、よく聞いている真面目なエンジニアなので、良さそうにも見えるかもです。まあ確かに、できないできないしか言わない人よりは良いかも!? 解決方法を探れるのはエンジニア こないだのブログがちょっとヒントです。 // 質問のコツその一: なんでその質問してるのか？も伝えよう http://d.hatena.ne.jp/jflute/20170611/askin
技術的負債の返済プロジェクトが失敗する 11 のワケ - jfluteの日記
ワケ一覧 序の口: フレームワークだけが負債だと思ってる 序二段: ビジネスサイドに理解してもらう努力がない 三段目: 技術で遊び過ぎてしまう 幕下: 太り過ぎアーキテクチャ 十両: 過去に目もくれず、現状だって見ない 前頭: 技術に詳しいだけでアーキテクト 小結: アーキテクトの知識と覚悟が足りない 関脇: スパンが長く、モチベーションが続かない かど番大関: スパンが長く、人の入れ替えでチグハグ 大関: アーキテクチャデザインはどこへ？ 横綱: 実は人間的負債だった 序の口: フレームワークだけが負債だと思ってる みんな、フレームワークが大好き。とはいえ、さすがにみんな、「フレームワークが古いことだけが負債」だなんて思ってないはずだが...なのに多くの人が、あたかもそのような振舞いと判断をしてしまう。潜在意識の Big Issue だから？ o 信用できないテストデータ も負債 o 現
フレームワーク選び、現場フィットレイヤを忘れずに - jfluteの日記
忘れてると... 既存のシステムがあるとします。だいぶコードもぐちゃぐちゃしてきて、今のビジネス要求に耐えられない。フレームワークも刷新したい。 偉い人「リプレイスします！(英断)」 現場誰か「さて何を使おう？」 他の誰か「"A" が良いのでは？」 現場誰か「じゃあ "A" にしよう。」 他の誰か「じゃあ "A" で画面作り始めますね」 この開発で発生するジレンマが想像できます。 ... 新卒プログラマ 「既存システムにこういうクラスあるんですけど "A" には？」 先輩アーキテクト 「いやぁ、そんな独自的なものはさすがにないよね」 新卒プログラマ 「ないと困るんですけど...」 先輩アーキテクト 「あー、わかった作るね、他の仕事あるから来週まで待って」 新卒プログラマ 「ぼくの進捗が進まないので明日まででお願いします」 先輩アーキテクト 「いやぁ、俺は俺で作らないといけないものがあって.
メンテ不能の強者、引数リモコンパターン - jfluteの日記
Let's read! さあ、いきなり、コードを見てみてください。 public void index() { // what do you select? ... = logic.selectNandemoMember(null, "S", null , false, true, false, CDef.MemberStatus.Formalized , true, false, true, true); } Action, Controller, Service相当のクラスが、そのLogicのメソッドを呼んでいると思ってください。 こういうメソッド見たことありませんか？読みやすいですか？ さて、Logic側はこうなっています。(省略してますけど、もっとデカくなります) public List<Member> selectNandemoMember(Integer memberId ,
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
