タグ

ブックマーク / irof.hateblo.jp (43)

  • IDEに何を期待してどう使おうか - 日々常々

    先日オンラインで行われたJJUGのJava生誕25周年 記念イベント 5/23(土) 開催で話させていただきました。 Java25周年おめでとうございますですね。もうJavaより若い開発者さんも結構おられることでしょう。これ会場で「Javaより若い人ー」とかやったら、結果がどっちでも微妙な空気になりそうですね。オフラインだとうっかりやっちゃった気がしないでもないので、オンラインでよかった! さて、タイトルは「IDE起点で2020年代の開発環境を眺めてみる」です。 スライド 動画もあったりする。自分の動画ってあまりみたくない 話したつもりのこと (……を書いてるつもりだけれど、話してないことも混じってるかもしれない。) 一口に「Javaを使ったアプリケーションの開発環境」と言っても、実際は様々な道具を使用します。 とは言え、我々開発者の仕事は「道具をうまく使う」ではありません。 道具なんてど

    IDEに何を期待してどう使おうか - 日々常々
  • 経験年数で何がわかるか - 日々常々

    経験年数が問われることはしばしばあります。 私も聞かれたり聞いたりしたことはあるけれど、それで何かがわかったことはありません。他の話のきっかけに使うのがせいぜいです。 たとえばJava経験15年とか言われれば「Java5が出た前後か、この時期をどう過ごしたか聞いてみようかな」なんて思ったりします。 Java5はジェネリクスやenumなど、Javaにとっての一大転換期です。とはいえこの時期に新人だったとすると、社会人として精一杯で言語のバージョンに意識が向いていなかったかもしれません。 とはいえ次の転換期であるJava8の話は間違いなくできます。転換期の振る舞いは何を期待していいかを知る重要な手がかりになると思っています。 対して経験年数が5年未満であれば、Javaの転換期の話をしても仕方ありません。それよりも言語の選択肢が増えている昨今ですから、他の言語など横に広げて聞いた方が実りのある話

    経験年数で何がわかるか - 日々常々
    alcus
    alcus 2020/06/09
  • 「良い椅子を買え」と私の選択 - 日々常々

    テスト駆動開発入門に「安い机に良い椅子」と言うパターンがあるので引用します。 背中が痛ければ、良いコードは書けない。だが、えてして組織というものは、チームに10万ドルかけても椅子には1万ドルもかけないものだ。私は安い折りたたみ机にコンピュータを置いているが、椅子は調べた限りで最高の椅子を使っている。 テスト駆動開発 作者:Kent Beck発売日: 2017/10/14メディア: 単行(ソフトカバー) 「良い椅子を買え」はTwitterでも最近のリモートワークの文脈でよく目にするようになりました。まあ「オフィスはいい椅子使っているから……」と言うのもセットなことも多いので、先に挙げた話はこの十数年で改善された組織も少なくないんだろうとは思います。リモートワークを緊急事態で実現できる程度の会社って前提があるので必然かもしれませんが。 私自身、数年前まで現場常駐の仕事が多く、もちろん現場で用

    「良い椅子を買え」と私の選択 - 日々常々
  • 仕事を早く終える小手先芸 - 日々常々

    元々Qiitaに投稿していたものです。 関連書籍としてプロダクティブ・プログラマ。 プロダクティブ・プログラマ -プログラマのための生産性向上術 (THEORY/IN/PRACTICE) 作者:Neal Ford発売日: 2009/04/27メディア: 単行(ソフトカバー) このブログに最近書いたのだと 量に量で対抗しない方法を身につける がちょっと絡む感じ。 以下は 2016-12-12 に書いたのそのままです。 システムエンジニア Advent Calendar 2016の12日目です。ふつうのプログラマとして書かせていただきます。 当初はSIな現場のドロドロした何かしらを書こうと思っていたのですが、 ネタが被ったので 現場で使える小手先芸のお話をしようと思います。単純作業に対する個人技の話です。 なぜ小手先芸なのか SIの現場では膨大な単純作業が待ち構えていることも少なくありません

    仕事を早く終える小手先芸 - 日々常々
  • ドメイン駆動設計に関する何か - 日々常々

    2020-03-13追記: 「ドメイン駆動設計」のハードルを上げる意図はありません。そもそもそんな特殊技能でもないと思っています。「ドメイン駆動設計が合っているか」を測る材料になるかも?くらいの気持ちで読んでいただけると幸いです。 何度目か知りませんがDDDがまたブームを迎えているようで。DDD難民と言う言葉が出た頃を思うと感慨深いですね。実際難民になったわけではないので肌感覚で知らないのが残念なところですが、これはどうでもいい。 DDD、日語ではドメイン駆動設計となりますが、DDDを冠していてもドメインが語られることは少ないようです。 数ある書籍もドメインモデリングの話ではなく、ドメインモデルをいかに実装に落とし込むかにフォーカスしていると感じています。 これはこれで仕方ないと言うか、ドメインの話って広く語れないんですよね。 ドメインは領域で境界があって範囲が限定されています。特定ドメ

    ドメイン駆動設計に関する何か - 日々常々
  • 変わった本棚買ってみた - 日々常々

    棚は棚で別にあるんだけれど(写真の棚を置いているのも棚の上)、部屋にが散らばってたりするんで追加で買おうかなと思いまして。 技術書ってサイズまちまちなので棚に収めにくく、サイズに縛られない棚がいいなーって思ったんです。 Smilemart ブックシェルフ 書棚 棚 卓上 樹木型 オブジェ ラック コンパクト 省スペース ブックスタンド ブックラック 木製 おしゃれ かわいい シンプル  日語説明書付き 60cm 3色選択可能 ベージュ・ダークブラウン・ブラック (ダークブラウン) SmilemartAmazon 元々はこっちの平積みタイプを買おうと思ったのだけど…… オークス ブックタワー ハイタイプ L51DA ダーク オークスAmazon 案外大きいのと案外高かったので、ついつい安くて奇抜だったこちらを買ってしまいました。 雑感 組み立て式。個々の板は小さいので、届い

    変わった本棚買ってみた - 日々常々
    alcus
    alcus 2020/03/05
  • Springアプリケーションのテスト道具 使いどころ、使わないどころ - 日々常々

    2019-12-18の Spring Fest '19 で登壇させてもらいました。みなさまありがとうございました。 資料 Springアプリケーションのテスト道具 使いどころ、使わないどころ です。タイトルの「使わないどころ」って日語的に不自由な感じなんですが、「使うべきでない」とか禁止ではなく、プログラマとして「使わない」と意思を込めてる感を出したくてこうなっています。いい名前が思いつかないので変な名前をつけて、結局最後までいい名前が思いつかなかったパターンです。 なおこのセッションは、2019-07-18にこのブログで書いたどこでモックを使おうかを下敷きにしたものです。 補足もしくは蛇足 49-52ページ: テストで動かせる範囲とモックの例です。例なのでテストしたい対象見極めたら何とでもなると言うのと、それができるアーキテクチャが役立つよねと言う感じ。この一連の図は機能面で、ここで話

    Springアプリケーションのテスト道具 使いどころ、使わないどころ - 日々常々
  • 簡易的な技術記事の取捨選択法 - 日々常々

    見るべきポイント 3点です。 バージョン ソースと実行結果 プロダクトのソースコードや公式ドキュメントへのリンク これらが記載されていない技術記事は、参照する優先順位を下げるのがいいです。 説明 増え続ける一方の技術情報ですが、あまりにあふれすぎて「何を参照すればいいかわからない」といったことに陥りがちです。これはある程度経験を積まれている方でも同様で、調べ物されているのを眺めていると「ガチャっぽい調べ方してるなぁ」と思うことがしばしばあります。 「ガチャっぽい」と言うのは、当たる当たらないの話になっているので、「いつ解決するのか」が全く見当もつかないことを指しています。天井なしのガチャですね。関係ないけど最近のガチャは天井があって親切……よくすり抜けるけど……。 さてそんなわけで技術記事に溢れる昨今、私が言語化できている取捨選択法を書いておこうと思いました。 例えばドメインで「このサイト

    簡易的な技術記事の取捨選択法 - 日々常々
  • モデリングのきほん - 日々常々

    関西Javaエンジニアの会10周年イベント、 KanJava 10th Anniversary Party でモデリングの話をしました。 話したこと モデリングをモデリングしたモデルでモデリングを説明してみました。図の書き方とか言葉の抽出とかそう言う話ではありません。「なんちゃらモデリングをうまくやる方法」みたいなのを期待された方はすみません。でも延長線上にはあると思います。 私の中のモデリングは、対象から使わない情報を削ぎ落とし、対象の特定部分を強調することです。 モデルのモデルを 26ページ で描いてみました。 この図単体では伝わり難いと思いますが、図単独で成立するモデルではなくセッションも含めてのモデルなので雰囲気で見てください。 モデリングのポイントとして 54ページ で「同じことは同じように表現する」と挙げています。「同じことは同じように表現する」は手段で、原則は「情報を維持して

    モデリングのきほん - 日々常々
  • 脱ブランチファースト - 日々常々

    あるいは「プルリクエストをやめてみた」 チーム構成とかにもよるんだろうけど。Gitかつフォークされないプロダクトでの話です。OSSとかは全然話は変わります。 問題とアプローチ (2019-10-25T15:20 追加) 表出している問題と、ここでのアプローチを書いておきます。 ブランチファースト(造語) 「ブランチファースト」はこのエントリでの造語です。コードベースに変更を加える際に「まずブランチを作成する」から始めることを指します。 作業単位でブランチを作成、ブランチでコードを変更してプルリクエスト、レビューを経てメインライン( master ブランチ)に反映までがブランチファーストのスコープになります。 よくあるスタイルだと思いますし、ブランチだけ作成して変更せずプルリクエストを作成する拡張もありますね。 プルリクエストを挟まずにメインラインにマージするものは含みません。 ……名前微妙

    脱ブランチファースト - 日々常々
  • プルリクエストとマージリクエストと。 - 日々常々

    short answer プルリクエストとマージリクエストに違いはありません。 同等の機能が別の呼び方をされているだけです。 名前の由来を考えてみる 名前の由来を考えてみるのも面白いと思うんです。 ここに書いているのは私の予想ですが、大外しはしていないはず。 仮に違ったとしても別に良くて、名前の由来を考えてみることは、名付けのいい訓練になります。なるはず。たぶん。 こんな感じ。たぶんpullは使われてない。 プルリクエスト、通称プルリクは元々GitHubの言葉です。Gitの機能ではありません。 テキストではPRと略されることもあるけど、ピーアールって読むと何を宣伝したいんだろう(Public Relationsとは意味変わっちゃってますね)ってなるからか、発音はプルリクなことが多いと思います。 Gitのpullはfetch+mergeなのだけど、このGitHubでForkしたリポジトリがフ

    プルリクエストとマージリクエストと。 - 日々常々
    alcus
    alcus 2019/10/04
  • finalを付けるのをやめてみた - 日々常々

    Javaの話ね。バージョンは8以降の実質的final(effectively final)があるものとします。7以前は匿名クラス(この呼び方は 匿名クラスとかローカルクラスとか参照)でローカル変数を使うにはfinalが必要なので文脈変わります。 前提の整理 final は色々なところにつけられます。 例えばこんな感じ。 final class FooClass { final Object barField = new Object(); final void bazMethod(final Object quxParameter) { final Object corgeLocalVariable; } } このエントリで対象にするのは変数。フィールド barField 、パラメータ quxParameter、ローカル変数 corgeLocalVariable です。 以下を前提にします

    finalを付けるのをやめてみた - 日々常々
    alcus
    alcus 2019/09/30
  • JUnit 5の拡張機能を完全にマスターしたぃ - 日々常々

    日9/19の関ジャバ'19 9月度でJUnit 5のExtensionの話をしました。 スライド JUnit 5.5.2 のUser Guide を合わせてご参照ください。なお5.3ならoohiraさんの日語訳もあります。とても助かってる。 ちなみに表紙で言及してるBtoWは ゼルダの伝説 ブレス オブ ザ ワイルド - Switch で、ロード画面がこんな感じなのです。 背景 9月度のセッションは、以前の関ジャバにて登壇枠で申し込みいただいたお二人です。 業務システムの概要とその選択肢 / tunemageさん みんなのSelenium:The Road to WebDriver / woosyumeさん 他のイベントでの登壇などから特に心配はないのですが、流石に初登壇の方だけにお任せするのもあれなので私も話すことにしてみました。 Seleniumに絡めてテストの話、と考えてExte

    JUnit 5の拡張機能を完全にマスターしたぃ - 日々常々
    alcus
    alcus 2019/09/20
  • SQLアンチパターンを読んだ - 日々常々

    SQLアンチパターン 作者: Bill Karwin,和田卓人,和田省二,児島修出版社/メーカー: オライリージャパン発売日: 2013/01/26メディア: 大型購入: 9人 クリック: 698回この商品を含むブログ (46件) を見る 積読--; 1冊減ったところで誤差でしかない……。ちなみに2年積んでました(懺悔 感想 「知ってることばっかやなー」 ……パターンなんだから当たり前です。だいたいは普通にやってたら踏まない、はずが、なぜか現場ではよく見る。アンチパターンって引力があるからアンチパターンなので、「なぜか」ではないんですが。 「SQLアンチパターン」って名前ですけど、「データベス論理設計」「データベース物理設計」「クエリ」「アプリケーション開発」の四部構成です。SQLでDMLを想像したなら一部だけで、内容の印象としては前半二部の設計が厚めでした。 でも踏むのもある はい。

    SQLアンチパターンを読んだ - 日々常々
  • ArrayListじゃなくListを使うという話 - 日々常々

    具象型ではなく抽象型で扱え、インタフェースを使え、みたいなお話に対して。 前置き Javaの話。他の言語だと話は変わります。 「こうするのが絶対的に正解」と言うものではありません。私の現在の選択の説明です。明日になったら違うこと言ってるかも。 主な登場人物は掲題の java.util.ArrayList および java.util.List、そして java.util.Collection と java.lang.Iterable です。 こんな世界観。他のインタフェースやクラスもたくさんありますが、この話の筋では無いので触れません。 前提として以下を置いています。 フレームワークやライブラリではなく、一つの業務アプリケーションに閉じた話です。ゆえに不特定多数から使われる型ではなく、影響を与えるコードは全て目が届く範囲にあるものとします。 計算量は別の話です。扱うドメインにもよりますが、

    ArrayListじゃなくListを使うという話 - 日々常々
    alcus
    alcus 2019/08/10
  • DIコンテナのインジェクション方法の使い分けについて - 日々常々

    DIコンテナを使う時にどのインジェクションを使うかって話です。 たぶん誰かがどこかで同じようなことを書いているだろうけれど、気にせず書くよ。 「他の誰かが書いている」なんてのを書かない理由にしてると何も書けなくなるし。 コンテナ DIコンテナのこと。 コンテナ管理 インスタンスのライフサイクルをコンテナが管理していること。雑に言えば、使う側で new しないってこと。 インジェクション Dependency Injectionのこと。 Short Answer コンストラクタインジェクションを使いましょう。使い分けなくていいです。 3種類のインジェクション インジェクションには3種類ありますね。他あっても知らない。 フィールドインジェクション セッターインジェクション コンストラクタインジェクション フィールドインジェクション 一番よく見るかな。 class Hoge { @Inject

    DIコンテナのインジェクション方法の使い分けについて - 日々常々
  • Javaエンジニアからみた最近のJava事情 - 日々常々

    5/9(水) 大正GeekNight Vol.1で話しました。 https://taisho-geek.connpass.com/event/85508/ 4ヶ月前のスライドです。 Javaのサポートについては続報も出てきていますし、思い込みで騒がないのが吉です。 いよいよ今月命のJava11がリリースですね。どうなるかな。

    Javaエンジニアからみた最近のJava事情 - 日々常々
    alcus
    alcus 2018/09/18
  • ベタープログラマ第二部の感想 - 日々常々

    ベタープログラマを読もう - 日々常々 ベタープログラマの第一部を読んだ - 日々常々 第二部「練習することで完璧になる」を読みました。 読んだのは15,16,17,19,22章。15章は16,17章を読んでたら「我々のチームの三つの規則」として触れられてたので。 15章 規則に従って競技する いろんな規則があるけれど「自分達で決めた規則が必要」とあります。規則は自分達のためにあるってやつですね。著者のチームでは以下の3つの規則が挙げられています。 単純に保つ 頭を使いなさい 変わらないものはない これらの規則についてはそれぞれ別の章で語られていて、15章は規則のありかたが書かれています。この章で重要なことは、要点の囲みにも挙げられているこれだと思います。 曖昧で記述されていないチームの「規則」に頼らないでください。暗黙の規則を明示して、コーディングの文化を統制してください。 たまに見るの

    ベタープログラマ第二部の感想 - 日々常々
  • Javaアプリケーションを作るときにまずやってること - 日々常々

    DevLOVE関西で実験的なイベントをさせてもらいました。 devlove-kansai.doorkeeper.jp このイベントのおかげで、自分がアプリケーション作るときに最初にどうしてるかを確認できたので晒してみます。誰かの役に立つかどうかは知らない。あ、Macです。ある程度はWindowsでもいけると思うけど、ある程度だと思う。 なおSTSとかIDEのプロジェクト生成機能を使えば一発で済むことだったりする。宗教上の理由で使わないけど。 やってること 作業ディレクトリを作る ビルドスクリプトを用意する 必要なディレクトリを作る IDEを起動して取り込む テストを書いて実行する コミットする 基的にマウスを触る必要はないです。それぞれの詳細は次の通り。長く見えるかもしれませんが、(IDEAの起動とgradleのjarのダウンロード時間を除けば)全部で30秒くらいです。 作業ディレクトリ

    Javaアプリケーションを作るときにまずやってること - 日々常々
    alcus
    alcus 2018/03/12
  • 「あるエンジニアがプログラムを紡いでいく様を見てみる」ライブコーディング・リプレイ - 日々常々

    あるエンジニアがプログラムを紡いでいく様を見てみるでしたライブコーディングで言ったことや言わなかったことを書いてみます。 意識してるのは「コードをどまんなかに」です。 speakerdeck.com ……あ、このスライドのブログ書き忘れてた。 スライド中の「えらぶ」はだいたいIDEの機能を指します。なのでライブコーディング中に使用したIDEの機能も挙げようと思います。基的にデフォルトのつもりだけど、vimとの兼ね合いで変更してるのもあるので、そこはごめんなさい。あとMacです。今回はメソッド抽出とかクラス間移動とかダイナミックなのがなくて地味だけど、便利な子たちなので使ってあげてください。 リプレイ 今日の公開コーディングはスゴい新鮮だった🎵 コミット後のソースには、どこに悩んだのか、どこにこだわったのかは残らないのですね。 実際のコーディングを見させて頂く事で、気づかされる事が多かっ

    「あるエンジニアがプログラムを紡いでいく様を見てみる」ライブコーディング・リプレイ - 日々常々