JAX-RS の仕様に組み込んで欲しいという意見をちらほら見かける、噂の Jersey MVC を試す。 テンプレートには JSP を使い、とりあえず GlassFish で ver 2.0 を試してから、 Tomcat で 2014/01/26 現在最新の ver 2.5.1 を試してみる。 環境 AP サーバ GlassFish 4.0 Tomcat 7.0.42 GlassFish で ver 2.0 を試す Jersey MVC JSP はバンドルされている GlassFish 4.0 には、 Jersey MVC JSP の 2.0 がバンドルされているので、それを利用する。 glassfish\modules>dir /b jersey-mvc* jersey-mvc-connector.jar jersey-mvc-jsp.jar ← MVC JSP がバンドルされてる je
このチュートリアルでは、埋め込み Tomcat を使用して単純な Java Web アプリケーションを作成する方法を示します。 各手順を実行してアプリをゼロから構築するか、最後までスキップしてこの記事用のソースを入手してください。 前提条件 Java の基本的な知識 (インストールされている JVM および Maven のバージョンなど) Git の基本的な知識 (インストールされている Git のバージョンなど) pom.xml を作成する アプリを格納するフォルダーを作成し、そのフォルダーのルートに、pom.xml という名前のファイルを次の内容で作成します。 <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schem
ResponseEntityExceptionHandler について Spring Boot では ResponseEntityExceptionHandlerクラスで『どの例外が発生したときになにを返すか』のハンドリングを行っています。 このクラスを継承して例外ごとに定義されているメソッドをオーバーライドすることで、処理を好きなように行うことができます。 すべての例外のハンドリングがこのクラスに記述されているわけではないので、クラスの中身を確認してみてください。 ハンドリングの例(HttpRequestMethodNotSupportedException) 処理の例を見ていきます。 POSTメソッドしか定義されていないエンドポイントに対してGETでリクエストされたときなどに発生するHttpRequestMethodNotSupportedExceptionにおいて、任意のレスポンスボ
この記事について 最近(5.4〜6.0)のSpring Securityでは、セキュリティ設定の書き方が大幅に変わりました。その背景と、新しい書き方を紹介します。 非推奨になったものは、将来的には削除される可能性もあるため、なるべく早く新しい書き方に移行することをおすすめします。(既に削除されたものもあります) この記事は、Spring Securityのアーキテクチャの理解(Filter Chain、 AuthenticationManager 、 AccessDecisionManager など)を前提としています。あまり詳しくない方は、まずopengl_8080さんのブログを読むことをおすすめします。 サンプルコード -> https://github.com/MasatoshiTada/spring-security-intro 忙しい人のためのまとめ @Configuration
PHPerKaigi 2024〜10年以上動いているレガシーなバッチシステムを Kubernetes(Amazon EKS) に移行する取り組み〜
抹殺は言い過ぎかもしれませんが簡易な名刺管理アプリであれば自作で十分という時代がきていたようです これで紙の名刺からはきっとバイバイできるでしょう! 名刺管理アプリ作ってほしいといわれた それは2/22のお話。 ことの発端は別の部署からかかってきた一本の電話でした。 新規事業の部署でいろいろな取引先様と付き合いがあるものの、紙の名刺が非常に多く管理に困っているとのことのことです。 私は小売業に勤務しているしがない一社員で、現在Eコマースの戦略立案に関する部署に所属しています。 電話先の方は、以前一緒の部署で勤務したことがある方です。現在新規事業のプロジェクト推進をしており、冒頭のような課題感を持っているため既存の名刺管理アプリ導入を考えたのですが、あまりのお値段の高さに卒倒して私に藁をもすがる思いで連絡されたようです。 これまでのアプリは名刺の識別専門のAI()を使っていた 話を聞いてみた
こんにちは、AIShift バックエンドエンジニアの石井(@sugar235711)です。 AIShiftでは去年の11月からAI Worker[1]という新しいサービスの開発が始まりました。(以下AI Worker) 本格的に開発が始まり3ヶ月弱経ったので、その間に試してきた技術やチームの取り組みについてまとめてみたいと思います。 はじめに この記事では、AI Workerのおおまかな概要・設計を説明し、それらのバックエンドを実現する上でどのような技術を試してきたのか、技術以外でのチームの取り組みについてまとめます。 少し分量が多いので、ライブラリについての情報を求めている方は、目次から気になる部分を読んでいただければと思います。 何を作っているのか ざっくりまとめると、Microsoft Teams/Web上で動くAIを活用した業務改善プラットフォームを作成しています。 GPTとRAG
はじめに Java の enum は大変便利で非常多くのシーンで活用されています。例えば区分を表すようなオブジェクトを表現したい際にもよく使われていますね。 Java 14 で正式機能となった switch式にて網羅性検査が行えるようになり、それまで以前ではどうしても抽象メソッド等を活用する必要があった処理についても、switch式を利用する事で簡潔に表現することができるようになりました。 また、Java 17 で正式機能となった sealed classes/interfaces と Java 21 で正式機能になった Record Patterns によって、これまで必要だった区分値のような enum を必ずしも定義しなくて良い場合も出てきました。 この記事では、今まで enum を使っていたコードがこれらの機能によってどのように変わるのかを紹介し、盲目的に enum を定義するのでは
ソーシャル経済メディア「NewsPicks」で推薦や検索などのアルゴリズム開発をしている北内です。Pythonは頻繁に新機能や便利なライブラリが登場し、ベストプラクティスの変化が激しい言語です。そこで、2024年2月時点で利用頻度の高そうな新機能、ライブラリ、ツールなどを紹介したいと思います。 この記事では広く浅く紹介することに重点を置き、各トピックについては概要のみを紹介します。詳細な使用方法に関しては各公式サイト等での確認をおすすめします。なお、本記事ではOSとしてmacOSを前提としています。 環境構築 Pythonの環境構築はpyenvとPoetryの組み合わせがもっとも標準的でしょう。 以下の手順でpyenvとPythonをインストールできます。 brew install pyenv # Bashの場合 echo 'eval "$(pyenv init -)"' >> ~/.ba
どうも、レコメンド商品のシステム開発をしている野川と申します。 私は、2021年にモノタロウに新卒入社し、2022年5月からレコメンド商品の開発に関わり始めました。 モノタロウのレコメンド商品は、下の図の①~④の流れでクライアントサイドで表示しています。大部分の処理はJavaScriptで構成しており、UIもそのHTML部分をjQuery(JavaScript)で作成しています。 図:レコメンド商品表の流れ 入社当時私は、ソフトウェアエンジニアとして、「可読性の低いコードは駆逐するべきだ」「読みやすいコードだけが正義である」「理解しやすいシステムだけが皆を幸せにする」と心の底から考えていました。加えて、「なぜ先輩たちは可読性の低いコードを放置して平気なのか?」と疑問を持つこともしばしばありました。 レコメンド商品周りのコードはまさに可読性の低いコードベースとなっていたため、当事者となった私
前置き 業後に技術的負債のイベントに参加してきました。 内容がそれぞれバラバラであるかに見えて、自分の中ではすべてが有機的に繋がって感じました。 ただ、懇親会に参加できなかったのは残念です💦 開発サイドの方や、テスト設計されている方、組織構造と絡めて話されている方 などそれぞれが違った観点で技術的負債についてアウトプットされていました。 技術的負債の定義 「コードを書くというのは、借金をするようなもの。 少しの借金は速やかに返済(リファクタリング活動により)される限り開発を加速させるが、 危険なのは借金が返済されない状態が続くこと。」 という文が紹介されました。 つくっているプロダクトで得られる売り上げよりも、 変更などにかかるコストが上回っている状態なわけだから、 お金という定義が明確な数値として、負債曲線グラフ的なもので定期的にチェックできる体制が望ましいですね。 で、事前に負債解消
はじめに 勝丸と言います。ログラスのエンジニアが毎週記事を発信するLoglass Tech Blog Sprint 2周目に突入しました。前回は「心穏やかにDBバージョンアップ!ロジカルレプリケーションで安全にバージョンを切り戻せるようにした話」という記事を書きました。こちらもよろしくお願いします。普段はログラスの横串組織で活動しています。 この記事では「数年来の技術的負債を改修した話 - 2種類のORM並列状態からの脱却 -」というタイトルで、年末から年始にかけてやっていた作業について共有します。 この記事で得られること リファクタリングのやり方や考え方 リリースへの持っていき方 投資判断のタイミングや負債解消について 経緯 ログラスでは2種類のORMが存在していました。創業時にORMとしてExposedを採用したのですが、後に一部機能が足りないことが発覚し、別のORMを利用し始めました
エンジニア、デザイナー採用の面談/面接時に使用している会社紹介資料です。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く