結論から言うと、ピースオブケイク改めnoteは、アグリゲータとしてのポテンシャルが高すぎて、プラットフォームになれないかもしれない。でもプラットフォームになりたそうで、その為には方向性の調整が必要だと思う。 結論を言うだけならツイートに収まるので、僕なりの分析を、以下書き留めてみる。 目次 プラットフォーム is 何 そろそろnoteの話を 「を」vs「で」 もうひとつの違和感ーコロナに関する但し書き Facebookという教訓 Twitterという警鐘 プラットフォームでいるには さいごに プラットフォーム is 何 そもそも「プラットフォーム」とは何だろうか。「民主主義」とかもそうだが、それが意味するところの輪郭がぼやけているのに、何となく「良いこと」になってしまいがちな言葉だ。なので一先ず定義するところから始めたい。さいわい最近だとBen Thompsonという兄ちゃんがいて、彼のブ

きっかけ 昨年(2021年9月ごろ)に徳丸さんのこのツイートを見て、「2022年にはJWTを用いたセッション管理に代表される、ステートレスなセッション管理は世の中に受け入れられなくなっていくのだろうか？」と思っていました。 OWASP Top 10 2021 A1に「JWT tokens should be invalidated on the server after logout.」（私訳:JWTトークンはログアウト後にサーバー上で無効化すべきです）と書いてあるけど、どうやって無効化するんだ? ブラックリストに入れる?https://t.co/bcdldF82Bw— 徳丸 浩 (@ockeghem) 2021年9月10日 JWT大好きな皆さん、ここはウォッチしないとだめですよ。これがそのまま通ったら、ログアウト機能でJWTの即時無効化をしていないサイトは脆弱性診断で「OWASP Top

ITエンジニアが投票した「ITエンジニア本大賞2022」ベスト10発表。「シェル・ワンライナー160本ノック」「モノリスからマイクロサービスへ」「恐れのない組織」など 「ITエンジニア本大賞」は、仕事の役に立った本、初学者におすすめの本、ずっと手元に置いておきたい本など、おすすめの本をITエンジニアがWeb投票で選ぶイベントです。 主催は翔泳社ですが、対象となる書籍は出版社を問わず技術書、ビジネス書全般となっています。刊行年も関係なく、これまで大賞に選出された書籍を除き、この1年を振り返っておすすめしたい書籍が対象となります。 今回発表されたのは技術書部門とビジネス書部門それぞれのベスト10です。現時点では50音順に並んでいます。 このなかから特に投票の多かった技術書3冊、ビジネス書3冊について、同社が2月17日と18日に開催する「Developers Summit 2021（デブサミ20

突然ですが、ここに一つのプロダクトがあるとします。 そのプロダクトを見つめる視線には様々な種類があります。 そのプロダクトを利用しているユーザーの視点、利用していないが存在は知っているという人の視点、それをつくるデザイナーの視点、プロダクトを運営している会社経営者の視点… もしあなたがデザイナーであれば、デザイナーの視点だけが唯一自分で体感できる「主観」で、それ以外はすべて「客観」となります。 主観と客観のスイッチング プロダクトデザイナーはユーザーの期待通りに正しく動くしくみを設計し、「このプロダクトを利用した時に、ユーザーの生活はどう変化していくのだろうか？」と問いを立てながらアウトプットを評価していきます。 自らの考える理想像をデザインしながら、一方でそれに触れるユーザーの様子を想像する…プロダクトデザイナーは主観と客観を電気のスイッチのように瞬時に切り替えることに長けた人が多いイメ

著書54冊!? エンジニアかつ「数学ガール」著者の結城さんが語る、エンジニアのメンタルマネジメントのすゝめ

webpack/lib/config/defaults.js 実際に使うときの設定 結論ですが、webpack.config.js へ以下のように書くことが推奨されます。 module.exports = { cache: { type: "filesystem", buildDependencies: { config: [__filename], }, }, }; あとは、各コードの設定に依存するためversion等の追加が必要になる可能性があります。 ドキュメント Other Options | webpack webpack is a module bundler. Its main purpose is to bundle JavaScript files for usage in a browser, ... 仕組み ファイルキャッシュでは以下のようにデフォルトではnode_m

