タグ

2024年2月25日のブックマーク (10件)

  • 飲み会を1,000回やって学んだ、「最高の飲み会」のつくりかた(長い)|udon

    (この記事は全文無料で公開しています) これは何人生を30年、会社員を10年やってきたが、飽き性であまりずっと続いてることがない。10年続いてることがあるとすれば相方との関係、書くこと、そして飲み会である。稿では、20歳以後一貫して取り組んでいる飲み会についての1個人の知見を極めて真面目に記したい。ここ10年でだいたい週3-4くらいはコンスタントに飲み会をして、そのうち体感6-7割は自分で企画しているので1,000回以上は飲み会を主催してると思う。その経験をもとに学んだことを書きたい。 なお、査読をお願いした相方には「長すぎ。強いられないと最後まで読む人はいない」と愛の鞭(?)をもらった14,500字ですが、必要な際に参照され、どこかの誰かには染み渡る箇所があればいい(ダシみたいですね)と願い、そのまま出します。 わいわい飲み会とは稿では、あくまで個人が娯楽目的に開催する会について記し

    飲み会を1,000回やって学んだ、「最高の飲み会」のつくりかた(長い)|udon
    hush_in
    hush_in 2024/02/25
  • HonoXについて

    2月9日、予告していた通りHono v4をリリースしました。 そのHono v4のリリースと同時に、Honoを使ったメタフレームワーク「HonoX」を公開しました。 今回はHonoXのいくつかの特徴について書いてみたいと思います。これは使い方というより作者目線の思想みたいなものです。 メタフレームワーク HonoXとは一言で言うと「HonoとViteを組み合わせたメタフレームワーク」です。HonoX自体が機能を提供しないのが肝です。 もう少しだけ具体的に言います。HonoXで扱うのは「Honoのインスタンス」そのものです。つまりあなたがHonoXでアプリを作るということは「Honoのアプリを作る」ことになります。その証拠にエントリーポイントになるapp/server.ts内で出てくるappはHonoのインスタンスなので、hono/devにあるヘルパー関数showRoutes()がそのまま使

    HonoXについて
  • 新規サービスのバックエンド開発で3ヶ月経ったので、試した技術や取り組みをまとめてみた

    こんにちは、AIShift バックエンドエンジニアの石井(@sugar235711)です。 AIShiftでは去年の11月からAI Worker[1]という新しいサービスの開発が始まりました。(以下AI Worker) 格的に開発が始まり3ヶ月弱経ったので、その間に試してきた技術やチームの取り組みについてまとめてみたいと思います。 はじめに この記事では、AI Workerのおおまかな概要・設計を説明し、それらのバックエンドを実現する上でどのような技術を試してきたのか、技術以外でのチームの取り組みについてまとめます。 少し分量が多いので、ライブラリについての情報を求めている方は、目次から気になる部分を読んでいただければと思います。 何を作っているのか ざっくりまとめると、Microsoft Teams/Web上で動くAIを活用した業務改善プラットフォームを作成しています。 GPTとRAG

    新規サービスのバックエンド開発で3ヶ月経ったので、試した技術や取り組みをまとめてみた
  • SaaS アーキテクチャ概要

    SaaS をアーキテクトをするにあたって、どのような事を考えればよいのか?をまとめました。

    SaaS アーキテクチャ概要
  • 令和最新版エンジニアのリーダーシップ論 - エムスリーテックブログ

    エムスリーエンジニアリンググループ製薬企業向けプラットフォームチーム(「Unit1」)の三浦 (@yuba)です。乗り物大好き男の子ですので好きなテレビ番組は銀河鉄道999とナイトライダーです。 さて「フラットな組織」だとよく言われるエムスリー、特にわがエンジニアリンググループなのですが、そのフラットってどういう感じなんでしょう? 上意下達の体制でない中では、人々はどう組織としての目標を共有して一緒に動いているんでしょう? この疑問への、(管理職でない)一般エンジニアとして5年半やってきた私なりに得た答えをご紹介したいというのが今回のお題になります。これは エムスリー Advent Calendar 2022 の5日目の記事です。前日は id:hsasakawa による グローバルサービスの開発における技術的な意思決定 - エムスリーテックブログ でした。 そしていきなり最初に結論から言っ

    令和最新版エンジニアのリーダーシップ論 - エムスリーテックブログ
  • TanStack Router(& Query)はSPA開発で求めていたものだった✨【Reactのルーティングとデータ取得】

    React技術選定においてルーティングとデータ取得は特に重要な役割を担っています。 もちろんNext.jsやRemixのようなフレームワークを採用すれば、個別のライブラリを追加することなくルーティングからデータ取得までフレームワークが提供するAPIを使って実装することができます。 しかし、AI ShiftのようなBtoBのサービスにおいてはSPAで十分なことがほとんどで、Next.jsなどのフレームワークの採用がtoo muchになりかねません。 この記事は2024年2月時点の技術選定において、TanStack RouterがSPAのルーティングライブラリとして非常に有力な候補であることを紹介します。 はじめに TanStack RouterとTanStack Queryの採用がSPAアプリケーションにおける最適解の一つになりうることをその特徴と実際の設計例をもとに解説します。 TanS

    TanStack Router(& Query)はSPA開発で求めていたものだった✨【Reactのルーティングとデータ取得】
  • Blueskyメモ - 日誌(は)

    Blueskyは見た目はTwitter/Xみたいだけど、お金持ちが買収してめちゃくちゃにするのを防ぐのを目標として、そのための仕組みをいろいろ用意している、というところがTwitterとは違うところです(この公式ブログの記事で「billionaire-proof」と表現してます) Twitterの創業者であるJack Dorseyがきっかけで始まったプロジェクトで、彼は今でもBlueskyのボードメンバーではあるっぽいのですが、今はBlueskyの開発や運営にはほとんど関わってないようです ※1 ※2。最初の出資者ではありますが、現在はもっと多くの出資者がいます。今はnostrを中心に活動してます 2024年2月23日に、BlueskyのPDSのフェデレーション(連合)というものが始まりました。Blueskyが分散SNSであると言われるために必要な第一歩です。PDSってのはユーザーの投稿、

    Blueskyメモ - 日誌(は)
    hush_in
    hush_in 2024/02/25
  • なぜ、エンジニアの"フロー状態"は見落とされるのか? 継続的なフロー状態が開発生産性を高める

    前回は「開発生産性」という言葉の広さから、きちんと組織のレイヤーを構造化しながら用語を分けてオーバーラップする部分を繋げていきましょうという話を紹介しました。第2回となる今回は、開発チームに焦点を当てていきます。ソフトウェア開発の現場では、Four Keysを中心とした「開発生産性のメトリクスはどうあるべきか」 や「認知負荷を下げるエコシステムはどう設計するべきか」といった議論が頻繁に行われています。こうしたソフトウェアアーキテクチャから生まれる開発生産性に関する議論はとても重要であり効果が高いものです。記事ではそうした議論とは少し離れ、「エンジニアの継続的なフロー状態が生む開発生産性への重要度と、組織が開発チームに対する不安の定量化によるフロー状態の軽視がなぜ起こるのか」という観点で解説します。 以前の記事 【第1回】「開発生産性」はエンジニア"だけ"のモノではなくなった?──開発組織

    なぜ、エンジニアの"フロー状態"は見落とされるのか? 継続的なフロー状態が開発生産性を高める
  • React Server ComponentでもContextで状態を共有する | フューチャー技術ブログ

    Next.jsの最近の大きな目玉機能はReact Server Component(以下サーバーコンポーネント)です。パフォーマンスアップに有効だったり、gRPCだRESTだGraphQLだ論争を終わりにするServer Actionsなど盛りだくさんです。 一方で、サーバーコンポーネントはコーディング上の制約がいろいろあります。 サーバーコンポーネントではhooksが使えない サーバーコンポーネントのソースからクライアントコンポーネントはimportできるが逆はできない。レンダーツリーを工夫すればクライアントコンポーネントの下にサーバーコンポーネントを配置することは可能 サーバーコンポーネントでは非同期コンポーネントを作成でき、fetchでサーバーから情報をとってきたり、DBアクセスした結果を利用できます。しかし、最近のモダンReactの場合、状態管理などはすべてhooksに寄せるので大

    React Server ComponentでもContextで状態を共有する | フューチャー技術ブログ
  • 米Gizmodoの元記者、退職時にSlack上の名前を「Slackbot」に変えて数か月間なりすましていたことを告白 | テクノエッジ TechnoEdge

    ガジェット全般、サイエンス、宇宙、音楽、モータースポーツetc... 電気・ネットワーク技術者。実績媒体Engadget日版, Autoblog日版, Forbes JAPAN他 ビジネス向けIT技術情報サイトIT Brewのシニアレポーター、トム・マッケイ氏は、所属していた米Gizmodoを2022年に退職した際、Slackアカウントの名前を「Slackbot」に書き換え、その後数か月間、偽SlackbotとしてこっそりアクセスしていたことをX(Twitter)で明かしました。 マッケイ氏は、このことについてGizmodoの親会社であるG/O Mediaが「何か月も発見も削除もできなかった」と述べています。 Slackbotとは、Slackユーザーの特定の投稿に対して自動的にレスポンスを返したり、リマインダーを知らせたりする機能を持つBotのこと。 条件や応答内容を設定してカスタマイ

    米Gizmodoの元記者、退職時にSlack上の名前を「Slackbot」に変えて数か月間なりすましていたことを告白 | テクノエッジ TechnoEdge
    hush_in
    hush_in 2024/02/25