システムの保守には修繕計画が必要という話 - Innovator Japan Engineers’ Blog
こんにちは、CTOの山岡（@hiro_y）です。 ソフトウェア開発（特にWebアプリケーション開発）に携わっていると「レガシー」という表現をよく聞きます。でもよくよく考えてみると、ソフトウェアは放っておいても腐りませんし、錆びてしまうこともありません。しかし現実問題として、ソフトウェアは放っておくと否応なく「レガシー化」します。どうしてそうなってしまうのでしょうか。 （「レガシー」それ自体は悪い意味の言葉ではないはずですが、不思議とソフトウェア開発の文脈だとよくない意味合いの方が強くなってしまいますね…。） レガシー化する理由とその対策 動いているソフトウェア自体が変化しなくても、周りの環境が変化します。OSのバージョンが上がったり、その上で動いているミドルウェアが変わります。また、最近だとクラウド環境を利用することが多いので意識することが減りましたが、ハードウェアも新しいものがどんどん出
わたしたちにIaCはまだ早かったのかもしれない
AWS Startup Meetup #13 LT 登壇資料です。 Infrastructure as Code（IaC）を導入したものの、IaC化した恩恵が思っていたより少なく、IaCで基盤を統一していく方針を転換していった話をご紹介します。
2022年の技術トピックをふりかえる - laiso
それはベンツなんよ 総括 今年はコードをよく読むようにした。 技術的にはひき続きPaaSやクロスプラットフォームの動向に注目した。 デファクトの移り変わりを感じるので来年以降はGoやGraphQLに手を出していきたい。 去年のエントリ: 2021年に作ったモノや技術をふりかえる 今年やったこと コード読み 去年はコードを書くことに注力していたので今年は一転コードを読んでいた。 プログラム雑談ポッドキャストを聞いていて「コード読み」っていう言葉がよく出てくるので聞きながらそういえば自分もこの分野が好きだなと思い出したので意識してやることにした。 丁度、最新技術のトレンドだけ俯瞰しているのに学びを感じなくなってきたのでより潜りたい気持ちがあったのでそれを満せたと思う。 IntelliJ IDEAで全言語のプログラミング環境が楽に揃っているのが心強い（Samuraismさんありがとう）。 読んだ
エンジニアのスキルマップ・テックリードへの途 - 電通総研 テックブログ
みなさんこんにちは。電通国際情報サービス(ISID) 金融ソリューション事業部の水野です。 これは電通国際情報サービス Advent Calendar 2022の16日目の記事です。 今回は、ISID金融事業部で運用しているスキルマップについてご紹介します。 テックリードとは 実は、ISIDの少なくとも金融事業部にテックリードと言うポジションはありません。 実在するのはチーフアーキテクトと言う職種のみで、各プロジェクトでリードエンジニアやテックリードという仮想的なロールがあるのが実態です。 一時期はフルスタックエンジニアと呼んでいる時期もありましたが、近年このワーディングが好まれない印象なので、大々的に使っていません。 主観ですが、フルスタックエンジニアはインフラ知識／運用系の知識のウェイトが高いエンジニアで、テックリードはソフトウェアアーキテクチャ、Webアプリケーション実装技術寄りのエ
「変わらない」を貫いた先に。少年ジャンプ＋がマンガ業界のゲームチェンジャーになるまで - ミーツキャリアbyマイナビ転職
「特別何かを変えようとは思っていませんでした」 そうつぶやくのは、集英社のマンガ誌アプリ「少年ジャンプ＋（以下、ジャンプ＋）」の副編集長、籾山悠太さんです。 今やネット上における話題作の“発信源”ともなっているジャンプ＋。ブラウザ版と連動してソーシャルバズを促す仕組みや「初回閲覧無料」の制度など、マンガ業界の常識を塗り替えるような施策を次々と打ち出してきました。 しかし、立ち上げ当初は社内リソースもヒット作もない、小さな媒体だったといいます。さらに、立ち上げ人の籾山さんは編集畑出身で、異動するまではデジタルの知見もほぼなかったそう。 そんな状況で籾山さんが参考にしたのは、技術的なトレンドでも、横文字の並んだ数値目標でもなく、「週刊少年ジャンプ（以下、ジャンプ）」の創刊時から社内に脈々と受け継がれる「ジャンプの思想」でした。 インターネットもSNSもない、約50年前に生まれた「ジャンプの思想
RESTful のウェブ API 設計で避けるべき 6 つのよくあるミス | Google Cloud 公式ブログ
※この投稿は米国時間 2022 年 12 月 1 日に、Google Cloud blog に投稿されたものの抄訳です。 オンラインで、組み立て式のテーブルを注文したとします。ところが、パッケージを開けてみると、組立説明書が入っていません。完成品がどんなものかはわかっていても、それぞれのパーツをどう組み立てればいいのか、まるでわかりません。設計が不十分な API を使うコンシューマ開発者も、同じような経験をしているといえます。適切に設計された API なら、容易に見つけ、検索してアクセスし、使用することができます。高品質の API は、コンシューマ開発者がアイデアをひらめき、新しいユースケースを作り上げる手助けになってさえくれます。 もちろん、API 設計を改善する方法はあります。たとえば、RESTful のプラクティスに従うなどです。しかし、お客様が知らず知らずのうちに、ちょっとした不便
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