はじめに 業務中、ふと「雰囲気でコードレビューしてしまっている」ということを自覚しました。 そこで、コードレビューにおいて気をつけていること、こうすればさらに良くなりそう！を言語化してみました。 「雰囲気レビューを卒業したい」、「コードレビューの質を向上・体系化したい」といった方はぜひ読んでみてください。 ✊ レビュアーの役割 レビュアーが果たすべき重要な役割として、システムの品質を保証することが挙げられます。 要件不十分 不具合 コード品質低下 などの発生責任は、レビュアーにも共有されます。 それらの発生を防ぐために、レビュアーが心がけるべきことをについて書いていきます。 👀 コードレビューの視点 コードレビューのときに特に見るべき観点は、大きく分けると以下の３つです。 仕様を満たしているか バグが含まれていないか コードの品質が低くないか 1と2は言わずもがな重要です。死ぬ気で見まし

はじめに コードレビューを依頼するとき、どんな気持ちでお願いしていますか？ 自分が始めたての頃は、「チェックしてもらえてありがたいなあ」くらいの考えでした。 コードレビュー依頼とは、いわば責任の共有依頼です。 つまり、本質はそれほどカジュアルなものではありません。（依頼しやすい関係性は別として） コードレビューを通したレビュアーには、品質の保証をしたという責任が伴います。 通したコードが不利益を生んだ場合には、レビュアーも責任を負わなければなりません。 そのリスクを負ってもらうことに対し、レビュー依頼者（reviewee, 以下レビューイと呼びます）」が果たすべき義務は、レビュアーが最小限のコストで効果的にレビューできるように最大限努力することです。 その努力の具体的な方法を、以下に書いていきます。 効果的/効率的なレビューをしてもらうために 👨‍💻 開発で気をつけること レビューに必

2020/09/26 Scrum Fest Mikawa 2020で発表した資料です。 セッションの詳細は下記からご参照ください。 https://confengine.com/scrum-fest-mikawa-2020/proposal/14699

LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog LINEの開発組織のそれぞれの部門やプロジェクトについて、その役割や体制、技術スタック、今後の課題やロードマップなどを具体的に紹介していく「Team & Project」シリーズ。 今回は、フロントエンド開発組織の中で、ユーザ向けサービスのWebフロントエンドを担当しているチームについて紹介します。フロントエンド開発センターの清水大輔、縣亮太、折原レオナルド賢に話を聞きました。 ユーザ向けサービスのWebフロントエンドを担当しているチームのzoom会議の様子 ―― まず、自己紹介をお願いします。 清水：システム開発会社で図書館システムや金融・物流の開発などを担当した後、2009年5月にネイバージャパン（現LINE）にフロントエ

Next.js + Electron を使えばめちゃくちゃ簡単にデスクトップアプリを作れるという記事です。 デスクトップアプリケーションをWeb技術で作成するElectronを、むちゃくちゃ久々にやってみたら、とても簡単になっていた React のフレームワークである Next.js もバージョン9.xになってから劇的に良くなり続けていて、どんどん触りやすくなっています ちなみに Next.js は非公式な日本語翻訳が進んでいるようです。 9割くらい翻訳が完了しているようですが、気になる方は、このサイトの「翻訳プロジェクトについて」をご覧ください。 セットアップする # npmの場合 $ npx create-next-app --example with-electron-typescript hoge $ cd hoge $ npm run build $ npm run start

XP祭り2020 #xpjug で発表した内容です。 コードレビューが教育に良い理由と、 更に効果を高めるTipsを紹介しました。

本記事は、 「なぜ仮想 DOM という概念が俺達の魂を震えさせるのか」 https://qiita.com/mizchi/items/4d25bc26def1719d52e6 の 2020 年版のリライトです。 2014 年当時、日本においては React は未だ知る人ぞ知るライブラリ、という位置づけでした。それが、この記事によって一気にメジャーになったように思います。 オリジナルは2014 年末の情報によって書かれたもので、さすがに 6 年経った今では情報が古くなっており、当時の暗黙のコンテキスト、古いリソースの参照、初学者の混乱を招く表現が残ったままになってしまっています。 定期的に更新しようとも思いましたが、そうすると 2014 年末の歴史的な背景を失ってしまうため、あえてそのまま残し、新しい記事を投稿することにしました。増補改訂版というより、ほぼ書き直しです。 この記事は本来なら

米村歩@日本一残業の少ないIT企業社長 @yonemura2006 「技術的負債」という言葉があります。要するにちゃんとシステムを構築しないと後で多く利子を払うことになってしまうということです。無茶な納期や金額でシステムを作らせてたまたまうまくいったら最初は得した気分になるかもです。しかし後々の改修やらメンテやらで莫大な利息を払うことになります。 2020-06-24 07:49:11