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
はじめに 前回はRloginを使ってSSH接続しましたが、PythonのParamikoライブラリを使えばコードからも同じことが出来ることを知ったのでやってみる。 本記事のゴール PythonライブラリのParamikoを使って、WSL2で作ったUbuntuにSSH接続してLinuxコマンドを実行する。 環境 Windows 10 64bit Ubuntu 20.04.4 LTS(WSL2) 利用ライブラリ Paramiko SSH, SFTP用のPythonライブラリ https://docs.paramiko.org/en/stable/api/client.html 事前準備 Paramikoのインストール pip install paramiko コード SSH接続してカレントディレクトリを取得するサンプルコード SSH接続paramikoを使用したSSH接続 #paramiko
このチュートリアルでは、埋め込み 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
はじめに あまり知られていないかもしれませんが、Svelteを使ってWeb Componentsを開発することができます。 本記事ではSvelteを使ってWeb Componentsを開発するやり方を紹介したいと思います。 Web Componentsとは webcomponents.orgから引用 Web Componentsは、WebプラットフォームAPIのセットで、WebページやWebアプリケーションで使用する、新しいカスタム、再利用可能な、カプセル化されたHTMLタグを作成することを可能にします。カスタムコンポーネントとウィジェットはWeb Componentsの標準に基づいて構築され、モダンブラウザで動作し、HTMLで動作するあらゆるJavaScriptライブラリやフレームワークで使用することができます。 Web Componentsは、既存のWeb標準をベースにしています。We
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
はじめにクレディセゾンに来てちょうど5年が経ったので、これまでの取り組みをまとめてみようかと思う。書き進めていくうちにとても長くなってしまったので、1年につき3トピックに絞ってあとはカットした。それでも5年分なこともありかなり長くなったので、目次から各トピックに飛んでもらえればと思う。社内の関係者も読むかもしれず、「自分のやったことが載ってない!」と思うこともあるかもしれないが、内製開発案件だけでも53案件あり全部載せるととんでもない量になるので許してほしい。それから、振り返ってまとめると退職すると勘違いされるかもしれないけれど、退職するわけではありません! 2019年:ゼロからのスタート1-1. 内製開発エンジニア募集を始める「日本のそれなりの規模の事業会社の中に、内製開発チームを立ち上げることはできるのだろうか?」 2019年3月、クレディセゾンに来たばかりの私にとってはこの質問への答
PHPerKaigi 2024〜10年以上動いているレガシーなバッチシステムを Kubernetes(Amazon EKS) に移行する取り組み〜
「負債にも50パーセントの時間を使ってください」は機能しなかった 西村賢氏(以下、西村):最初にやったことに価値がありました。そして、次は第2段。 原トリ氏(以下、原):この説明会やった時に、6月は一回止めますと(話しました)。完全に機能開発を止めて、サポートから流れてくるチケットに関してはオンコール体制を組んできちんと対応するけれど、機能開発はしないというのを戦略として……。 西村:これ、カミナシの歴史で初めてですね。 原:たぶん、初めてだと思います。 西村:そこは「大丈夫なのかな?」とかなかったんですか? 原:「この1年大きい機能、出てないよね?」みたいな共通認識は、全社にあったから経営の中で意思決定が早かったんです。 西村:なるほど。なにか技術的にうまくいっていないというのがあった。 原:そうです。プロダクトがうまくいっていないという認識がまず全社にあって、かつ、これがカミナシの底力
2024.3.22(金) SRE観点での技術負債 懺悔会 2024 https://mixi.connpass.com/event/312191/
スマレジ社が株式会社ロイヤルゲート(以下、RG社/決済端末「PAYGATE」を開発)をM&Aしてから2年が経ちました。当社にとって初の大型M&Aしかも買収先は赤字企業と、リスクの高い選択でしたが、本日開示の決算説明資料記載のとおり単月黒字化まで漕ぎつけることができました。 株式会社スマレジ 2024年4月期第3四半期決算説明資料よりこれまで本件の成果を公に報告する機会を作れていませんでしたから、ちょうど2年の節目において、M&A検討時から今日に至るまでのリアルな様子や、黒字転換の背景、その一方で感じた反省や教訓などを振り返りました。当社の取り組みのご報告を兼ねて、今後同様のM&Aを検討されている企業の方に向けて参考となれば幸いです。 スマレジ社のM&A戦略まずはじめに当社のM&A戦略について触れておきます。当社にとってM&Aは成長率向上のための重要な戦略のひとつと位置付けています。いま単一
僕は2018年にPLEXという会社を立ち上げました。それから5年、メンバーは200人を超え、今期の売上は30億円を見込んでいます。資金調達は今のところしていませんが、新規事業への投資ができるぐらいの利益も出ています。 まだまだ「大成功!」とまではいえませんが、この先の大きな成長を見据えられるぐらいには、安定して伸びてきました。 ただ、僕自身は決してビジネスセンスがあるタイプではありません。実は学生時代も含めると4つほど、「なんとなくいけそう」と感覚で事業を作っては、伸びずに潰してしまったんです。 だからこそ、今回は事業を立ち上げる前に入念な「事前準備」をしました。徹底的にリサーチをして、ビジネスの成功パターンを学んで、仮説を検証する。そのうえで事業を立ち上げた。 その結果気づいたのが、 事業づくりにはちゃんと「やり方」があって、実は誰でもできるレベルまで落とし込める ということです。 起業
Amazon Web Services ブログ サーバーレスマイクロサービスを構築するための設計アプローチの比較 AWS Lambda でワークロードを設計すると、コードレベルでもインフラレベルでも表現できるモジュール性のために、開発者に疑問が生じます。また、コードを実行するためにサーバーレスを使用するには、基盤となる機能コンポーネントからビジネスロジックを抽出するためのさらなる検討が必要です。この意図的な関心の分離により、堅牢なモジュール性が保証され、進化的なアーキテクチャへの道が開かれます。 この投稿は同期ワークロードに焦点を当てていますが、他のワークロードのタイプでも同様の考慮が当てはまります。API の境界を特定し、コンシューマと API について擦り合わせた後、その境界と関連するアーキテクチャを構成します。 Lambda 関数を使用して API を構成する最も一般的な 2 つの方
結論話題の記事「UIの色を変えただけで大量のクレームを頂戴してしまった話」を読みました。ユーザーを軽視した内容に驚愕したのですが、それよりも記事が批判されている原因を理解できていない様子の方が存在することに衝撃を受けました。 現職のデザイナーあるいはデザイナーを目指している方々にお伝えしたいことは以下の3点です。 具体的な不都合を訴える問い合わせは無益なクレームではなく有益なフィードバックです。プロダクトの価値向上につながる貴重な意見ですから無視するべきではありません。 時間の経過でユーザーがUIに慣れることはありません。問い合わせをしても無駄だと学習して離脱したパターンを疑いましょう。受け入れられる場合も含めて画面の変更はユーザーに負担を強いているのだと自覚してください。 色覚特性や色とコントラストについて学びましょう。色だけで情報を伝えるデザインはアンチパターンですから避けてください。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く