Re: 28: レイオフと Return To Office の話 - Middle Aged Developers #madevs - @kyanny's blog
レイオフは会社のお金が実際にあるかないかというよりも、株価・株主を意識して行われるものだということを今回初めて知ったというか認識した。お金が少なくなってきた・このままだとなくなるから節約する、というロジックではなく、株価が下がったので・下がらないように予防的に対応するもの、というか。つまり実際にお金が少なくなってから手を打っては遅すぎる、ということなのだろう。 最近知人が「レイオフは絶対値ではなく相対値で行われる」と言っていて、それも新しい認識だった。ビッグテック企業が絶対値としてはものすごい金額を稼いでいる、それは事実なのだが、目標・予想に届かなかったのでレイオフ、というロジック。「儲かっていればレイオフしないされない・儲かってないからレイオフする」のではない、という。「儲かっている」の定義の問題、とも言える。 GitHub 完全リモートに移行の話 パンデミック前から元々、過半数が完全に
なぜ我々は筑波大を便利にすることができなかったのか？ - いなにわうどん
早いもので筑波に来て 3 度目の春を迎えます。2 年前の春を憶えていますか。 筑波大学を便利にするサークルが爆誕 元々は大学の KdB と呼ばれる開設科目データベースがダウンし、その代替サイト「KdB もどき」を作成したことに端を発します*1。懐かしいですね。 ミラーを立ち上げただけと言えばそうなのですが、新入生が大学をディスりながらシステム開発！みたいな構図が予想以上にウケたっぽく、Twitter がバズったりメディアに取り上げられたりしている間にサークルを新設する流れになりました*2。 togetter.com 筑波大には学生が開発した数多のサービスやアプリケーションが存在しますが、その多くは個人レベルで開発が行われているため、開発者が大学を離籍するとシステムが保守されなくなる傾向にあります*3。そこで、筑波大学の学生生活を便利にする各種サービスを総括的に管理・保守することで持続可能な
Deno のめっちゃ難しいバグを修正した - Qiita
2022年4月、Deno に以下のバグが報告されました。 fetch API を使って 300KB ぐらいあるファイルをアップロードすると、一定確率でアップロードされたファイルが壊れるというバグの報告です。 報告者によれば、1.20.6 まではバグは発生しておらず、1.21.0 から発生するようになったという事です。1.20.6 の次のリリースが 1.21.0 なので、パッチバージョン1個分まで、バグの発生時期が特定されている状態です。 fetch 周りは自分はほぼ実装していないので「担当範囲ではない」感覚だったので、普通にスルーしていました。 自分に限らず、Deno Land コアチームの誰もこの issue にピンと来る人が居なかったようで、stale ボット (数ヶ月進捗の無い issue を自動的にクローズしようとするボット) に2回もクローズされかけていました。Deno の st
How I/we got 2k stars - ゆーすけべー日記
Honoという僕が作っているWebフレームワークのGitHubスター数が2,000に迫ってきた。これまで作ってきたOSSのソフトウェアでは最高で revealgo の221、次点で gh-markdown-preview の134だ。それが一気に2,000である。 もちろん、スターの数がソフトウェアの良し悪しを決めるものではない。 それに2,000はとりわけ多いわけではない。 でも、以前の自分には遥か彼方に見えていた数を獲得できたのは、とても嬉しいことだ。 去年12月から作り始めて9ヶ月間、552コミット。 今や使ってくれる人も増えた。 cdnjs のAPI Serverのバックエンドにも使われているし、 HonoをきっかけにGitHubスポンサーをしてくれている企業や人も現れている。 なにより、いろんなことを勉強させてもらった。 今回はHonoというプロダクトがどうやって2,000のスタ
「雑に立てられるissue」で疲弊しないためにOSS開発者ができること - 2021-12-04 - ククログ
要約：OSS開発プロジェクト運営者の側でとれる対策はいくつかあるよ。issueは基準を設けてどんどん閉じてしまおう。GitHubならActionsで自動化も簡単だよ。自動テストを整備するように、必要なコストだと思って割り切るといいよ。 結城です。 GitHub Actionsに関することならなんでもありらしいアドベントカレンダーとのことでしたので、ほんのちょっとかすっているだけではありますが、4日目にエントリーさせて頂きます。 「軽率に寄せられる報告や要望がOSS開発者を疲弊させる」という問題について語るOSS開発者は少なくないです。私の観測範囲内では最近も、イシュートラッカーにissueを立てようとすること自体に待ったをかける記事1や、「要望には初手で『なぜ自分で実装しない？』と訊ね、次に『継続的にメンテナンスしてくれるの？』と訊ねるドライな対応がおすすめ」という趣旨に受け取れる発言など
リモートワークについてテック業界が誤解していること | Coral Capital
テクノロジー業界のリーダーたちからは「これからはリモートワークだ」という意見をよく聞くかもしれません。TwitterやSquare、Shopifyなど、いくつかの大手企業は、本人が希望すれば無期限でリモートワークを続けられるような制度を導入したと最近発表しました。世界で最も華やかかもしれないキラキラしたオフィスを、何千億円もかけていくつも作ったあのザッカーバーグでさえ、今後5〜10年の間にFacebook社員の50%がリモートワークへ移行するだろうと言っています。新型コロナウイルスによって世界中でリモートワークへの大規模な取り組みを試行錯誤しつつ進める必要に迫られ、私たちは今、明らかに今世紀最大の働き方改革の1つの真っ只中にいます。 例によって、今回の改革においてもテック業界がその最先端にいます。コロナウイルスをきっかけにリモートワークへの試みがはじまる前から、多くのテック企業ではオフィス
アメリカで、ソフトウェアエンジニアの日本人がインパクトのある仕事をする方法 - メソッド屋のブログ
アメリカに移住してもうすぐ４ヶ月ぐらいになるけど、こちらに来てから面白いほど成果が出ていない。 最初の２ヵ月ぐらいはなんやかんやで仕事にならんやろうなと思っていたから、気にもしなかったが、そろそろ４ヵ月なので、流石に焦りを感じて来た。何一つ仕事が完了しない。日本で仕事をしていた時はこんなことは発生しなかった。こっちの方が一緒に働いている人が同じタイムゾーンだし、近いし、やりやすいはずなのに何故だろう？焦っていても何も改善しないので、直接仕事をしているクリスと、日本人エンジニアの先輩の河野さんに話を聞いてみた。自分の会社限定かもしれないけど、学んだことの記録と、もしかすると誰かの役にたつかもしれないから書いておこうと思う。 仕事が完了しない焦り 何だろう、この仕事の完了しないっぷりは。いくつか、終えたらインパクトがある仕事があるのだが、これがまた完了しない。一緒に働いているエンジニアの人はみ
オープンソース製品の「仕様」 - 赤帽エンジニアブログ
Red Hatの佐藤匡剛です。昨日、Red Hat Forum / Tech Nightにお越しいただいた方、ありがとうございました。 昨日のRed Hat Tech Night冒頭のトークセッションで、id:nekopこと木村さんから面白い発言があり、Twitterでも話題になっていたようなので、ちょっとフォローアップの記事を書きたいと思います。 「これは仕様ですか？」 と聞かれても、たまたま開発者がそうしただけというケースもあり、答えにくいことが多々ある #rhtn2018— 転職しても肉の妖精だった件 (@nanodayo) November 8, 2018 仕様が先かコード書いた人の気持ちが先か #rhtn2018— えいご (@enagok) November 8, 2018 実装がたまたまそうなっているw とても分かる。#rhtn2018— 水無月 忠司 (@longyoru)
コードレビューのレビューはマネージャーの仕事 | POSTD
経営に関する名著「 High Output Management （邦題：ハイアウトプット・マネジメント（＝高い成果を可能にするマネジメント））」の中でAndy Groveは、”トレーニング（訓練・教育）はマネージャーの仕事”であり、組織の成果を向上させるためにマネージャー（経営者・管理者）が実践できる最高のレバレッジ活動だと述べています。 多くの組織のマネージャーにとって、この言葉は現在においても参考にできる素晴らしいアドバイスでしょう。しかし、現代のソフトウェア開発チームのマネージャーに関して言うと、その中心となる考え方はシフトしています。 > エンジニアリングチームの成果向上にとっては、GitHubのプルリクエストなどで実行するコードレビューが、今では最大のレバレッジポイント（レバレッジの作用点）である。 品質管理以上の役割 従来、コードレビューのプロセスは品質管理のツールと見なされ
✓DO、X DO NOT の誤訳事案
だいぶ炎上してる例のあれ doの意味が全体的に逆になっています。 #118 対応ミスってるとはいえさすがにかわいそうなレベルでいいがかり付けられてる感じもするのでちょっと補足を。 元々の問題 マイクロソフトの機械翻訳がよくやらかすのはいつものことなんですが。 今回は何をやらかしたかというと、よくある ✓DO: 〇〇してください X DO NOT: 〇〇はしないでください みたいなやつを、DOもDO NOTもどっちも「しないで」と訳してしまっているという問題。 「しないで」も不自然だし、ましてDOの方は真逆の意味になっているという誤訳。 どうしてこうなる… みたいな気持ちはもちろんあるものの、こういう「普通の文章」になっていない部分の単語ってのは、機械翻訳では一番ミスを起こしがちな部分です。 たぶん、原文の時点で何らかのアノテーションでも付けておくとかしないと、今後も同様の誤訳は起こりまくる
GitHubリポジトリで8000スター獲得、人気OSS「Boostnote」オープンソース化の軌跡 - エンジニアHub｜Webエンジニアのキャリアを考える！
GitHubリポジトリで8000スター獲得、人気OSS「Boostnote」オープンソース化の軌跡 GitHubリポジトリで8000スターを獲得しているプログラマ向けノートアプリのBoostnote。グローバルな開発コミュニティを築き上げた経緯についてインタビューしました。 Boostnoteというアプリをご存知でしょうか？ こちらはElectronで作成されたデベロッパー向けのノートアプリ。実は海外ではとあることでとても有名なアプリなのです。 なんと企業が事業として開発しているアプリにもかかわらず、コードをすべてオープンソースとしてGitHub上に公開しているのです。海外を中心に注目度は高く、世界中のコントリビューターがBoostnoteに携わっています。現在、GitHubのスター数が8000を超える人気のOSSとなっています。 Boostnoteはどのようにグローバル展開とし、どのよう
リモートワークの事例を話してきました at “ITワークで青森暮らし”｜福井 烈 / note inc.｜note
かれこれ半年程前になるのですが、2017/10/21(土)にITワークで青森暮らしという将来UIJターンを考えている方向けのイベントで、 「Uターンにおける青森で就職 or 起業以外の選択」 というタイトルでリモートワークの事例を話してきました。 忙しさにかまけて資料をpublicな場所に公開するのを忘れていたので、今更ながら公開します。(最近入社した方への自己紹介の意図もあったり.....) 場所が品川のマイクロソフトさんだったので、ちょまどさんに会えるかもとか淡い期待を抱いていたのですが残念ながらお会い出来ませんでした。 ※リモートワークはテレワークとほぼ同義です 発表内容アジェンダとしては、 ・ リモートワークをするにいたるまでの経緯 ・ ピースオブケイクでリモートワークをどのように実践しているのか ・ 2年間のリモートワークで得た知見や課題, 工夫している点 ・ リモートワークをす
リモートチームでの働き方 - Hatena Developer Blog
こんにちは！はてな東京オフィスでアプリケーションエンジニアをしている id:KGA です。 はてなで毎週開催している技術勉強会で「リモートチームでの働き方」と題し、自分以外のメンバーが全員京都オフィスにいるチームで2年間仕事をしてきた経験から心がけるようになったことを発表しました。今回はその発表資料を公開します。 speakerdeck.com 最近では東京オフィスにもエンジニアやデザイナーなどの開発メンバーが増えてきましたが、それでもまだ半数以上のメンバーが京都オフィスに勤務しているというチームも少なくありません。どのチームも規模や状況によって試行錯誤しながら様々な取り組みをし、働きやすいチームを作ることを目標に東京・京都双方で力を合わせ日々改善を行っています。 僕自身、入社当初から東京オフィスに1人だけというチームで働いていて、やはり最初は大小様々な問題に直面しました。そんな中で他のチ
CoolなソロとHotなペアプロのあいだ
チームでプログラミングをする際、幾つかのスタイルが存在します。どの場面でどのスタイルを使うかについて経験を元にご紹介します。 https://commons.wikimedia.org/wiki/File:Pair_programming_1.jpg一人が黙々とプログラミングするソロのスタイル、ソロでプログラミングしつつも「（WIP）プルリクエスト」のオンライン上「コードの共同所有」で集団で洗練させていくスタイル、２人が同じタスクを同じディスプレイを共有し対話しながら難しい問題を解いていく「ペアプログラミング」スタイル、複数人がホワイトボードと巨大なディスプレイに集まって寄ってたかって、議論しながら開発する「モブプログラミング」スタイル、などがプログラミングスタイルとしてよく知られています。 しかし、実際の開発の現場では、「ソロプログラミング」「プルリクエスト」「コードの共同所有」「ペアプ
非英語ネイティブにとってのOSSのメンテナンスコスト - once upon a time,
disclaimer: この記事を書いている人はClouderaというHadoop/Sparkのディストリビューターの会社にいます。 codelunch.fmの20回目を聞いていろいろ思うところがあったのでつらつら買いてみます。 codelunch.fm この回のcodelunch.fmでは、前職の同僚である丸山さん（@h13i32maru）と@hokacchaさんが、お互いの家庭環境の変化を交えながら個人プロダクトの開発について話しているエピソードです。これ自体なかなかおもしろい回なので、趣味でプロダクト開発している人は聞いてみるといいんじゃないかなと思います。 丸山さんはJasperやESDocを精力的に開発していますし、hokacchaさんはnodebrewやadventarを作られています。彼らの話していた、個人で趣味プロダクトを開発するモチベーションは何かというところは、以下のよ
Linuxの開発者であるLinus Torvalds氏がGitHub上でプルリクエストを受け付けない理由 | スラド Linux
ストーリー by hylom 2016年11月29日 21時01分 少なくともGitHubのみに依存しないのは正しいと思う 部門より Redditで「This is why Linus doesn't accept PRs from GitHub」（LinusがGitHubからのプルリクエストを受け付けない理由がこれだ）という画像が話題になっている。 ここで言われている「Linus」は、もちろんLinuxの開発者であるLinus Torvalds氏。この画像は、GitHub上のLinuxのリポジトリに対する「Delete duplicate word "long long" in Introduction」（イントロダクション中でダブっている「long long」という単語を削除）いうプルリクエスト。これに対し、ほかの開発者からが「long long」は単語がダブってるわけではなくそういう
オープンソースプロジェクトを最初から英語で運営してみてわかったメリットについて｜Rui Ueyama
僕は最近とあるオープンソースプロジェクトをオーナーとしていわば運営しているのですが、英語でプロジェクトをまわすというのは良いなと思うようになりました。他の言語を使うのに何も悪いことはないのですが、英語のほうがコミュニティがずっと大きいので想定外の幸運なことが起こる可能性が高くなるというのが理由です。 僕がやっているプロジェクトは開発ツールを作るというもので、それなりに専門的な知識が必要になるプロジェクトです。人間が書いたプログラムのコードは最終的に何らかの形でコンピュータが直接実行可能な形に変換されて実行されるわけですが、僕が作っているリンカというのは最後の実行ファイルを作成する部分を担当するプログラムです。つまり僕はプログラムを出力するプログラムを書いているわけで、そのためにはOSやCPU、入力や出力のファイルの形式などについてよく知っている必要があります。 また僕らの目標は既存のものよ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
先輩から教えてもらったコードレビュー
チームでプロダクト開発するための取り組み/cookpadtechconf2017
Geek Women Japan keynote
