https://gihyo.jp/magazine/SD/archive/2025/202512
一度確立された技術は何年経っても変わらないというのはまさに科学的で面白いなと思った. 理由をきちんと学ぶというのは大事ですね.
自動化するとはいってもこれまでなかった問題が出てくるんだろうなと思う. 障害になったら解決するにもなかなか難しそうではある. 新たなビジネスができるということかもしれない.
それでも、たとえばコンパイラの授業に本気で頑張って取り組んだところ、100人くらいいる受講生の中で僕が圧倒的にトップの成績を取ってしまいました。すべての課題と中間、期末テストでクラス最高点というパーフェクトな成績です。
笑った. こんな人はなかなかいないのでやはり大学というのは良い学びの場と言えるのかもしれない.
部分的に知っている内容もあるものの, 全体として背景知識や概念は理解していなかったので, こういうまとまった内容で知れるのは良かった. 個人的には「第4章：B2B SaaSにおける認証基盤構築の実際IDaaS採用から内製化まで」 が他社事例として面白かった. IDaaSに関する内容が中心なのでしかたがないが, もう少し Keycloak に触れてほしい気持ちがある. 認証基盤の選定基準が星取表でさらっと終わっているようにみえる.
最近の話題として面白い. けっきょくは責任所在としてヒトが介在する必要があるということかもしれない. SQLインジェクションみたいにこれから一生言われる話題になっていくのかもしれない.
タイムリーでなおかつ高度な話題なのでネット上よりもこういった雑誌で読めるのはいい感じ. 個人的には既知の部分があり, 一般向けにブラケット記法と量子状態を説明するにはこういう感じになるのかという面白さがあった.
Java 21 から Java 25 に絞ったアップデート内容でかなり詳しく書かれていて, これだけ読んでおけば大丈夫 👍. JavaのLTS移行で気になる廃止や非推奨の部分も丁寧に書かれていて, これだけ読んでおけば大丈夫 👍. Javaは最近でもGCとかが頻繁にアップデートされていて, Javaのバージョン上げるだけでパフォーマンスが上がるというのは嬉しい.
面白い. モバイル特有の難しさというか紆余曲折あって大変そうという感想.
しかしながら当時のSUZURIにはiOSエンジニアが1人と、Webと兼任しているエンジニアが1人という、約1.5人分の人手しかなかったため、Webブラウザからの利用者数などを考慮するとiOSアプリに集中するという判断をしていました。
SUZURIみたいなところでもリソースは厳しいんだな...
2020年の初頭に、当時在籍していたエンジニアとデザイナーがたまたま同じタイミングでFlutterを個人的に学習していました。SUZURIではREST APIを公開しているため、エンジニアが個人的な技術の学習をする際にもAPIを使っています。その学習の中でFlutterでSUZURIのAndroidアプリを作っていたエンジニアがいました。それがある種の技術検証となり、ネイティブと比べてかなり速い開発速度でAndroidアプリが作れそうと判断し、本格的にFlutterでAndroidアプリを作ることを決めました。
エンジニア個人としてはとても良いエピソードだけど, 企業としてはこういうのを奨励していくための仕組みを作るべきなんだろうな.
プロンプトやカスタムインストラクションで多くの要件を伝えたとしても、そのすべてを満たすコードを一度に生成することはできません。そのため、コードレビューという形のフィードバックを行い、それに対応したコードに改善するプロセスが必要です。
それはそう.
AIによるコードレビューはやわらかい Linter みたいなものでボトムアップには良さそうだが, それでもヒトによるレビューを完全になくすことにはならないと思う.