Re: OSSで世界と戦うために - k0kubun's blog
yusukebe さんの OSSで世界と戦うために を読んで感銘を受けた。 hono の快進撃もさることながら、OSSで日本のコミュニティの外にリーチしたり、 GitHubスター数を伸ばしたりみたいな話は、 自分も10年くらい挑戦し続けているけどあんまり表に出てこない気がするネタなので興奮した。 僕はいくつかの点で上記の記事とは違う方法でOSSで世界と戦っているのだが、 その中でうまく行っているものや、良くないと思っているものなどについて紹介したい。 GitHubのスター数 OSSを始めたばかりの学生時代、GitHubのスターへの執着がもはや煩悩の域であり、 集めたスターの数を合計するCLIツールを作ったり、 同じ計算方法でランキングを作るWebサイトを作ったりした。 このサイトによると、僕の今のスター数は9000を超えている。 自作したOSSの中では、スター数が1600くらいのものが2つ
peercastを作った人
皆さんお馴染みのpeercastですが、peercastを作ったのって誰なのかなーと思って色々調べたら面白いことがわかったので自分用と一部の物好きな人の為にまとめておきます。 @Giles Goddard 彼の職歴は、当時イギリスで最も革新的なゲーム会社であったアルゴノート・ソフトウェア（現アルゴノートゲームズPLC）に始まります。アルゴノート・ソフトウェアと任天堂株式会社の提携により1990年に来日した彼は、スーパーファミコン用ゲームソフト「Starfox」の開発に携わりました。 3Dポリゴン技術を使った初のコンソールゲームである「Starfox」は全世界で発売され、またたく間に人気を集め、大きな賞賛を受けました。また彼は、任天堂株式会社での在職中に、「ワイルドトラックス（海外版タイトル：Stunt Race FX）」、スーパーマリオ64、「テン・エイティ スノーボーディング（海外版タイ
タイミーで、飲食店として凄まじい経験をした話｜Sotaro Karasawa
飲食店経営のなかで、 最も難しい問題の1つはシフト管理である。 賑わうと思って アルバイトをたくさん配置した月末・給料日後の 金曜日にお客様が一組しか来なかったり、平日だしなぁと思ってアルバイトを一人しか配置しなかった日に満席になったり。 そして、最も恐ろしいのは、予約が入っていて、あらかじめシフトをしっかり調整したにもかかわらず、 当日に突然くる病欠などの欠席報告である。 少し前になるが、P2B Haus で6月に起こった突然の事態は、そういった不安のすべてを突いてくる出来事だった。 元々のシフトは社員1 + アルバイト2名、予約が3組合計11名。ウォークインでの来店を想定しても十分な人員配置ではあったが、 前日にアルバイト1名から用事で欠員の報告、 当日朝もう1名のアルバイトから発熱による欠席の報告 他の社員はすでに予定がありどうしても出勤が難しい状況 これはピンチである。 ディナーの
プロジェクトはキックオフが9割 | Marginalia
9割シリーズ この記事は、けっこう前にClassiの社内ブログ記事として書いたものだ。一般論として通用する内容だし、社内に閉じておくのはもったいないと思ったので転載する。 プロジェクトの成功は、キックオフの成功にかかっています。なぜなら、キックオフとはプロジェクトの出発点であり、そのキックオフの準備こそがプロジェクトを始める準備であるからです。 準備に失敗することは、失敗する準備をしているようなものです。 https://www.atlassian.com/ja/work-management/project-management/project-kickoffプロジェクトのキックオフの目的プロジェクトキックオフとは何ですか? それは、プロジェクト チームの...最初のミーティングです。このミーティングは、共通の目標とプロジェクトの目的を確認するための機会です。 キックオフミーティングなし
開発要望タスクの優先度が「高」ばかりで悩んでませんか？ - CARTA TECH BLOG
CTO室 相談室でCARTAの各部署の技術メンター・コーチをしている前田@brtriver です。 自分の仕事内容を説明するのが難しいですが、スタッフエンジニアでいう右腕です！ いろんな部署のサポートをしていると開発要望タスクのリストを確認する場面がよくあります。 そして、その中の「優先度」という項目で正しく優先度をつけることができていない現場が多いと感じます。 そこで、今回はどのように「優先度」を考えればよいかについて私自身が意識していることをまとめてみるので、ぜひ一緒に考えてみましょう。 優先度が「高」だらけになってしまう チケット管理において優先度が「高」だらけになってしまう現象を目にしたことはありませんか？ チケットは困ってる本人が書くため、基本とその優先度は「高」が多くなります。 チケットに残すために書いたとしても、優先度低いタスクはそもそもやらないという判断されることが多く、そ
OpenAI DevDay で発表された新モデルと新開発ツール まとめ｜npaka
以下の記事が面白かったので、かるくまとめました。 ・New models and developer products announced at DevDay 1. GPT-4 Turbo「GPT-4 Turbo」は、「GPT-4」より高性能です。2023年4月までの知識と128kのコンテキストウィンドウを持ちます。さらに、「GPT-4」と比較して入力は1/3、出力は1/2の安い価格で提供します。 開発者はモデルID「gpt-4-1106-preview」で試すことができます。今後数週間以内に、安定した実稼働モデルをリリースする予定です。 1-1. Function Calling の更新「Function Calling」に、単一メッセージから複数のFunction (「車の窓を開けてエアコンをオフにする」など) を呼び出す機能などが追加されました。精度も向上しています。 1-2. 構造
Boolean のカラムを生やす前に考えたいこと
その方が単純に情報量が増えるため 最初 boolean にしてたけど後から時刻もほしくなるということはよくある。後から日時型のカラムに変えようと思っても、過去のイベントの日時は失われてしまっていて困る。今は日時が必要でないように感じても日時にしておく方がよい。 またアプリケーション的に使わなくても、データ分析のためにあると嬉しいことは多い。 コード的にも特に扱いにくくなることはない 以下のようにして簡単に boolean と同じ感覚で扱うことができる。 class Post < ApplicationRecord scope :unpublished, -> { where(published_at: nil) } scope :published, -> { where.not(published_at: nil) } def published? !published_at.nil?
「わかってんじゃん」と思われる議事録を目指して - Qiita
はじめに エンジニア職は、コンサルや営業などのフロント部門と比較すると、議事録を取る必要のあるミーティングの機会は少ないと思います。 それでも製品企画や設計などの各種レビューや、ユーザーへの業務ヒアリングやユーザビリティテストなど、議事録を取る場面はやってきます。 これまで読みやすいと思う議事録に出会うことがしばしばあり、そういった議事録を取れるように精進せねばな、と感じます。 また私自身、議事録を取るのが割と好きで、私がミーティングの主体でない場合、特に依頼されずとも議事録を取ることが多いです。 ・・・まあ、私が書いた議事録について「わかってんじゃん」と言われたことはありませんが、これまで議事録を読んできて、そして取ってきて、ここポイントだな、と感じている点をまとめてみます。 なお今回書くポイントは、私がよく出席する以下の2種類のミーティングの議事録の取り方に寄っていると思いますので、そ
エンジニアの稼働率を上げれば上げるほど機能リリースが遅くなっていく｜mtx2s
組織内のメンバーを「リソース」として見始めると、それを100%使い切ることにばかり注力してしまいます。リソースの稼働率を下げることは、すなわち、生産性を下げること。マネージャーは、まるで強迫観念に取り憑かれたように、そのような考えに囚われます。 自社でのソフトウェアプロダクト開発において、その対象は特に、開発者に強く向けられます。その理由は明らかでしょう。バックログに積み上がり続けるアイデアをソフトウェアに変えられるのは、開発者だけです。より多く、できる限り早く、アイデアを市場投入したい。彼らに空き時間という無駄を作らせてしまうわけにはいかない。 しかし、そのような努力が、必ずしも良い結果につながるとは限りません。むしろ、開発者の稼働率を高めすぎたことが、リードタイムに悪影響を与えているかもしれないのです。そして言うまでもなく、アイデアの市場投入が延びれば延びるほど、ユーザーにとってもビジ
Project Googrename: Google Workspace で 14 年運用されたドメインエイリアスをプライマリドメインに変更 & 全ユーザーを安全にリネームする - クックパッド開発者ブログ
コーポレートエンジニアリング部の id:sora_h です *1。今回は 3 ヵ月ほど前に実施した、Google Workspace テナントのプライマリドメイン変更について、記録を兼ねて説明します。 クックパッドは 2009 年頃 *2 より Google Workspace *3 を利用しています。当社の対外的なメールアドレスは cookpad.com ですが、Google ではプライマリドメインとして cookpad.jp が設定されています。各ユーザーには cookpad.com のアドレスを別名 (エイリアス) として登録されていて、メールアドレスとしては cookpad.com を利用、ただ Google へログインする時だけ cookpad.jp を利用する運用になっていました。想像が出来ると思いますが、これが様々な面で不便・混乱を発生させていました。どうしてこうなった… *
Linus Torvalds 氏の理想の git 運用と GitHub
Note 本記事の内容は Linus 氏の発言が人を傷つける場合に筆者がそれを良しと考えるといった意図はございません 少し古い記事になるが、 Linus Torvalds 氏 の GitHub に対する苦言が記事になっていた。 LinuxカーネルにNTFSドライバーが追加、トーバルズ氏はGitHub経由のマージに苦言 - ZDNet Japan Linus 氏が GitHub について苦言を呈するのは今に始まったことではない（後述）が、 別に GitHub のすべてを否定しているわけではない。[1] では一体何が不満なのか。Linus 氏の理想とする git の開発フローを考察した上で、整理してみたい。 Linus 氏の理想 結論からいうと、 「意味あるコミットを作れ」「コミットを大事にしろ」 という思想が伺える。 では 「意味あるコミット」「大事にされたコミット」 とは何なのか。 筆者な
お願いしなくても毎日その場がやってくる良さ - Mitsuyuki.Shiiba
軽くリファインメントをする時間 いまのチームでは、デイリースクラムのあとに毎日15分だけ、軽くリファインメントをする時間をとっている。目の前のスプリントのタスクのことをいったん忘れて、次のスプリントやもう少し先のことについてチームで相談する時間。 そこでは、PdM（プロダクトマネージャ）が「こういうこと考えてるんだけどどう思う？」って話をしてくれたり、エンジニアが「このあたり早めに改善しておきたいんだよねぇ」って話をしたりしている。 こういう軽い相談の場とは別に、もっと深く議論したいと思ったり、要件がかっちりと決まってきたりしたら、別途時間をとって、軽くないリファインメントでしっかりと相談している。 軽いリファインメントが結構好き 僕はこの日次の軽いリファインメントが好き。自分の「技術的な部分の改善をしたい」という考えをふわっとしてる段階で聞いてもらえるし、PdMがプロダクトの機能追加や改
PyCon APAC 2023におけるNOCコンテンツに関するご指摘について
一般社団法人PyCon JP Association（以下「当法人」といいます。）が主催するPyCon APAC 2023（以下「本イベント」といいます。）においてネットワークオペレーションセンター（以下「NOC」といいます。）が提供するコンテンツの一部につきまして、DNSクエリ情報を収集し、その一部の情報をインターネット上に公開したコンテンツがありました。このようなコンテンツを公開したことについて、下記に詳述する通り、本イベントの主催者として不適切な行為であったと考えます。 本イベント参加者、企業スポンサー、Pythonコミュニティおよび運営ボランティアスタッフをはじめとする関係者の皆様にご迷惑とご心配をおかけしたことを心よりお詫び申し上げます。合わせて、本件に関してご指摘をいただいたコミュニティの皆様には御礼申し上げます。 当法人は本件を厳粛かつ真摯に受け止めるとともに、本件の発生事実
テーブルのカラム名に迷ったんで、英語圏で仕事しているエンジニアに聞いてみた | かきエンジン
テーブル設計をしていて、テーブル名やカラム名を付ける時、英語辞書を参考にするだけでは解決できなくて、様々なサイトを調べながらハチャメチャに悩みつつ「これは英文法的に正しいのか・・・？」と疑問に思いながらも、プロジェクトを進める場面が多いかと思います。 と言う事で、せっかく英語を勉強しているので、テーブルのカラム名を付ける時に判断に悩んだ事を、スペインでエンジニアをやっている友人に聞いてみました。 （仕事は英語でやっていて、以前はオーストラリアに住んでいた） ちなみに、 「ググったけど、いろいろな言い方があるみたいで、結局どれを採用していいのか分かんねーよ！」 というものを主に取り上げています。 「表現方法はいろいろあるけど、システムで使うならこれ」 というのを書いている感じです。 また、変数名や関数名については、すごい議論が活発で、色々な情報が溢れていますが、テーブル名やカラム名については
Working Out Loud(WOL)の取り組みと振り返り - LIVESENSE ENGINEER BLOG
リブセンスVPoEの中野(etsxxx)です。 私はこれまでWorking Out Loud(WOL)というコミュニケーションスタイルを、所属した2チームで実践してきました。最初のチームでは7年、次のチームでは1年ほど運用しています。 最近、他のチームからも取り入れてみたいと相談されることがあったので、改めてWOLについて振り返りをしてみようと思い、この記事を書いています。 WOLとは？ 導入の経緯 1チーム目: WOLの原体験 2チーム目: 意図を持って始めたWOL WOLの導入を振り返る 導入前の課題感 実際にWOL導入初期にやったこと チャンネル削減 会話量を増やすための行動 WOL導入前後の比較 私が気をつけていたこと 積極的に絡みに行く 読み落としを責めない 長文をなるべく送らない 大事なメッセージは目立たせる スレッドが嫌いなことを言い続ける 集中したい時は、チャットを見ないで
リモート開発を助ける「思いやりのある文章」の書き方 - ROUTE06 Tech Blog
新しいプロジェクトに参加してローカル環境を作り始めると、何かとエラーに遭遇します。 また、設計や実装について開発者に相談したり、コードレビューを依頼することもありますね。 開発者が近くにいれば、（それなりに、程よいタイミングを見計らって）話しかけて、エラーの原因を調べてもらったり、設計方法をホワイトボードにスケッチしながら相談できますが、リモート開発ではそうはいきません。 リモート開発で成果を上げるためには、このブログのように何の装飾もインタラクティブ性もない文章で、自分の状況や相談したい事柄を正確に伝える必要があります。 とはいえ私は昔、「文章がわかりにくい」と毎日、毎日上司にフィードバックをもらうくらいには文章を書くのが下手くそでした。今もわかりやすい文章が書けている自信はありません。 それでも、これまでに何度か、議論が好転したり、プロジェクトが前に進むきっかけとなる文章を書けたことが
タケモトピアノ会長、財津一郎さんの訃報に涙の告白「社内で反対されながらCM契約を2か月延長」叶わなかった“最後の挨拶” | 週刊女性PRIME
10月19日、俳優の財津一郎さんが14日に慢性心不全で亡くなっていたことを週刊女性PRIMEが報じた。 財津さんは「ピアノ売ってちょーだい！」のフレーズで知られる中古ピアノの買い取りを行う『タケモトピアノ』のテレビCMに20年以上にわたって出演していた。 バラエティー番組『探偵ナイトスクープ』（ABCテレビ）では、赤ちゃんが泣き止むCMとして検証が行われ、実際に100人近い赤ちゃんが泣き止む結果となった。 財津さんの逝去を受けて、タケモトピアノの竹本功一会長に話を聞いた。取材中、涙声でときに言葉を詰まらせながら、話してくれたこととは……。 20年目の節目で契約を終了した理由 ――財津さんが亡くなられたことは知っていたか。 「先ほどニュースで知りました。財津さんと直接は、もう長らくお話しさせていただいておりませんが、財津さんの所属事務所から“元気でゴルフにも行っている”と、ウチの広報から伝え
個人分担性がスタートアップの成長を殺す �〜協働でチームがめっちゃ進化する話〜
※ スクラムフェス仙台2023 で登壇した際の資料です。 スタートアップでの開発形態は、ウォーターフォールに依存しがちなJTCと違って、プロダクトバックログやカンバンぽいものを使ったアジャイル風の開発をしていることが多いです。 しかし一方で、そういったスタートアップにはプロダクトバックログはあっても、たいていPBIの1つ1つがやたらでっかくて、1つ1つにしっかり担当者がアサインされてて、何ならデッドラインまで記されています。 これを引き起こすのは、スタートアップ特有の個人分担制です。 多くのスタートアップ企業はたいてい、エンジニア1〜2名からスタートし、個々のエンジニアの馬力で開発をこなしていくところから始まります。このときのバリバリ個人開発なノリが、エンジニアが増えても継続してガチガチの個人分担制に移行しがちです。 このセッションでは、個人開発をこじらせたスタートアップ企業がどうやって個
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
はじめてスポンサー運営PMをやってみてわかった4つのこと
📘果てなきデイリーノートの旅路 with Obsidian - Minerva