2010年頃まで前半の時期の方がよく覚えているが、後半は記憶が飛んだように覚えてなない所が多かったりとかで、たぶん、こんな感情だったのに違い無いという感じで書いた所もあったり
なぜ「すべてのジャンルはマニアが潰す」と言ったか すべてのジャンルはマニアが潰す。これまでの私の発言の中で最も物議を醸し、また最も広く知られている言葉です。一部の熱狂的なファンの要望を受け入れ続けると、新規ユーザーが入りづらくなり、その結果ジャンルは衰退してしまう、ということを指摘しました。 一番初めにこの言葉を使ったのは、新日本プロレスがブシロードのグループ会社になったときでした。当時は新日本プロレスを、前向きに大きく変化させなければいけませんでした。そのために外野の声をいったんシャットアウトしたかったのです。 ある程度の反発は予想していましたが、要はコアなファンに「しばらくは口出ししないで見守っていてほしい」というお願いだったわけです。 その頃は新日本プロレスに限らず、すべてのプロレスファンが「このままでは日本のプロレスはなくなってしまうかもしれない」という危機感を持っていました。です
F5、NGINXの開発チームをロシア国外へ移転させたことを報告。開発を立て直しリリースサイクルも元通りに NGINX(エンジンエックス)はオープンソースで開発されているWebサーバとしてもっとも人気のあるソフトウェアの1つです。その開発者であるIgor Sysoev(イーゴリ・シソエフ)氏がロシアの首都モスクワに住んでいたことなどにより、NGINXの開発はロシアの首都モスクワを中心に行われていました。 そのロシアは現在、ウクライナへの武力侵攻に反対する西側諸国による厳しい経済制裁下にあり、多くのIT企業もロシアにおける活動を停止しています。 2019年にNGINX社を買収し現在NGINXの開発元となっているF5も、ロシアにおける営業活動とNGINXオープンソースプロジェクトへの貢献を停止したことを、3月15日付けのブログ「Standing Firm in Support of the Pe
Cygamesから4/1にリリースされたプリコネ!グランドマスターズのサーバーサイドとインフラ開発をCysharpが開発協力しました。リアルタイム通信を含むオートバトラー系のゲームです。 Cysharpはサーバー側のアーキテクチャ設計と基盤実装、クラウドインフラ構築、一部サーバーロジック実装を担いました。リアルタイム通信部分だけではなくてAPIサーバーからマッチメイキング、インフラまで、構成されるあらゆる要素がC#で作られています! クライアント (Unity) API サーバー(MagicOnion) バトルエンジンサーバー (リアルタイム通信; MagicOnion, LogicLooper) マッチメイキングサーバー (リアルタイム通信; MagicOnion) バッチ(ConsoleAppFramework) デバッグ機能サーバー (Web; Blazor) 管理画面サーバー (W
「アジャイルサムライ」の著者が語る、技術志向の企業が世界をどう見ているのか? そしてソフトウェアテスト自動化を進化させる方法について(前編)。JaSST'22 Tokyo基調講演 Jonathan Rasmusson(ジョナサン・ラスムッソン)氏はアジャイル開発における著名人の一人であり、さまざまな先進的ソフトウェア企業において開発やテストに携わってきました。 日本ではアジャイル開発の入門書として話題となった書籍「アジャイルサムライ」(オーム社,2011)や「初めての自動テスト」(オライリー,2021)、「ユニコーン企業のひみつ」(オライリー,2017)の著者としても有名です。 そのラスムッソン氏が2022年3月10日と11日の2日間、ソフトウェアのテストに関わる国内最大のイベント「ソフトウェアテストシンポジウム 2022 東京」(JaSST'22 Tokyo)の基調講演に登壇しました。
闘神3面白かったですよ。 私はやりこみました。僥倖という言葉が出てきて調べたのを覚えてます。 付与システムでどうすれば最高のセッティングができるかいっぱい試しました。 読むゲーム?はALiveZ以外ではあしたの雪之丈以来でしたが、低価格シリーズで、欲張りサボテンとかしまいまとか、全部ちゃんと買ってやりました!! 東京開発室のことがホームページに出たとき、そんなに大企業になるなんて、ひょっとしたら他の分野に進出か!?でも、エロゲー作るって書いてあるし、、、???と気になっていたので少しスッキリした気分です。 返信削除
人気アニメ「機動戦士ガンダム」シリーズの生みの親、アニメーション監督の富野由悠季氏(80)が、毎日新聞などのインタビューに応じた。話題は故郷の神奈川県小田原市にとどまらず、地球の環境問題や教育に及んだ。2021年に傘寿を迎えた巨匠の言葉に、今こそ耳を傾けたい。 小田原の風土が生んだストーリー ガンダムは、人類が宇宙進出する時代を描いている。宇宙に建設した植民地(スペースコロニー)が地球連邦に独立戦争を挑み、兵器としてのロボットを操るパイロットたちが巻き込まれていく物語だ。勧善懲悪ではない筋書きには、故郷の風土が全面的に反映されているという。 「(小田原は)海のものでも山のものでもない、偏りがないところにワールドワイド性があった。だから、作品の中でイデオロギーを持った人をテロ集団にできた。田舎の小さな町だが、住みやすい良いところで、箱根や熱海を背負っている。明治から大正にかけて別荘地帯でもあ
YAPC::Japan::Online 開催めでたい キーノート光栄 オンライン開催 id:onishi さんに先んじてしまった YAPC::Kyoto 中止残念でした (延期とのことです) 今後のオフライン開催に期待 新しいハイブリッドな形にも Discord活用いいですね Me id:Songmu (ソンムー) Masayuki Matsuki / 松木雅幸 Launchable / プリンシパルソフトウェアエンジニア おそらくはそれさえも平凡な日々 https://www.songmu.jp/riji/ https://metacpan.org/author/SONGMU 60+ CPAN Modules / 200+ GitHub repositories 3 Times ISUCON Winner Using Perl 「みんなのGo言語」共著者 ghqメンテナ 認定スクラムマス
ボランティア開発者が「反乱」。もっとオープンソースに還元されるべき?(山口健太) - 個人 - Yahoo!ニュース これいろんな意見がありますよね。オープンソース・オープンソースコミュニティ大好きなので開発者・ユーザーにとって良い方向に進むといいなと思います。 それとは別に、オープンソース開発者の義務について思うこと。 OSSに好き勝手に要望を出すことは良いと思う。 「だったら自分でやれよ」って言っちゃうとフィードバックが無くなっちゃうので。 それと同時にOSSコミッターが持つ最大の権利が、 「要望を無視すること」 かな〜と思いました。(要望を「反論する」「却下する」ではなく「無視する」) 「好き勝手に要望を出すのはOK」ただしコミッタは「スルーする権利」を持つ。 好き勝手な要望に全部向き合わないといけないのではコミッターの体が持たないんじゃないかな〜と思います。 この「スルーする」って
■ マネジメントの極意は「自分のことは棚にあげる」こと タイトルは https://qiita.com/jnchito/items/0a0b46106681f41f2f0e のインスパイアです。 昔エンジニアなどをやっていた時に、マネージャや上司から何かコメントを受けると「とは言っても、このコードも書けないのにさあ」というような気持ちになった経験から、自分が実際にマネジメントをする立場になると、「は〜、React とかあまりわからんので方針とか出しにくいなあ」となって止まってしまうことがあります。 昨今のソフトウェアエンジニアリングは幅も深さも異次元のレベルまで広がっているので、全てのことをマネジメントが実践できるというのは正直無理な話です。自分ができることしかマネジメントできないなら、ソフトウェア開発の世界では何もできないのに等しいです。 そこで必要なことは「自分のことは棚にあげる」です
SOULVARS (App Store 610円 / GooglePlay 610円) 無名のインディーゲームスタジオの処女作ながら、発売されるや有名作品をぶち抜いてアプリストアでRPG1位を獲得し、話題になっているゲームがある。 ひとりぼっちインディーゲームスタジオ、ginolabo (ジーノラボ)が制作した『SOULVARS』だ。 基本無料ゲームが全盛のスマホで、610円買い切り完全新規のド硬派RPG。 スタイリッシュで小気味よい動きのドット絵で魅せ、オート不可・戦術制が高く歯ごたえのあるバトルシステムで攻めるこのゲームにハマってしまい、筆者は買ってすぐに2周クリアしてしまった。 やり込み要素も多く、2周しても飽きないこのゲームを作っているのはどんな人物なのか、本当にひとりで開発しているのか。 どうしても気になってしまい、今回は作者、ginolabo のジーノさんにお話を伺った。 SO
みなさんこんにちは。@ryuzeeです。 昨年12月に新刊『チームトポロジー』が発売になったのでぜひよろしくお願いします。 アジャイルコーチや技術顧問の仕事は多岐にわたりますが、その1つに社内での講演やセミナーがあります。 今回、技術顧問先のイベントで登壇しましたので、その際の資料を公開します。 アジャイルとは直接関係ないものも多々含まれていますが、ネタということでご了承ください。 アジャイル全般QCDSを同時にすべて固定することはできない要件の決まったものを早く・安く作る方法ではない開発だけをアジャイルにしても意味がないアジャイルで請負契約は無理だと心得ようすべてがアジャイルに適しているわけではない大規模アジャイルは小さなアジャイルの成功後アジャイル導入を支援しようアジャイル推進での組織的な課題に取り組もう無駄な社内プロセスを廃止するよう働きかけよう効率ではなく成果に着目した組織設計をし
2009年から新卒&修士卒で約12年勤めていた株式会社 東芝を退職しました。 正確には2021年の9月末には退職していて、10月からは別の会社で働いております。 東芝では様々な方々にお世話になり、色々な経験を積むことができました。ありがとうございました。 やっていたこと ソフトウェア技術センターという研究所の機関でソフトウェアにまつわる色々な研究、開発をずっとやっておりました。雑に括るならソフトウェア工学という分野全般です。あまり公開できる情報は多くはないのですが、ソフトウェアメトリクスの研究、社内のソフトウェア開発環境の整備や、深層学習を使ったバグ検出の研究などをやったりしておりました。 組織としてのサイトはこちらのリンクから確認できます。近年取り組んでいた活動が大体はまとまっていると思います。ここに載っていないものでも、事業部から委託を請けて色々な開発活動も行っている部門となります。
www.shoeisha.co.jp 最近、開発方法論や組織論に関心をもっています。2020年改訂スクラムガイド を読んだり、実際に業務でもスクラムを実践している開発チームで働いています。しかし、まだスクラム開発者として働き始めて2ヶ月なので新人です。これまで私はスクラムを実践している開発チームで働いたことがなく、いま初めてスクラムチームで開発者として実践しています。とはいえ、チケット駆動開発 + イテレーション開発 は10年以上実践してきており、厳密な定義では正しくないかもしれませんが、広義ではアジャイル開発という枠組みで開発を実践してきたと私の中では捉えています。そして、私の周りでうまくまわっていないスクラム開発をみかける度にチケット駆動 + イテレーション開発でうまくいくのになぜスクラムのような効率の悪い開発をしているのか?とすら内心では思っていました。 本書を読み終えて、結論から言
arm Mac と向き合う Web アプリケーション開発環境 しない話: Docker Desktop の課金回避 問題意識 Mac の CPU が arm になってしまった結果、以下のような問題がある JVM 系を中心に amd64 な Docker image が Mac で挙動が怪しい ネイティブ開発すっか!!となるとライブラリのバンドリングとかでおかしいことになりがち Ruby の nokogiri とか ネイティブだと古いものはわりと動かない そういう問題がなかったとして arm で開発したものを amd64 環境にデプロイするのはちょっと勇気がいる。 古い環境はアップデートせえやという話なのだが、リソース不足してるものはどうにもならず、結果として古い JVM 環境を延命させてたやつとかはまじでどうにもならなくなったりする。えてしてそういうものは皆さんの手元にあることでしょう。
ソフトウェアエンジニアにとって、技術的負債が増え続けるソフトウェアプロダクト開発現場に身を置くことがどれほど苦痛なことであるか。エンジニアリング組織のマネジメントを長年担ってきて、それは強く感じるところだ。 中途採用の選考プロセスに面接官として参加し、これまで数多くの退職理由を見聞きしてきた。その中で、レガシーシステムをリファクタリング・リアーキテクティング・リライトできないことへの不満を理由として挙げるエンジニアは多かったように思う。裏を返せば、自社のソフトウェアプロダクトが技術的負債にまみれたまま放置されているなら、優秀な人材が他社に流出するリスクがあると認識すべきだ。 本稿では、技術的負債と開発者体験の関係について紐解くとともに、それに対してソフトウェアエンジニアリング組織を預かるマネージャーが取るべき行動について考えてみたい。 ※これは、Engineering Manager Ad
みなさんこんにちは。@ryuzeeです。 12月1日に新刊『チームトポロジー』が発売になったのでぜひよろしくお願いします。 スクラムの認定コースでも基礎的なコースでも、よく聞かれるのが大規模の場合の対応についてです。 そこで、今日は大規模の場合の選択肢になりそうな大規模アジャイルフレームワークを紹介します。 紹介しますが、最初に大事なことをお伝えしてから紹介します。 そんなにたくさん作っても使わない2019年にプロダクトマネジメント関連のSaaS企業であるPendoが行った調査によると、ソフトウェアプロダクトにおいて平均的な機能の利用状況は次のようになったそうです。 まったく使わない: 24%ほとんど使わない: 56%よく使う: 8%いつも使う: 12%つまり80%の機能はほとんど、もしくは、まったく使われないということになります。 たくさんの人を集めて、たくさんの機能を作るのは、ムダであ
はじめに こんにちは!Google Cloudでオブザーバビリティの担当をしているものです。CVE-2021-44228のおかげでバタバタしていますがみなさんはお元気ですか? このエントリーはpyspa Advent Calendar 2021の15日目の記事です。昨日は @moriyoshit さんの「Goのロギングライブラリ 2021年冬」でした。めちゃめちゃ調べてあって良い記事でした。Goでログライブラリの選定をする際にはこちらをまず読むと良さそうです。 2021.12.21 追記: 穴が空いていたのでGo Advent Calendar 2021 その1の14日目の記事にもしました。 さて、今日は本当は「Goならわかる確定申告第三表」という記事を書こうと思ったのですが、まだ確定申告の時期ではないのでそれは辞めにします。そのかわり、今日はGo 1.18がめでたくベータ版リリースとなっ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く