はじめに 社内で提供しているWebAppがFacebookGraphAPIを利用していた。 FacebookGraphAPIにはバージョンの概念があって、3ヶ月周期ぐらいでバージョンが上がっていく。 利用期日が迫ったタイミングでFacebook周りの実装をリファクタリングした。 その際にAPIクライアントを restfb を利用するようにした。 restfb Java製のFacebookGraphAPI用のAPIクライアント。 月次リリースを行なっているようで、更新頻度高め。(2021年06月現在 初期導入したバージョンは 2.25.0　。 その後、保守で 3.15.0 まで引き上げた。 利用するにあたりの利点としては、APIから返却されるjsonをマッピングするレスポンスクラスが用意されていること。 導入方法 下記らへんを参考に実装した。 restfb-examples(サンプルコード) cookbook documentation ライブラリアップデート 2.X系から3.X系にあげたが、大きく変更があった箇所は記憶にない。。。 おわりに 書き味やコードサンプルは特に記載しませんが、 公式リファレンスが整頓されすぎて、導入の敷居はすごく低いです。 JavaアプリケーションでFacebook連携する際は、restfbの導入を検討して欲しいです。

switch文について switch文とは? Javaには条件分岐処理というシステムがあります。 代表的な文として「if-else文」があります。 今回は、もう一つの条件分岐処理の「switch文」について説明致します。 switch文の構造 以下のコードをご覧ください。 switch(式){ case 定数1: //式の結果が定数1と一致したとき、以下の処理が行われる。 処理文1; case 定数2: //式の結果が定数2と一致したとき、以下の処理が行われる。 処理文2; default: //上記どのcaseにも一致しなかったとき、以下の処理文が実行される。 defaultの処理文; } switch文は、式を評価した結果とcaseで指定した定数とを比較し、 一致した場合にそのcase以降に記述した処理文を実行します。 switch文のデータ型 switch文の式の評価は、データ型として ・char ・byte ・short ・int(およびそのラッパークラス) ・enum ・String のいずれかの値である必要があります。 それ以外の型が指定されるとコンパイルエラーとなります。 また、式の評価がnullの場合、コンパイルは成功しますが、実行時にNullPointerException例外が 発生します。 break文 case文で式を評価しtrueになった場合、case以下の処理が全て行われてしまいます。 もしswitch文を抜けたい場合はbreak文を記述します。 case 定数1: 処理文1; break; case 定数2: 処理文2; このコードの場合、もし「case 定数1」でtrueになった場合、処理文1が実行され、「case 定数2」の式は 評価されず、switch文を抜ける流れとなります。 まとめ ・switch文は、式を評価した結果とcaseで指定した定数とを比較し、 一致した場合にそのcase以降に記述した処理文を実行する。 ・switch文の式の評価は、データ型として【char,byte,short,intおよびそのラッパークラス),enum,String】 のいずれかの値である必要がある。 ・switch文を抜けたい場合はbreak文を記述する。

　諸元 ニフクラのmBaaSに移行することになって、RestAPIのリクエストで渡す日時がUTCのISO形式だったのでなんとかしたかった。 2021-06-13T12:34:56.789Z ←　現在日時をこういう形式の文字列にしたい。 　やりかた Calendarを使うてもあるけど、簡単なのはこっちか。 SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SSS'Z'"); sdf.setTimeZone(TimeZone.getTimeZone("UTC")); String iWant = sdf.format(new Date()); "T"とか"Z"はシングルクォートで囲まないと死。 　ちなみに ZonedDateTimeとDateTimeFormatter使えっていう話はいったん置いておきます:) うっかり他コンポーネントとのインターフェースをDateでやっちゃったんだあ:0

はじめてのjava.text.SimpleDateFormat とりあえずフォーマットを定義したらその形で出力できるらしいのでやってみた。 SimpleDateFormat_DD Date date = new Date(); SimpleDateFormat sdf = new SimpleDateFormat("MM月DD日"); String today = sdf.format(date); System.out.println(today); //　出力結果 6月161日 えー、なんで。。？ 調べたら大文字とか小文字でいろいろ定義がされていて、 大文字のDDは年における日数がでるらしい。ふむ。 ddを小文字に変えた。 SimpleDateFormat_dd Date date = new Date(); SimpleDateFormat sdf = new SimpleDateFormat("MM月dd日");　//ddを小文字に変更 String today = sdf.format(date); System.out.println(today); 思った通りに出た。 //　出力結果 6月10日 日時パターン 文字 コンポーネント 例 y 年 2021;21 M 年における月 11 D 年における日 161 d 月における日 25 F 月における曜日 2 E 曜日の名前 Tuesday;Tue u 曜日の番号 1(1=月曜） まとめ 便利なので基本的なパターンを覚えて使いこなしたい。

強連結成分分解について解説します 強連結とは、強連結成分とは wikipediaより。 強連結 有向グラフが強連結であるとは、グラフ上の任意の2点間に有向路が存在することである。極大で強連結な部分グラフは、強連結成分という。 引用の通り、有向グラフにおいて、任意の2点間に有向路が存在（直接または別の頂点を通って行き来できる）するとグラフは強連結、また、グラフの部分グラフが強連結である場合は、それを強連結成分というようです。 強連結成分分解は、グラフを強連結成分に分解していくこと（そのままですが）となります。 例えば、このグラフは強連結です。 任意の2点間に有向路が存在（どの2点を選んでも直接または頂点を経由して移動することが可能）します。 そしてこのグラフには強連結成分が存在します。 四角で囲んでいる、グラフの部分グラフに該当する2箇所はそれぞれ強連結となっています。 強連結成分分解のやり方 手順は以下のとおりです。 適当な頂点からDFSして、帰りがけに頂点をラベリングする グラフを逆グラフ（辺の向きをすべて反転）にし、頂点ラベルの大きいものから再度DFSし、一度でたどり着けるところをそれぞれSCCとする。 こちらのリンクが参考になりましたので、引用させていただきます。 ここでは、とりあえずこの手順に従って実際の問題を解いて見ようと思います。 例題 E869120さんの、典型90問より、021 - Come Back in One Piece（★5）を解いてみました。典型的なSCCの問題のようです。 ACコードを載せておきます。 Main.java import java.util.ArrayList; import java.util.Arrays; import java.util.Scanner; public class Main { // dfsで使用 static boolean[] checked = null; // 辺 static ArrayList<ArrayList<Integer>> edge = null; static ArrayList<ArrayList<Integer>> revEdge = null; // 頂点のラベリング static int count = 0; static int[] vr = null; // SCCのgroup番号 static int group[] = null; static int groupNum = 0; public static void main(String[] args) { Scanner sc = new Scanner(System.in); int v = sc.nextInt(); // 頂点数 int e = sc.nextInt(); // 辺数 edge = new ArrayList<>(); // 左要素→右要素が存在するかどうか revEdge = new ArrayList<>(); // 左要素→右要素が存在するかどうか vr = new int[v]; // 配列の添字がラベル、値が頂点 /* * Listの初期化 */ for (int i = 0; i < v; i++) { edge.add(new ArrayList<>()); revEdge.add(new ArrayList<>()); } /* * 入力の受け取り、辺の格納 */ for (int i = 0; i < e; i++) { int s = sc.nextInt() - 1; int t = sc.nextInt() - 1; // 頂点sからtへの辺が存在 edge.get(s).add(t); // 反転したグラフを考える際に使用 revEdge.get(t).add(s); } /* * DFSして帰りがけに頂点をラベリング。 * 一度のDFSで終わらないことを加味し外側にもループ */ checked = new boolean[v]; // 探索した頂点を記録 for (int i = 0; i < v; i++) { // i番目の頂点について探索 if (!checked[i]) { firstDfs(i); } } /* * 再度DFSをラベルの大きい順・辺を逆転したグラフで行う。 * DFSが途切れるたびにgroupを更新 */ Arrays.fill(checked, false); // 探索した頂点を記録 group = new int[v]; // 頂点vが属するグループ名 for (int i = v - 1; i >= 0; i--) { // ラベリング大きい順から探索 int tansakuTyoten = vr[i]; if (!checked[tansakuTyoten]) { secondDfs(tansakuTyoten, groupNum++); } } long ans = 0; for (int i : group) { ans += (long) i * (i - 1) / 2l; } System.out.println(ans); } static void firstDfs(int now) { // 頂点nowを受け取りdfs checked[now] = true; for (int i : edge.get(now)) { if (!checked[i]) { firstDfs(i); } } // 引き返した際のラベル付け vr[count++] = now; } static void secondDfs(int now, int groupNum) { // 頂点nowを受け取りdfs checked[now] = true; group[groupNum]++; for (int i : revEdge.get(now)) { if (!checked[i]) { secondDfs(i, groupNum); } } } } なんとなく、DFSを2回やっていることを感じ取れると嬉しいです。 ※変数名が問題と微妙に異なります。AOJの問題を先に解いていたのですがStackOverFlowErrorが出てしまい解けなかったのでこちらを例題としました。 問題はこちらです。Strongly Connected Components 再帰が多いからStackOverFlowErrorが出ているのだと思いますが、他のACコードも再帰使いまくっているのにこのコードだけStackOverFlowErrorが出る理由を突き止められず・・・。典型90問は解けたからいいか、、、という気持ちになっています。 ひとまず、強連結成分分解の実装についてはここまでとします。 ※「競技プログラミング研究月間 - みんなでさらなる高みを目指そう」が開催中のようです。

はじめに E2Eテストの自動化でどうしても結果レポートなどを出力させる処理をbatから実行せざる負えない状況になってしまった時に、Javaからwindowsのbatを実行する実装を行ったので、その備忘録を残しておく。 Javaからwindowsのbatを実行する Bat.java public class Bat { public static void execute() { String batFile = "C:\\temp\\sample.bat"; ProcessBuilder pb = new ProcessBuilder(batFile); pb.redirectOutput(ProcessBuilder.Redirect.INHERIT); pb.redirectError(ProcessBuilder.Redirect.INHERIT); Process process = pb.start(); process.waitFor(); } }

clone、およびCloneableについて(主に欠陥について)、詳しく記載しています。 正直、記載内容は全部は読まなくても良いのではないかと思います・・・ Cloneableの是非に記載した内容は、EffectiveJavaでは項目の末尾に記載されていますが、 一番重要な内容であるため、最初に記載しました。 その内容を呼んでも、Cloneableについて知りたい方は、その続きを読んでください。 興味が無い方は、考察まで飛んでください。 記載内容 Cloneableの是非 clone()について複雑なルール、注意点を記載するが、そこまでclone()によるコピーが必要な状況はまれである。 残念ながら、すでにCloneableを実装しているクラスを拡張するのであれば、 正しいclone()を実装する以外の選択肢はほとんどない。 それ以外の状況であれば、オブジェクトのコピーを行う、代替手段を提供する方が良い。 オブジェクトをコピーする良い方法は、 コピーコンストラクタ、コピーファクトリメソッドを提供することである。 Cloneableの多くの問題を考えると、新たなインタフェースはCloneableを拡張するべきではないし、 新たな拡張可能なクラスはCloneableを実装するべきではない。 finalのクラスがCloneableを実装することに害はないが、パフォーマンスに対する最適化とみなし、 それが正当化されるまれな場合のみにするべきである。 Cloneableの欠陥 Cloneableは、クラスが複製であることを示すことを意図しているが、その目的は果たせていない。 最大の欠陥は、Cloneableインタフェースがclone()を定義しておらず、Object.clone()がprotectedなことである。 このため、リフレクションを使わないと、Cloneable変数からclone()を呼び出すことが出来ない。 Cloneableの意味は、実装することでObject.clone()の動作を変更することである。 Object.clone()は、 クラスがCloneableを実装している場合、自身のコピーを返し、 実装していない場合、CloneNotSupportedExceptionをスローする。 これはインタフェースの異常な使い方であり、真似するべきではない。 clone()の一般契約は、Cloneableではなく、Object.cloneのJavaDocに記載されている。 (ここでは割愛) Cloneableを実装しているクラスは、適切に動作するpublicなclone()を実装することが期待されているが、 そのためには、そのクラスとすべてのスーパークラスが、 複雑で、強制するのが不可能で、ドキュメントにほとんど記載されていない規約に従わなければならい。 clone()の実装方法 前提として、親クラスが正しく動作するclone()を提供している場合、 最初にsuper.clone()を呼び出すべきである。 クラスが可変オブジェクトを参照するフィールドを保持していない場合 そのクラスのすべてのフィールドが基本データ型か、不変クラスへの参照であれば、 super.clone()の戻り値をキャストして、clone()の戻り値とすればよい。 ただし、クラスが、インスタンスごとに一意なIDをフィールドとして保持しているような場合、 clone()はただフィールドをコピーするだけでななく、そのフィールドを修正する必要が有る。 クラスが可変オブジェクトを参照するフィールドを保持している場合 もし、クラスが可変オブジェクトを参照するフィールドを保持しており、 その可変オブジェクトを複数のインスタンスで共有できない場合、 解決方法は、その可変オブジェクトに対して再帰的にclone()を呼び出し、フィールドをclone()の戻り値で更新することである。 ただし、この方法は可変オブジェクトを参照するフィールドがfinalの場合は、うまくいかない。 これは根本的な問題であり、final修飾子を外す必要が有るかもしれない。 クラスが可変オブジェクトを要素とする配列を保持している場合 クラスが配列を保持しており、その配列の各要素を共有できない場合、 配列に対するclone()呼び出しでは不十分であり、全配列要素に対してdeep copyが必要になる。 最後の手段 複雑なオブジェクトを複製する最後の手段は、super.clone()を呼び出し、 返されたオブジェクトの全フィールドを初期状態に戻し、 複製元のオブジェクトの状態を再現するために、高いレベルのメソッドを呼び出すことである。 しかし、この方法は、複製先のフィールドを直接更新する方法と比べると遅く、 また、Cloneableアーキテクチャの基本となる、フィールドの自動的なコピーとは、正反対の方法である。 clone()実装時のその他の注意事項 もしクラス自体が不変クラスであれば、clone()を提供するべきではない。 clone()は、無意味なコピーを行うだけである。 clone()は、コンストラクタと同様に、生成中の複製先に対して、オーバーライド可能なメソッドを呼び出してはならない。 これは、そのメソッドがオーバーライドされた場合に、複製先が不正な状態でサブクラスのメソッドが呼ばれることになり、 複製先と複製元の破損につながる可能性が高くなるためである。 Object.clone()は、CloneNotSupportedExceptionをスローすると宣言されているが、 オーバーライドしているメソッドでは、throws節を削除するべきである。 (実際にはCloneNotSupportedExceptionをスローすることはなく、使用側はthrows節が無い方が使いやすいため) スレッドセーフなクラスでは、clone()も排他制御が必要になる可能性がある。 継承されるクラスに対するCloneableの扱い 継承されるようにクラスを設計する場合、以下の選択肢がある。 (どちらを選ぶ場合でも、継承元のクラスはCloneableを実装するべきではない) 適切に機能する、protectedのclone()を実装する このclone()では、最初にsuper.cloneを呼び出し (サブクラスがCloneableを実装していない場合は、この時点でCloneNotSupportedExceptionがスローされる) 可変オブジェクトのフィールドのコピー等を適切に行う。 サブクラスのclone()実装を不可能にする 以下の様なclone()を提供することで、サブクラスがclone()を実装することを防ぐ @Override protected final Object clone() throws CloneNotSupportedException { throw new CloneNotSupportedException(); } 考察 長い項目ですが、ひたすらCloneableの複雑さ、デメリットについて書いています。 CloneableとSerializable この2つは、初期のJavaの設計における大きな失敗と思います。 (Serializableについても、項目85で盛大にディスっています) どちらも、クラスツリーの上位で実装(拡張)してしまうと、 そのクラスツリー全体が汚染されてしまい、末端のクラスまで性質を引き継ぐ必要が出てしまいます。 もはや、クラスの拡張で機能追加を図ること自体が時代遅れとは思いますが、 既存のクラスがCloneableやSerializableを実装している場合、拡張時の大きな制約になります。 配列の防御コピー 唯一といってよい、clone()のありがたみがあるケースと思います。 コンストラクタ等で、引数の防御コピーを行う場合、 配列に対してclone()を呼ぶのが簡単で良いです。 (要素が不変クラスである場合に限りますが) コピーコンストラクタ、コピーメソッド 記載してある通り、 可変クラスに対して、コピーを作成する必要が有る場合、クラスにこれらの機能を追加するのが良いです。 ただ、「項目17 可変性を最小限にする」にある通り、可能な限り値の保持を不変クラスで行えば、 インスタンスのコピー自体が、多くの場合不要と思います。 サブクラスがcloneを実装不可能にする ここまでやる必要は無いのではないかと思いますが、 利用者を信頼できないのであれば、実施するべきなのかもしれません。 業務での開発でここまでやる必要はないと信じたいですが・・・ いつの間にか、サブクラスでclone()を実装されるのを防ぐには 必要かもしれませんが、 そこまでしたところで、このclone()を削除されたら意味が無いわけで・・・

こんにちは！ テクニカルコンサルティングチームの古堅です。 本記事は「Java における SPA (Single Page Application 以降 SPA) 導入とフロントエンドフレームワークの選択」というテーマで執筆しました。 Java の特徴 何でも出来る開発言語 Java は出来ないことはほとんど無い。と言っても過言ではないプログラミング言語です。 Java Virtual Machine (JVM) の仕組みのおかげで OS 問わず、 Windows 、 Mac OS 、Linux で動作できるのは大きい強みですし、デスクトップアプリ、Web アプリ、スマートフォン、組み込み系など様々なデバイス上で動作するアプリケーションを作成できる万能な開発言語です。 エンタープライズ向けアプリケーションの採用率が高い Java は、オブジェクト指向言語であり、高品質な設計を実現できるため、エンタープライズ向けアプリケーションで採用率が高い開発言語です。 特に、バックエンドの処理を得意としており「フロントエンドは Java ではないが、バックエンドとしての API は Java で開発している」というアーキテクチャも多いです。 Webシステムは、サーバーサイドレンダリングで構築できるが、SPA の実現は出来ない Java には、Spring などのフレームワークを導入し、簡単に Web ページを作成することもできます。 非常に高機能、かつ、便利な機能を提供しており、バックエンド、フロントエンド、どちらも開発することができますが、SPA は、Java 単独では実現できません。 そのため、フロントエンドフレームワークを選択する必要があります。 そもそも Java の Web システムに SPA が必要か？ 前述したように、Java は優秀な開発言語ですが、SPA の実現は出来ません。そもそも Java で SPA は必要なのか？ いくつか採用理由を列挙してみました。 このページをご覧頂いている Java デベロッパーの方で、SPA の検討理由も、おそらく下記の①～③に該当するのではないでしょうか。 ① SPA でしか実現できないビジネス要件がある SPA が導入されている有名な Web ページは、Twitter、Facebook、Slack、Google Map などがありますね。 開発要件として、そもそも SPA でしか実現できないビジネス要件がある。というのが一番大きい採用理由かもしれません。 例えば、Slack や、Twitter は、ページの更新をボタンをクリックせずとも、通知が来たり、メッセージのやり取りなどができますね。 このように、ページ遷移を行わずに、継続的に情報をやり取りするようなアプリケーションは SPA の導入が最適でしょう。 ② クラウド運用のメリット「スケーラビリティ」を享受したい 次は、運用コスト的な観点の SPA 採用理由です。 ひと昔前は、Web サーバー運用は、高価なサーバーを購入 (またはレンタル) し、運用するのが主流でした。 しかし、クラウド運用が主流になった現代では、アクセス数の増減などのサーバー負荷に応じて、対応するサーバースペック、あるいは、サーバーインスタンスを増減することで、運用コストの最適化を行う。いわゆる「スケーラビリティ」を行うことが主流となっています。 スケーラビリティを意識したクラウド運用を前提とした場合に、サーバーサイドレンダリングはコストの削減の足枷になる場合があります。 例えば、バックエンドの負荷が高いため、サーバーインタンスを4台に増やしたい場合でも、１つのサーバーとして構築されている場合、負荷が少ないフロントエンドも含めて、インスタンス数を増やすことになり、余計なコスト増につながる可能性があります。 ③ マイクロサービスの運用 マイクロサービスは、API を疎結合し、単独で動作を完結させることにより、再利用性、保守性を高める開発手法です。 Java 的に表現すると 「API をオブジェクト指向的に活用する」という理解でも良いかもしれません。 詳細は以下のページをご確認ください。 有名な採用事例としては、Line 、Amazon、Facebook、Netflix など、他にも多くあります。 また、マイクロサービスの採用のよくある例としては、パソコン、携帯電話、スマートフォン、タブレット、スマートスピーカーなど、多様なインターフェースに対応するために、再利用制の高い API 群を構築し、どのデバイスからでも、API を再利用できるようにする目的とすることが多いでしょう。 この観点でも、フロントエンド / バックエンドが同一のサーバー上に配置する必要がある サーバーサイドレンダリングは、マイクロサービス採用時に、余分なコストの増加に繋がる可能性があります。 三大フロントエンドフレームワークの比較 SPA を採用するにあたり、選択肢となる3大フレームワークの特徴を解説していきます。 Angular : 優等生なフレームワーク Angular は、優等生なフレームワークです。Angular はフルスタックでアプリケーションに必要な全ての機能を提供しています。 ルーティングを含め一般的に必要な機能を全て提供しているため、Angular が提供するアーキテクチャに従うことで、高品質なアプリケーションが作成できます。 良くも悪くも、Angular のお作法に従う必要があるので、Angular のルールではない独自の設計思想を取り入れたい場合は、苦労することがあるかもしれません。 Angular は学習コストが高いと言われていますが、上記で述べたようにフルスタックで機能を提供しているので、それらを包括した学習コストが、他のフロントエンドフレームワークと比較すると「学習コストが高い」と評価される原因になっています。 ですが、そのほとんどがアプリケーション開発において、必要な機能であるため、学習コストは決して無駄にはなりません。「SPA の構築」という問題を解くための、必要な学習項目が列挙されており「教科書」として、ベストプラクティスを教えてくれる。それが Angular です。 初めて採用する SPA としては、アーキテクチャ設計にかける時間が少ない、そもそも、どんな機能が必要なのか？を学ぶにも、まずは Angular の導入を検討することをおすすめします。 React : 柔軟性があり、拡張性が高い React は拡張性が高く、逆にいってしまえば、開発者が取捨選択する場面が多いフレームワークです。 そのため、React を採用する場合、設計段階において React 経験者の重要性が非常に大きいとも言えます。 また、豊富な拡張性により、どんな要件に対しても柔軟に対応することも出来るでしょう。 React Native でスマートフォン / タブレットのネイティブアプリを作成できることも大きな特徴です。 Vue.js : シンプルで導入コストが低い 導入のしやすさは、Vue.js が 一番でしょう。 日本国内において現状、最もフロントエンドフレームワークと言っても良いのではないでしょうか。 学習コストが低く、なぜなら、シンプルさが特徴であるフレームワークです。 とりあえず、プラットフォームとしては、Vue.js を採用し、まずは現行の HTML (CSS + JavaScript) を移行して動作させ、後々 Vue.js の機能を活用する。などの段階的に移行する場合は、Vue.js が適しています。 但し、シンプルさうえに、品質を維持するためのアーキテクチャを、デベロッパー自身がしっかりと考えなければならないため、React とは別の意味で腕が問われるフレームワークとも言えます。 まとめ : おすすめは Angular 結論としては、Java におけるフロントエンドフレームワークは Angular の採用をおすすめします。 特に、初めてフロントエンドフレームワークの導入を検討している場合、Angular は、フルスタックで機能を提供しており、それらを活用することで、アーキテクチャの検討、設計、実装コストの削減に大きく貢献してくれるかと思います。 次回以降の記事では、Java + Angular を組み合わせて Web アプリケーションを作成するために必要な手順などを、サンプルを交えながら紹介していきたいと思います。 Ignite UI for Angular トライアル版を利用するには インフラジスティックスでは充実した UI コンポーネントライブラリーを収録し、データリッチでレスポンシブなWebアプリケーションをより迅速に構築することを可能にする Ignite UI を開発しており、Angular 対応の Ignite UI for Angular もリリースしています。 Ignite UI for Angular はトライアル版での試用が可能です。 製品に関する技術的な問い合わせは こちらのページ よりアカウントの作成を行ってください。登録より30日間、弊社のテクニカルサポートをご利用いただくことが出来ますのでお気軽にお問い合わせください。 また、製品をご購入をご検討のお客様は こちらのページ より 開発全般に関するご相談はお任せください！ インフラジスティックス・ジャパンでは、各開発プラットフォームの技術トレーニング、コンサルテーションの提供、開発全般のご支援を行っています。 「古い技術やサポート終了のプラットフォームから脱却する必要があるが、その移行先のプラットフォームやフレームワークの検討が進まない、知見がない。」 「新しい開発テクノロジーを採用したいが、自社内にエキスパートがいない。日本語リソースも少ないし、開発を進められるか不安。」 「自社のメンバーで開発を進めたいが、これまで開発フェーズを外部ベンダーに頼ってきたため、ツールや技術に対する理解が乏しい。」 「UIを刷新したい。UIデザインやUI/UXに関する検討の進め方が分からない。外部のデザイン会社に頼むと、開発が難しくなるのではないか、危惧している。」 といったご相談を承っています。 お問い合せはこちらからお気軽にご相談ください。 技術サポート・無料オンライン相談会をご利用ください インフラジスティックスのUI製品は多くの機能を備えているためドキュメントの情報量も多く、なかなかお探しの情報に辿り着けない場合もあります。そういった際はお気軽に技術サポートや、製品導入支援担当との無料オンライン相談会をご予約いただくことで検証時間を節約可能ですので、ぜひご活用ください。 技術サポートへの問い合わせ方法を確認する 無料オンライン相談会を予約する

項目54 nullではなく、空コレクションかから配列を返す チーズのリストを返すメソッドを定義するとします。 private final List<Cheese> cheesesInStock = ...; /** * @return 店にあるすべてのチーズを含むリスト、もしくは、買えるチーズがなければnull */ public List<Cheese> getCheese() { return cheesesInStock.isEmpty() ? null : new ArrayList<>(cheesesInStock); } このメソッドはnullを返すので、毎回nullチェックしなければいけません。 List<Cheese> cheeses = shop.getCheeses(); if (cheeses != null && cheeses.contains(Cheese.STILTON)) { System.out.println("Jolly good, just the thing."); } この問題は、nullを返すのではなく、空コレクションや空配列 を返すことで解決できます。 public List<Cheese> getCheese() { return new ArrayList<>(cheesesInStock); } 空コンテナを生成するのはパフォーマンスが下がるかもしれないと考える場合は以下の方法があります。 しかし、空コンテナの生成でパフォーマンスが下がることはあまりありません。 実装が複雑になるので、パフォーマンスを測定し改善されることが確認できる場合のみ用いたほうがいいです。 public List<Cheese> getCheese() { return cheesesInStock.isEmpty() ? Collections.emptyList() : new ArrayList<>(cheesesInStock); } private static final Cheese[] EMPTY_CHEESE_ARRAY = new Cheese[0]; public List<Cheese> getCheese() { return cheesesInStock.toArray(EMPTY_CHEESE_ARRAY); } ちなみに、以下のように toArray へ渡す配列を事前に割り当てるとパフォーマンスが悪くなります。 return cheeseInStock.toArray(new Cheese[cheesesInStock.size()]); まとめ 空コレクションや空配列の代わりに、nullを返さないほうがいいです。。 nullを返すとそのメソッドが使いづらくなります。

EclipseでSpring Bootのプロジェクトを実行しようとした時、以下のエラーメッセージがコンソールに出力されました。 エラー: メイン・クラス ○○ が見つからなかったかロードできませんでした 「実行 ／ デバッグ の構成」の「クラスパス」タブで、「一時 JAR を使用してクラスパスを指定する（クラスパスの長さ制限を避けるため）／Use temporary jar to specify classpath (to avoid classpath length limitations)」をチェックして起動すると、エラーが解消され、アプリケーションを起動できました。 以下のStackOverflowの投稿で見つけました。 Eclipse 4.9で導入された機能でした。