Backlog UI リニューアルの舞台裏 / Backlog Renewal UI2017年4月13日の「DevLOVE 関西『デザインリニューアルの難しさ』」にて発表された、Backlog UI リニューアルの舞台裏のスライドです。
JUnitのNestedなMethodSourceの注意点 - 日々常々
JUnit 5.8.1 Java 17.0.1 IntelliJ IDEA 2021.2.3 JUnit5での @MethodSource のおさらい JUnit5にはパラメタライズドテスト用の @ParameterizedTest があり、様々な方法でパラメーターを与えられます。 その中でもパラメーターにある程度柔軟性が欲しい場合によく使うのが @MethodSource で、テストメソッドのパラメーターを生成できます。 import org.junit.jupiter.params.ParameterizedTest; import org.junit.jupiter.params.provider.MethodSource; import java.util.stream.Stream; import static org.junit.jupiter.api.Assertions.a
デスマーチが起きる理由 - ３つの指標
鳥のさえずり声を聞いて、私は悪態を吐いた。今日の早朝に予定されていたミーティングのことをすっかり忘れていたのだ。 まったく、最悪の朝だ。着替えている間に、電話も鳴った。「高い金を払ってコンサルタントを雇った極めて重要なミーティングだ」と念を押されていたというのに。 それもこれも昨日のバグのせいだ。睡眠時間も、開発スキルも、人員も、私の現場には何もかもが足りていない。 それにも関らず、理解の足りない上司は「テスト工程を削ってでも早く納品しろ」とプレッシャーを与えてくる。 あの馬鹿どもめ。一体何を考えているんだ？ スーツに着替え終わった私は、冷蔵庫の缶コーヒーで空腹を誤魔化すと、バイクに跨った。通勤時間が5分なのが、せめてもの救いだ。 「遅れてすまない」 そう言って会議室に入ると、奇妙なことに気がついた。教室のように整然と並んでいたはずの机が、即席の半円形に並べ替えられていた。 何より、ホワイ
開発チームをインシデント対応に慣れさせてくれる「インシデント対応チェックリスト」の導入 | 株式会社ヌーラボ(Nulab inc.)
SRE課で、主にBacklogのSREを担当しているMuziです。 Backlogでは2019年8月から、アプリケーションの障害については、開発チーム自身が対応できるオンコール体制を取っています。これにより、サービス影響の少ないアプリケーション障害については開発チーム自身で対応できるようになりました。 しかし、サービス影響の大きいものについては依然としてSREの対応が必要な状況が続いていました。この問題を解決するために、インシデント対応をするオンコール担当者のためのチェックリスト（以下、インシデント対応チェックリスト）を新たに考案し、今年の7月から導入しました。 今回の記事では、このインシデント対応チェックリストの詳細に加えて、導入に至った背景からその効果までご紹介します。開発チームへの運用ノウハウの移管について悩んでいる方の参考になれば幸いです。 Backlogのオンコール体制 元々、B
開発のスピードを上げたいならすべてのスコープを小さくしよう
ピナクルズの CTO をしている渋谷です。「現場向け動画 DX」を実現するための SaaS『tebiki』を開発しています。 今回は、「プロダクトの開発スピードを落とさずに、かつユーザーの芯を食ったソリューションを提供するためには、すべてのスコープをいかに小さくできるかが重要」だということについて書いてみたいと思います。 ちなみに弊社はこれを実践することで開発がものすごくスムーズになり、リリース頻度が体感で 50% くらい向上しました！ スピードは失われていく前提として、プロダクトの開発スピードは意識的に改善し続けなければ、機能の追加とともに失われていきます。 提供する機能の増加に伴い、仕様の辻褄合わせだとか実装の順番だとかの複雑に関連するパラメータも同時に増えてしまうので、結果として人や時間といった必要なリソースが指数的に増えていくという話ですね。 （技術的な負債もこのパラメータに含まれ
Latest topics > なぜMozillaはXULアドオンを廃止したのか？（翻訳） - outsider reflex
Latest topics > なぜMozillaはXULアドオンを廃止したのか？（翻訳） 宣伝。日経LinuxにてLinuxの基礎？を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能！ « 「同調圧力は忌むべきものだ」と思考停止していたことに気付いた話 Main 「なぜMozillaはXULアドオンを廃止したのか？」に寄せられていた反応を見て、「甘い……甘すぎる……」と思って、W3C信者時代からの価値観に行き着いた話 » なぜMozillaはXULアドオンを廃止したのか？（翻訳） - Aug 22, 2020 （原著：David Teller, 2020年8月20日、CC BY-NC 4.0で公開されている内容の全訳。Qiitaにもクロスポストしています。） 要約：Firefoxはかつて、XUL
GitHubのスターは金にならない - Qiita
Sizzyというツールがあります。 様々なサイズの画面を同時に表示し、レスポンシブレイアウトがどうなるかを一気に確認できるという便利なツールです。 スマホ向けWebサイトを開発している人なら、持っていると非常に便利でしょう。 参考：レスポンシブの確認ツール、後発だけに便利！スマホ・タブレットの主要なデバイスでの表示確認が同時にできる -Sizzy / 『Sizzy』様々なデバイスでのサイト表示を確認出来る便利サイト さてこのSizzy、元々無償のChromeエクステンションだったのですが、先日2019年7月に単独のアプリとして有償化されました。 一人あたり月5ドル(団体割引あり)のサブスクリプション制です。 以下は作者のKizte( Twitter、Medium、Webサイト )がその理由や経緯を綴った記事、GitHub stars won't pay your rentの日本語訳です。
「斧を研ぐ時間」エンジニアリングフライデーという試み - 弥生開発者ブログ
こんにちは Misoca 開発チームの id:mallowlabs です。最近は ドラえもん のび太の牧場物語 にハマっています。使っている道具のグレードを上げるために、牧場はそっちのけで鉱山にこもって鉱石を掘り出す毎日です。 さて、先日の 軽減税率・区分記載請求書対応のリリース は開発チームにとっても比較的大きなリリースでした。そのため、リリースの直前には、このリリースに関係しないコミットは master ブランチにマージを控えることになり*1、自然と開発メンバーが普段使っているツールの整備や自由研究が行われることになりました。 ふりかえりで、このいわゆる「斧を研ぐ時間」がよかったという声が複数出たため、この時間を狙って作ってみようという TRY が生まれて「エンジニアリングフライデー」という試みが生まれました。 今回はこのエンジニアリングフライデーについて紹介したいと思います。 エンジ
ソフトウェア開発の生産性を阻害する「気軽に聞けない」ことの考察と対策 - メソッド屋のブログ
マイクロソフトの DevOps テクニカルエバンジェリストになる前から、ずっと不思議だったことがあります。 それは、「アメリカのエンジニアの生産性の高さ」です。素晴らしいサービスは大抵彼らから生まれていますし、彼らを見ているとアウトカムも生産性も非常に高く感じます。 私は個人的にこの秘密を解く旅の途中にいます。私はインターナショナルチームに所属しているのですが、同僚と一緒に働いたり、ハッカソンをしたりして気づいた１つの仮説について共有したいと思います。 気軽に「聞けないこと」が生産性を阻害しているのでは？ 以前私は「米国のエンジニアはコンピュータサイエンスを専攻している人が多くすごく優秀で、さらに英語が出来るので、技術収集するのも楽だから相当アドバンテージがある」と思っていました。 英語に関してはそうだと思いますが、彼らの個々の人がそんなに優秀かというとそうでもないことに気づきました。それ
実績を解除してエンジニアスコアを上げろ！はてなのエンジニア実績システムのご紹介 - Hatena Developer Blog
こんにちは、id:onishiです。今日もはてなの技術部の取り組みを紹介します。今回のネタは「エンジニア実績システム」です！ちなみに前回は「毎週勉強会」を紹介しました。 エンジニア実績システム はてな技術部では、ブログの公開やOSS活動、イベント登壇など社外にプレゼンスを発揮する活動を推奨するための取り組みを行っています。今回紹介する「エンジニア実績システム」もその一つです。 実績とは何ですか? 実績とは、特定の行動をゲームで達成したことに対するリワードです。 Xbox One の実績とチャレンジ 「実績」とはXbox 360, Xbox One に搭載されている同名のシステムを意識しています。Xboxのそれがゲーム内の進行状況や難易度の高い行為によって報酬を獲得できるのと同じように、エンジニアの社外プレゼンス活動に対して実績を設定し、エンジニアスタッフ個々人の実績解除を推奨しています。
善意を恒久的に続ける義務はありません - FANTA-G：楽天ブログ
2014.04.09 善意を恒久的に続ける義務はありません カテゴリ：カテゴリ未分類 あるフリーソフトのお話。 そのソフトは元々開発者が自分が楽をするために個人的に開発したもの。で、同じような苦労をしている人がいるのでネットで流してみた。 評判は大変よく、やがてそのソフトを利用したシステムやサービス、そのソフトで仕事のやり取りをする人もいるようになった。 やがてWindowsの世代更新が行われる。しかし、そのソフトはあたらしいＯＳには仕組みが違うため対応していない。使えなくなってしまう。一応、代用できる有料のソフトは世間にはあるが、以前のものを引き継いだ形のフリーソフトはない。 で、それに対して開発者はそれを開発する気はなく、ましてや過去、一部利用者による心無い誹謗中傷まで受けるような状況にまったくやる気をそがれている様子。開発者は自分のＢｌｏｇをすでに数年前に更新停止している。コメント欄
http://foreignkey.jp/archives/1579
See related links to what you are looking for.
｢コードの未来、エンジニアの未来｣まつもとゆきひろが語る、明暗2つのシナリオ 【キーパーソンインタビュー】 - エンジニアtype
Ruby / mruby開発者 まつもとゆきひろ氏 （@yukihiro_matz） 1965年生まれ。鳥取県米子市出身。筑波大学第三学群情報学類を卒業。1993年にオブジェクト指向スクリプト言語「Ruby」の開発に着手、1995年に公開。現在はネットワーク応用通信研究所（NaCl）のフェロー、楽天技術研究所のフェロー、Heroku、グルーブノーツのチーフアーキテクトを兼務する。「Matz」という通称で親しまれる なかなか難しいテーマですね……。でも、拙著を読んでくださってありがとうございます。 ―― この本では、数々の開発言語やプログラミング手法の現在・過去・未来について、私見を交えながら詳しく述べていらっしゃいますね。 そこで伺いたいのは、まつもとさんはソフトウエア産業の現状についてどう見ていらっしゃるか、ということです。本質的な部分では変化していないのか、何かしらのパラダイムシフトが
アイデアを塩漬けにしない-世界中の人に手伝ってもらう方法-
ngServer and-collaboratived-development-between-san-francisco-and-tokyoSatoshi Tanaka
「無駄にたくさんゲーム作って生きる」 “RucKyGAMES” という生き方 10の新機軸
1. ゲームを無駄に大量生産する ラッキー君はゲームをたくさん作っている。 僕は普段ゲームをしないのだが、i刺身Liteはダウンロードして持っている。 当時はこれが彼のデビュー作だとは知らなかった。 そして今まで2年半で約90本のiPhoneゲームをリリースし、総ダウンロード数は400万に上るという。 2年半で90本ということは、1ヶ月あたり3本のペースだ。 凄い勢いと言って良いだろう。10日に一本のペースでゲームアプリばかりを出し続けているのだ。 なかにはまったく日の目を見ないものもあるという。 それでも出し続ける。それが彼のやり方なのだという。 2. 遊びたいものを自由に作る 他人の目や結果の失敗を気にして躊躇しない。 自分が「遊んでみたい」と思い付いたら、とにかく作ってみる。 どんなにつまらないと思えるものでも、誰かしらの心に引っ掛かる。 そこからがスタートになる。 作らなければ、た
ありらいおん氏によるクリエイター奨励プログラムとコンテンツツリーに関する一考察 - Togetter
myrmecoleon @myrmecoleon 「クリエイター奨励プログラム」論議でよく無視されてるのが，奨励プログラムへの作品登録には「（投稿アカウントが）プレミアム会員に登録している」という条件があることと，登録する作品がオリジナルでないといけないとは規約上どこにも書いてないこと。 2012-02-04 13:06:43 myrmecoleon @myrmecoleon もともと権利者削除の恐れの強い動画は，プレミアムアカウントで投稿されている率が低い。なぜなら一定量の権利者削除が蓄積されると投稿制限等のペナルティが発生するため。削除率の高い丸上げやMADなどの活動を継続的におこなう場合，プレミアム垢でなく一般垢を乗り継ぐ戦略が普通。 2012-02-04 13:09:33
俺がゲームを作る際の考えかた。 島国大和のド畜生
■ゲームの大枠が決まったら。 ①ミニマムの快感を考える。 テトリスならスポッと嵌った瞬間。 カーレースならコーナリングの気持ちよさ。 シューティングなら弾幕避け。 格闘ゲームなら攻撃がヒットする気持ちよさ。 FPSならヘッドショットの快感。 自分は、この「ミニマムの快感」が一番大事派。ココさえ成立させてれば、後は装飾だからどうにかなる。 装飾ってのは、予算があれば本当になんとでもなる。（そういう派） ②最終的な快感を考える。 ＲＰＧならボス倒す。 格ゲーなら、強くなる。 ミニマムな快感の積み重ねの後の最終目的。 これをどれぐらい、ミニマムの快感から遠いところに置くかで、ゲームの難度、ボリュームが決まる。 ③ミニマムの快感と最終的な快感の間をどう繋ぐかを考える。 ぶっちゃけ、最近のゲームは最終的な快感が遠い。だって仕方が無いじゃないボリュームの少ないゲームはすぐ中古行きだし、ネットゲだったら
会社で新しくWebサービスを立ち上げる前に必ず考えないといけないこと。 │ モノづくりブログ 株式会社8bitのスタッフブログです
株式会社8bitのスタッフブログです。こんにちは。株式会社8bitの高本です。 今年は去年と違い、Webサービスを作る前にちゃんと考えてからやりましょう！というのが恥ずかしながら当社内でのスローガンのようになりつつあります。 今回はWebサービスを立ち上げる前に考えるべきことをまとめてみました。 これだけWebサービスがあふれている中で、今から画期的なサービスを作って売れるようになるのはすごく大変です。 ITで一攫千金というと、Webサービスを作ろうという発想に行きがちですが、みんなおんなじこと考えてますので一筋縄では行きません。 未だにスマッシュヒット出せていませんが、作っていくうちに考え方にも変化が出てきました。 量産することでWeb制作の受託案件を取ろうというのであれば、量産OKだと思いますが、Webサービスだけできちんと収益を取ろうと思ったら、よく考えないと、作ってみた
OSASK 公開停止か? | スラド
ストーリー by reo 2009年11月04日 10時30分 AC によるわたしへの横柄な態度は歓迎します (ほどほどに) 部門より 「エミュレータ OS」を標榜して川合秀実氏を中心に開発されている OS、OSASK-HB が一般公開停止になるかも知れない。 氏のブログ記事 (方針転換の予定(1), 方針転換の予定(2), 方針転換の予定(3)) で方針の転換に至った氏の心情が吐露されており、各自参照をお勧めするが、要約するとギヴアンドテイクの精神を忘れて横柄な態度をとるユーザの増加に嫌気がさしたということらしい。実際にどうするかは反響次第としながらも、公開停止がデフォルト時の路線のようだ。 タレコミ子はこの件を知って以前 /.J でも取り上げられた PSP filer の件を思い出したが、心ない一部ユーザの野次によって作者のモチベーションが削がれるのはコミュニティ全体の損失だと思う。皆
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
坪田 朋の3354年のノート
