ソフトウェア開発の進歩完全に止まったような気がする
(ゲームの話は一切知らん) いつのまにか「Webフロントエンドの動きが速い」とか誰も言わなくなってることにふと気付いた。なんというかソフトウェアをどう作るか、という問題にたいして大枠の部分では完全に固まってしまって、あとは個別の事情をどうやっていくかみたいな話しか残ってないように見える。 端的にいえば、宣言的UIとkubernetesは聖杯だったのではないかな。 k8sにかんしては「Cloud Runみたいのでいいじゃん」みたいな話はあると思うんだけど、Envoyほしいとかなってくると結局事実上k8s必須だし、今新しくアプリ作るときに宣言的UIじゃないフレームワーク使うこととかほぼ考えられんよな。で、こういう構成が定番ですね、みたいになってなんかもう数年は経つ気がする。結果として日本語でソフトウェア開発の話になるとチームビルディングがどうのみたいな話しかなくなってきていて、なんかつまんねー
サーバーアプリ開発環境(Python／FastAPI) | フューチャー技術ブログ
Pythonでお仕事する前提で、現在のところで自分が最適と考えるチーム開発のための環境整備についてまとめてみました。今までももろもろ散発的に記事に書いたりしていたのですが、Poetryで環境を作ってみたのと、過去のもろもろの情報がまとまったものが個人的にも欲しかったのでまとめました。前提としては次の通りです。 パッケージ管理や開発環境整備でPoetryを使う 今時はコードフォーマッター、静的チェックは当たり前ですよね？ コマンドでテスト実行、コードチェックとか実行とかができる（CI/CD等を考えて） VSCodeでもコマンドで実行しているのと同じコードチェックが可能(ここコンフリクトすると困る） デプロイはDockerイメージ コンテナのデプロイ環境でコンテナに割り当てられたCPU能力を比較的引き出せて、スケールさせたら線形にパフォーマンスアップできるようなasyncioを前提とした環境構
Webパフォーマンス虎の巻
Webパフォーマンス向上施策のために、今更ながら超速本1を読んだので、今までの自分の知見と合わせてまとめてみます。 なるべく柔らかく、改善施策ってまず何をどうすればいいの？という疑問を持った人に向けて書いています。 ▪️格言 そもそもWebは速い。遅くしているのは我々です。大抵は技術の問題ではなくて、人の問題。 引用元： テクニックではなく、今、本気で取り組むべきWebパフォーマンス （html5jパフォーマンス部 部長 竹洞さん） 心得 パフォーマンス向上に対する施策は大別すると以下の２通り 軽量化 （単純にやりとりするデータ容量を小さくすること） 圧縮 削除 最適化 （その時に最も適している実装・実行をとること） 経路・順番の変更 非同期 もっとも遅くしている原因を探して、それを対策するのが原則。「対効果」が絶対的正義である。手段から入るのは愚策。まず先に原因を知ることが重要。 ▪️1
Webサービスによくある各機能の仕様とセキュリティ観点（ユーザ登録機能） - Qiita
この記事の目的 課題: Webサービスの各機能の仕様に関するセキュリティ情報があまりない Webサービスを設計するにあたり、よくある機能というのが存在するかと思います。 ユーザ登録 ログイン・ログアウト パスワード復旧 URLで共有 SNSログイン お気に入り登録 いいねボタン マイページ 通知 等・・・ これらに関して、自分の認識をまとめておきたい・意見をもらってブラッシュアップしたいと思い、記事を書きます。 大きい記事たくさん書くの大変なので、機能ごとに書こうかな・・・と思ってますが一つを育てていくかもしれないです。 前書いた記事が個人的には好評だったことも受けて、書いています。 ユーザ登録機能の仕様とセキュリティ toC向けサービスならかなりの割合で存在する機能です。よくある仕様パターンについて考えてみます。 この機能でユーザから取得するもの 認証情報（ID/パスワード） 連絡手段
Webアプリケーションの全体像を掴む - Qiita
プログラミングしかしらない。。。 私は会社で主にサポート対応を担当しています。不具合が見つかったりすると、その原因を特定し、修正をするといった仕事です。 ただ一概に不具合といっても、プログラミングのコードが生み出したバグが原因のときもあれば、Webサーバにアクセスが集中してパフォーマンスが低下することが原因のときもあります。 プログラミングに触れ始めてから2年が経過しましたが、私はプログラミングのことしか勉強してきませんでした。Webアプリケーションがどのように構成されているのか全く知らないがために、不具合の調査するときに原因を特定できないといったことを何度か経験しています。 このままだと効率力よく不具合調査を進められないことを危機に感じ、入門書として「プロになるためのWeb技術入門」という本を手に取りました。 これは何の記事か？ プログラミングしか学んでこなかったエンジニアが「プロになる
サービス終了のお知らせ - NAVER まとめ
サービス終了のお知らせ NAVERまとめは2020年9月30日をもちましてサービス終了いたしました。 約11年間、NAVERまとめをご利用・ご愛顧いただき誠にありがとうございました。
チームでウェブ制作をする時に必要だったこと – vanillate
とりあえず少人数で、ウェブ制作とかスケジュールとか勘でやっちゃってて、 「できちゃってた」人用。 沢山のプロジェクトを抱えていると、脳みそのリソースがまず足りなくなります。 「簡単なことなのにどうしてできないの？」と自分を責め、鬱状態になるまえに、 いちどこれらの項目を見直してみてください。 いつまでに、何を、だれがするか。 いわゆるスケジュールなんですけど、スケジュールなんて言葉にするだけで なんか大げさな気分になりますね。 当たり前のことを、確認しあいましょう。そして、相談しましょう。 何を言ったらいいかわからない位混乱したら、 それも伝えられるチームは理想です。 見える化する とにかくなんでも見える化してください。 簡単なメモだけでなく、それは一体どんな手順を踏んで、 どんな風にこなしていくのか。 未来への自分への手紙でもあり、 突然誰かにお仕事をお願いする時にも役立ちます。 お金（
技術が変われば分業体制も変わる - masayang's diary
昨日のシステムエンジニア不要説とも関連。 id:kwatch さんからトラックバックをいただいたので、ちょいとコメント。まず、RailsConfの報告で書いた37signalsの事例だけど eRubyでXHTMLの大枠を記述するのはRubyエンジニア そのeRubyの編集をデザイナにも解放せよ デザイナがeRuby構造を壊したとしても、テストで検知できるし、最悪リポジトリから戻せるではないか リポジトリの概念はCSSの階層構造を理解できるデザイナなら、すぐに習得できる デザイナが先にHTMLテンプレートを作成し、プログラマがそれを参照にeRubyを書くという古典的手法では、「先に画面デザインを確定させる必要がある」ということになり、Agileの持ち味をぶち壊すことになる。 という内容であった。（あとでまとめると言っておきながら、まとめてなかった。申し訳ない。） で、id:kwatch さん
中小企業や個人経営規模相手のWebディレクションで気をつけている１５のこと。 | 笑顔を創りたいＷｅｂ屋の日常
笑顔を創りたいＷｅｂ屋の日常 Ｗｅｂ業界からひょんなことで専門学校の先生に。そしてまたＷｅｂ現場に戻ったＷｅｄディレクターのブログ。情報デザインやＷｅｂの勉強をしています。 あくまで”僕が”です。そこ大変重要ですｗ 僕もまだまだ勉強中で、これが全て正しいと思えるほど見極めていません。 他にもあるだろうし、もっと大事なものもあるかもしれません。 それは各々考えてもらって（もしよろしければ教えていただいてｗ）、とりあえず同タイプの仕事している人の叩き台にでもになればなと思って挙げてみた次第です。 というのもですね、僕はWeb屋としてみるとなんか物凄く変な経歴・経験をしている人なのですねｗ まあ、Web業界って割と他業界から来る人たくさんいますけどね。僕は印刷会社→大手Weｂ制作会社→専門学校教員（正規職員）→弱小ITベンチャーなので、なかなかこういう奴はいないと思いますｗ 教員とか普通はできま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TechEmpower Framework Benchmarks
【魚拓】Webエンジニア業界に感じた違和感 - Qiita