Tech blog
Linuxサーバーの運用で「/etc/security/limits.conf を書き換えたのに実は反映されていなかった…」という経験はありませんか？ 「確かにulimit -nで確認していたはずなのに、なぜ！？」
このような状態は、すぐにではなく時間がたって忘れたころに問題として現れます。。
今回、実際に詳細な比較検証を通じて「なぜ limits.conf だけでは不十分だったのか」そして「どうすれば全経路で確実に設定を反映できるのか」を3つのステップで解明しました。
これを機にあいまいな理解を整理して同じ失敗が起きないようにしておきましょう。
続きを読む
Tech blog
Tech blog
皆さんこんにちは。
GXソリューショングループの板橋です。
前回は、「システム開発プロジェクトのゴールは、安定した運用の状態に設定したほうがいいですよ」という話をしました。
今回は、システム開発失敗の大きな原因とその背景について少し掘り下げて考え、私のグループで実践している対策を少し紹介したいと思います。
※今回も文字成分多めになっちゃいました（ﾃﾍ
続きを読む
Tech blog
こんにちは！AX研究室庄内です。
私たちは、ある日を境に、それまで当然だと思っていた前提が覆ることがあります。
今日はMETRとOpenAIの記事を手がかりに、AIの現在地と、その変化のなかで私たちが何を見極め、どう備えるべきかを考えてみたいと思います。
Tech blog
ご無沙汰しております。エコモットの板橋です。
ブログを書くのは５年ぶり（前回はコードのコメントについて記載しました）になりますね。
わたしは相も変わらず、プロジェクトリーダーとして開発プロジェクトが無事に終わるようにガイド役に徹している日々を過ごしております。
今回は、開発プロジェクトにおけるゴールの設定と罠について少しお話したいと思います。
続きを読む
Tech blog
こんにちは！
SJC共同開発推進室の坂根です。
S3 で長期データを保管していると、コスト最適化のために Amazon S3 Intelligent-Tiering（以下、Intelligent-Tiering）を使っているというケースも多いのではないでしょうか。
アクセス頻度に応じて自動で階層を切り替えてくれるため、運用負荷も少なく、とても便利な仕組みだと思います。
そんな中、先日こんな場面に直面しました。
「半年以上前のデータを確認したい」と思い、S3 を開いたところ、オブジェクトは確かに存在しているのに、すぐに取得できない……。
対象は数万件。1件ずつ復元するのは現実的ではありません。
そんな状況を解消すべく、S3 Inventory・Athena・S3 Batch Operations を使って一括復元を試してみましたので、その方法をご紹介します。
Tech blog
おはようございます、こんにちは、あるいはこんばんは。またも前回執筆から約半年が経過、
>相も変わらず遅筆が身上、お久しぶりのクラウドソリューション開発部 伊藤です。
以前の記事では、「要件定義」工程の原理原則について取り挙げました。
前回の結びで、「次回はより実践的な内容で、お会いしましょう！」などと言ってしまったものだから、テーマ探しもまあ大変。
どうしたものかと頭を悩ませてみましたが……ここは敢えて奇を衒わず、上流工程の最上流にして花形(というイメージのある)工程、
「ヒアリング工程」についてお話しいたしましょう!
なお、本記事は「要件定義 ヒアリング工程」解説記事の前編となります。
まあまあ長くなりましたが、どうぞお付き合いください(このブログ見てるってことは時間あるでしょ)。
この記事を読むのにかかる時間は 約10分 くらいです！
Tech blog
おはようございます、こんにちは、あるいはこんばんは。
以上前略、クラウドソリューション開発部 伊藤です。
今回は続編記事！というか長すぎて分割になった
というわけで本編前置きはサクサク終わります。
要件定義入門シリーズ、「ヒアリング」編の中編となります。
えっ、こんな記事が三部作？と思いました？
いやいや、どうせ時間おありでしょう？活字読むのがお好きなんでしょう？
きっとそうだと信じて。
能書きはさておき、前編では「ヒアリング」工程の「下準備」について解説しました。
前編を読まずにこちらを開いたあなた、それこそ「準備」が足りない。
とりあえず前編を読んでいただいてから、またお会いいたしましょう。
前編も履修済だぜ！という方は、いよいよ「ヒアリング」の本筋について、
お付き合い願います。例のごとくちょっと長いよ！！
この記事を読むのにかかる時間は 約10分 くらいです！
その他
来月に結婚式を控え、大忙しの毎日を送っている新郎
クラウドソリューション開発部の市川です！
気づけば入社して丸2年が経とうとしています。4月からはついに3年目…
「新人」という言い訳がそろそろ通用しなくなる時期に、少しの緊張と、それ以上のワクワクを感じています。
今回は、この1年を振り返りつつ、最近私にできた「初めての後輩」とのエピソードを交えて
この数ヶ月間、後輩と一緒に試行錯誤してきた日々を振り返ってみたいと思います。
Tech blog
デバイスソフトウエア開発部の本間です。
最近、弊社業務にて Android アプリの保守を担当する機会がありました。そのアプリには自動テストが存在しなかったため、安全に改修を進めるための回帰テストとして、まずユニットテスト（JUnit）を導入しました。
しかしテストを書き始めると、クラス同士が直接依存していたり、I/O などの副作用が各所に埋め込まれており、既存コードに変更を加えなければユニットテストが難しいことが分かりました。そこで、モッキングフレームワークである Mockito を導入することにしました。これにより依存先を任意の処理（モック）へ差し替えることが可能となり、ユニットテストを実施することができました。
本記事では、その際に使った Mockito の機能を、実例を交えてご紹介します。
