寿司がシャリを撒き散らしながら爆走するゲームの映像がTwitterに投稿され、「疾走感がすごい」と話題になっています。開発者はハイセンスなゲームを多数手がける個人クリエイターksym（@mt_kuso）さん。 寿司がはしるやつ 「寿司がはしるやつ（仮称）」は、2019年内のリリースに向けて開発中のレースゲーム。100貫の寿司が滑るようにハイウェイを走り抜けるさまには、えも言われぬ中毒性があります。耳に残る音楽もかっこいい。 マグロやイカ、イクラに玉子など、プレイアブルなネタも豊富に用意されているもよう イキがいいねェ 開発者のkysmさんに開発状況を伺ったところ「まずはiOS/Androidで今年の早い時期にリリースしてその後PC版を検討しています」「特徴としてタッチデバイスでの操作に最適化しており、タップ操作のみでスピード感のあるレースを楽しむことが出来ます」とのこと。 動画は公開されて

Webサービスやアプリなど開発や運用に関わっている方であれば、こんなことを耳にしたことがあるのでは無いでしょうか？ 5人でテストを行えば、ユーザビリティ上の問題のうち85%を発見できるこれらは業界的にはある意味で常識ですが、色々話を聞いてみると、この常識の「出処」あるいは「根拠」ってあんまり知られていないようなのです。 もちろん、ちょっと知識のある人であれば、ユーザビリティ業界の第一人者であるヤコブ・ニールセン博士が提唱したというところまでは知識として知っているでしょう。しかしながら、その元ネタとなった論文を実際に読んだ人、あるいは85%という数字の根拠やその条件について理解されている方はどの程度居るのでしょうか。 ということで本記事では「ユーザテストは5人で85%」の元ネタである下記の論文について、解説、と言うとちょっと大げさかもですが、概要を紹介してみたいと思います。願わくば、この記事

本連載では、外資系テクノロジー企業勤務／圓窓代表・澤円氏が、エンジニアとして“楽しい未来”を築いていくための秘訣をTech分野のニュースとともにお届けしていきます 圓窓代表 澤 円 立教大学経済学部卒。生命保険のIT子会社勤務を経て、1997年、外資系大手テクノロジー企業に転職、現在に至る。プレゼンテーションに関する講演多数。琉球大学客員教授。数多くのベンチャー企業の顧問を務める。 著書：『外資系エリートのシンプルな伝え方』（中経出版）／『伝説マネジャーの 世界№1プレゼン術』（ダイヤモンド社）／『あたりまえを疑え。―自己実現できる働き方のヒントー』(セブン＆アイ出版)※11月末発売予定 連載：リクナビNEXTジャーナル『澤円のプレゼン塾』／ダイヤモンド・オンライン『グローバル仕事人のコミュ力』 皆さんこんにちは、澤です。 2019年、そして平成最後の年になりましたね。 皆さんはどんなお正

moonq515@黄金体験 @moonq5151 夜行バスが満席だったので苦肉の策で夜行フェリーを予約したものの、な、何じゃこりゃー！ めちゃくちゃ豪華じゃん！え～？😆飛行機と比べたら安いし、また世界が広がった(笑) pic.twitter.com/NWBt5XJWxt 2019-01-14 21:51:17

ドラゴンクエストやファイナルファンタジーなどのナンバリング表記でおなじみの「ローマ数字」。 「今度のモンハンはXと書いてクロスなのね」のノリで、新しいバージョンの度にいちいち読みを覚えたりしていないだろうか。 実はローマ数字にもきっちり規則があって、覚えるべき原則は「足し算」と「繰り返しは3回まで」の2つだけ。これだけでいろいろな数を表せるのだ。 足し算と引き算で表している ローマ数字は、各アルファベットが表す数を足すことでそのまま数を示せるようになっている。 例えば、1を表すアルファベットは“I”。“II”なら1が2つなので2、“III”なら3を表す。 なら4は“IIII”……といきたいところだが、同じ文字が4つ並ぶのは分かりづらい。そこでローマ数字では4を「5の1つ前」と考えて“IV”と表す。“V”は5に対応するアルファベット。 V（5）に先ほどまでと同様にIを足していけば、VI（6）

スポーツニッポン新聞社の、動画共有コミュニティー「TikTok」公式アカウントが大きな人気となっています。スポニチの紙面レイアウト製作工程を、白紙の状態から完成まで見られるのです。これは興味深い……！ 「TikTok」スポニチ公式アカウント 白紙の状態から紙面になっていくところがたっぷり見られます 現在公開されている最新の動画は1月13日の大阪版1面レイアウト製作工程で、阪神タイガースの藤浪晋太郎投手にスポットを当てたもの。中央に藤浪選手の写真を大きく配置するところから始まり、右上に大きな記事タイトルロゴや小さな写真を配置。そこから反時計回りに文字や写真を配置していく様子が見られます。広告が入るところは、この段階ではまだ空欄のもよう。 現在動画は30本程度上げられているのですが、その多くが紙面レイアウトの制作工程を収めたもの。また、少数ではありますが、紙とペンと写真の切り抜きを使った下書き

第14回福岡市西区プログラム勉強会資料（2016/07/03） Lore言語実装の副産物として汎用ASTライブラリを作成したので紹介した。 (1) シンプルな単一種類ノードのASTに型チェック付きで様々な型のアトリビュートを格納するAST実装 (2) ASTを辿る過程をイベント・ストリームに変換してアクセスすることでイベント駆動でないプル型のアクセスを可能にするASTウォーカーの実装 （先行事例はちゃんと調べてないので「あるある」実装かも。）

この記事は認証セキュリティ情報サイト「せぐなべ」に掲載された「架空世界 認証セキュリティセミナー 第7回『鉄人28号の操縦器（リモコン）認証』」（2017年10月12日掲載）を、ITmedia NEWS編集部で一部編集し、転載したものです。当時未発売だった製品やサービスの記述などは、本記事掲載時の状況に合わせて編集しています。 1つの架空世界に絞って認証を考える ……それでは講義を始める。 前回は1つの架空世界に絞って認証の考察を行うということで「ミッション：インポッシブル」シリーズを見ていった。さすがスパイモノ、多要素認証の事例も出てきて非常に興味深かったかと思う。また、さまざまな生体認証の事例も紹介した。 さて、今回も引き続き1つの架空世界に絞って認証の考察を行いたい。舞台となるのは「鉄人28号」だ。 多数のメディアミックスが存在する鉄人 まずは基本データから。1956年に月刊「少年」

2018年12月17～19日に開催された「IVS CTO Night and Day 2018 Winter」にて発表した資料です。

XP祭り2017のセッションのスライドになります。 http://xpjug.com/xp2017-session-a5-1/ 元ネタは以下です。 http://i2key.hateblo.jp/entry/2017/05/15/082655 ※CCPMの表記について一部誤解を与える部分がありましたので、表記を削除いたしました。 2017/09/21 0:27

終了 2018/10/26（金） 19:30〜 みんな教えて！！スクラムアンチパターン スクラムアンチパターン自慢大会 otajisan 他 東京都渋谷区道玄坂1丁目22−7 (道玄坂ピア10F)

この投稿は、アジャイル開発 Advent Calendar 2018の25日目です。 昨日は、@matsu0228さんの「ヨーロッパ最大のアジャイル・テスト自動化カンファレンス「AgileTestingDays2018」に参加してきた」でした。 この記事は、約半年間、スクラムマスターとして経験したアンチパターンの振り返りとそれに関連するスクラムの概念のまとめです。 記事下部にリンクしてあるLT資料からの抜粋 + α の内容なので併せてご覧ください。 リリースバーンダウンチャート これは正直判断が難しいですが、SCMでは、3ー4スプリント以上の未来予測はウォーターフォールになってしまうのでリリースバーンダウンは非推奨と言われました。一方で、組織としてはリリース予定日の決定と、それに向かっての経過報告は避けきれない部分もあったので、PBI(プロダクトバックログアイテム)を積んで、6スプリント先

という記事を見ての職業プログラマ歴３年程度の若造の過剰反応です。 まとまっていないポエムのようなものなので、 こんなことあるんだなっていう程度に思っていただいたら幸いです。 作ったプログラムを保守しているとは限らない まずはこれが大前提。 「作ったやつが無能」だとか「あらかじめ予想していなかった人が問題」だとか、 いろいろ思うことは当然私にもないとはいいませんが、 そういうことは後続の人が云ってはいけないと思っています。 なぜそうなったかの原因究明は必要ですが、悪口を言うための究明なら時間の無駄でしかない。 考慮ができていない「おかしなプログラム」を直すのが我々保守の一端、おざなりにしてはいけない。 １か月でリリースは難しい そもそもプログラムに直接書き込まれていて、 なおかつオフラインで運用されているシステムが、全国各地にある場合にある場合、 たった１か月で「調査→修正→テスト→納品」で

For the session A-4 ,DevLOVE Kansai 2012 Drive.Read less

8. 権限レベルを決める ストーリーの内容 Tell Sell Consult Agree Advice Inquire Delegate ストーリーの中の 内部仕様 PM Team Client PM スプリントに含める ストーリー PM Team PM Client … ストーリー全体計画 Client PM

なぜ日本のエンジニアは地位が低いのか？その傾向と対策 - paiza開発日誌 う～ん、前提となる分析がイマイチなため、結論もイマイチとなってます。 私が所属しているのは一次受けSIerなので、まあ、ITゼネコンと言ってもいいのかな。その中のそこそこ出世していると思われる理系プロマネからみて、実態あまり分析できてないのが残念です。 元記事とは違った見方をしているので、ちょっとまとめてみます。 大手SIerのしごと いわゆるITゼネコンと呼ばれる一次受けを担当するSIerの開発チームでは、以下の様な仕事してます プロジェクトマネージメント 業務設計、業務分析、仕様設計 ソフトウェアアーキテクト設計 基盤構築　※縮小傾向 ちなみに、上記技能が特化していれば文系でも理系でもだいたい出世できます。当たり前ですが、文系だから、理系だからではなく、仕事ができるから出世します。業務設計やソフトウェアアーキ

炎上プロジェクトの責任はプロマネが９割 - プロマネブログ はてなブックマークのコメントを沢山いただきありがとうございます。ちょっと気になったコメントが有りましたので、考えてみたく。 カネと期限の権限のないプロマネ　＝　プロジェクト推進の専門家プロジェクトリーダ 気になったコメントというのは 与えられた時点で予算や期限が限界を超えていて炎上必至 最初から赤字プロジェクトだった みたいな感じです。 で、ちょっと考えたのですが、オッサンの話の中で呼んでるプロマネとは微妙に役割が違うんですよね。。。 これって炎上プロジェクトの責任はプロマネが９割 - プロマネブログにある通り、PMBOK管理観点のスコープ管理、タイム管理、コスト管理に該当する話で、PMBOK的にはプロマネの管理の範疇の内容です。 にも関わらず、プロマネがそれを制御できない、そういう声が多く現れているわけです。 実は、これら予算や

サルでも分かるアジャイルとウォーターフォールをハイブリッドしたマネジメント・デザインパターン - プロマネブログ 前回からの続きです。 以下、３部作の３本目となります。 ウォーターフォール開発とアジャイルの本質 - プロマネブログ サルでも分かるアジャイルとウォーターフォールをハイブリッドしたマネジメント・デザインパターン - プロマネブログ 炎上プロジェクトの責任はプロマネが９割 - プロマネブログ 追記)ブコメで誤字の指摘がありましたので、訂正します。。。お恥ずかしい NetPenguinさん、ご指摘ありがとうございます 改めて考えたいプロマネの仕事 プロマネの仕事とは、PMBOKのプロジェクト管理に関する観点をマネジメントする、と言えます。 統合　　　・・・　チーム内の意思統一 スコープ　・・・　目標、成果決定 タイム　　・・・　期限、スケジュール管理 コスト　　・・・　予算、費用管

ウォーターフォール開発とアジャイルの本質 - プロマネブログ 以下、３部作の２本目です。 ウォーターフォール開発とアジャイルの本質 - プロマネブログ サルでも分かるアジャイルとウォーターフォールをハイブリッドしたマネジメント・デザインパターン - プロマネブログ 炎上プロジェクトの責任はプロマネが９割 - プロマネブログ 前回と今回のシリーズはカテゴリ　プロジェクトマネジメント論にまとめてます。 単一の開発手法の限界からハイブリッド方式へ 前回、各開発手法は失敗プロジェクトの反省から、それぞれ本質となる改善要素を持つことを示しました。 ウォーターフォール開発（以下WF）であれば、形式知化。 アジャイル開発であれば、フォーカス分割。 これらは排反する概念ではなく、それぞれの利点を活かしてプロジェクト運営を行うことが、より効率的なプロジェクト運営につながると考えられます。 とはいえ、ハイブリ

以下、３部作の１本目です。 ウォーターフォール開発とアジャイルの本質 - プロマネブログ サルでも分かるアジャイルとウォーターフォールをハイブリッドしたマネジメント・デザインパターン - プロマネブログ 炎上プロジェクトの責任はプロマネが９割 - プロマネブログ 度々話題なる開発手法、ウォーターフォール開発（以下WF）とアジャイル。 それぞれの違いってなんだろうと思い、ちょっと本質について普段考えていることをまとめてみました。 ウォーターフォール開発の本質とはなにか？ システム開発を行った方なら一度は耳にすることがあるWF。 各開発工程を順序良くこなしていく開発手法となります。 イメージにすると以下のとおり。 さて、WFのよく言われる特徴を以下眺めてみたいと思います。 最初に一括して要件定義を行うので、仕様変更に弱い No。一括して要件定義を行うこと自体は、要件定義のやり方の問題です。一括

はじめに ここ数年でアジャイル開発への期待が高まっています。 その中でもフレームワークとしてやることが明確なスクラム開発に人気があります。 しかしスクラムはその本質を理解しないと失敗するケースが多く、 かくいう私も一番最初に取り組んだスクラム開発ではうまくいきませんでした。 今はCSM、CSPOの取得とスクラムの実践を通して理解が進んだので、 自分のなかの「スクラムとはなんなのか」をまとめてみました。 事前にスクラムガイドを読んでいると理解がしやすいと思います。 スクラムの真髄は問題の可視化 スクラム自体は問題解決をしません。 スクラムは問題を見えるようにするものです。 スクラムのチームもツールもイベントもすべて問題の可視化のために貢献します。 継続的に問題を可視化できる仕組みを保つことによって問題が小さなうちに直していくのです。 ウォーターフォール（以下WF）との一番の違いはここだと思っ

2018年9月に登場した新型iPhone。これまで新iPhoneが出るたびに買い替えてきた津田大介氏だが、今回、初めて購入を見送ったという。その一方で「18年はアップルの当たり年だった」とも語る。iPhoneを買わなかった理由、そして、それにも関わらずアップルの当たり年だと津田氏が感じた理由について話を聞いた。◇　　◇　　◇08年に日本で初めてiPhone 3Gが発売されて以来、僕は新モデルが

モバイルエンジニアの@chiiia12です。 私がQuipperのモバイルチームにjoinした際に驚いたことの一つが、自動化スクリプト/便利ツール等が多く使われていることでした。 今回はモバイルチームで最近導入されたものをいくつか紹介したいと思います。 DeployGateのビルドバージョン通知 私達のチームではDeployGateを使ってQAチームやデザインチームに開発中のアプリを配布しています。 QAテスト期間中は、不具合を改修した後に改修が含まれたバージョンのアプリをQAチームに確認をお願いしています。その際にDeployGateのバージョンを伝えてテストをしてもらっていますが、開発者にとってはDeployGateのビルドバージョンを確認するのはひと手間かかる作業になっていました。 これをissueがリンクされたpull requestのマージをトリガーに、どのDeployGateの

何を書く？ アジャイル開発とは何か？ この答えはボンヤリ説明されることが多くて、なんかわかったような、わからないような。 Scrum の朝会をやってればいいの？ 普通の開発を素早く繰り返したらアジャイル開発なの？ などなど疑問は多いです。 あらためて、煙に巻かずに、実践的に、誤魔化さずに、その背景を説明してみるというチャレンジです。 2019.10 : 「評価（テスト/レビュー）についての考え方」を追加しました アジャイル開発とは（ぼんやりした版） 一応、哲学的な、でも本当は正しい、説明を書いておきます。 でもこれは忘れてくれても大丈夫です。 免罪符的に書いておくだけです。 アジャイルとは、常に改善している状態・より良いものを目指している状態です。 本質的にはこれがアジャイルで、アジャイル開発について言われるさまざまな手法やルールがありますが全てはこの状態を目指してのことです。 その考え方

IT Leaders トップ ＞ テクノロジー一覧 ＞ オピニオン ＞ 木内里美の是正勧告 ＞ 本質を理解しないままのアジャイル開発に挑む危うさ オピニオン オピニオン記事一覧へ [木内里美の是正勧告] 本質を理解しないままのアジャイル開発に挑む危うさ 2018年1月22日(月)木内 里美（オラン 代表取締役社長） リスト 定義が明確でないために「アジャイル開発」の議論は解釈が様々で、一部の特徴だけを捉えて議論していたりして曖昧であり危うい。本質を外さないための拠り所の一つとして、「アジャイルソフトウェア開発宣言」として示されたマニフェストがある。その中身に触れつつ、価値をあらためて考えてみたい。 ある業界団体からの誘いを受けて、政府のシステム関係者向けに“ライブ開発”をするイベントに立ち会わせてもらった。ライブ開発とはその場でテーマを出し、それを実現するシステムを開発するもの。言わばアジ

EnterpriseZine（エンタープライズジン）編集部では、情報システム担当、セキュリティ担当の方々向けに、EnterpriseZine Day、Security Online Day、DataTechという、3つのイベントを開催しております。それぞれ編集部独自の切り口で、業界トレンドや最新事例を網羅。最新の動向を知ることができる場として、好評を得ています。

失敗パターンを思いついた３つのポイントを書く。 アジャイル開発への知識不足 そもそも、この理由のケースがとても多い気がしている。 まとめページだけの知識で始めてしまう人が多い。もしくはトップダウンにより十分な知識が無いまま走り出してしまうケース。 名前しか変わらない開発プロセス マネージャーの名前をスクラムマスタに変えただけで、マネジメント方法が変わらない。 進捗確認会議を振り返りと呼び、仕様変更の差し込み作業をアジャイルと呼ぶ。 既存のプロセスとは全く違うものなので、しっかりと知識を付けてから戦略を持って導入して欲しい。 勉強のためのステップ １．書籍やWeb記事などで勉強する。 アジャイルの概念とアジャイルの手法の違いをしっかり理解して欲しい。 まずはスクラム、XP、リーンの手法などを勉強してみるのが良いと思う。 ２．書籍にあるものは半分は理想論であり、基本でしかない理解する ３．勉強

The Qiita Advent Calendar 2018 is supported by the following companies, organizations, and services.

2014-03-13（木）の、情報処理学会　第７６回全国大会のセッション『ビッグデータ時代に立ち向かうイノベイティブなシステム開発～Agile, Big-data, Cloud, DevOpsのプラクティスから ～』の発表資料です。 http://www.ipsj.or.jp/event/taikai/76/event_1-6.html 現場は難しく、面白いです。 唯一絶対の答えはなく、予測不可能な問題が多発し、何らかの改善を行なっても、問題はなくならずに移動していきます。 一方で、適切な知識・情報を見つけて行動することで、いくらでも変えていくことが出来る可能性も持っています。 このセッションでは、日々プロジェクト・プロダクトを俯瞰し、課題を見つけて解決策を講じるサイクルを短く繰り返して現場を改善していった、現場でのリーン開発とアジャイルの実践について、アジャイルコーチとしての自身の経験・

この記事は、社内向けに書いた資料を公開の許可を得て加筆修正したものです。 記事中の具体例やサンプルコードはJavaScript/TypeScriptで書かれていますが、内容自体は言語にかかわらず使えます。 同僚の @shisama にも手伝っていただきました。 はじめに 命名について 条件式について 関数について 変数・定数について コメントについて 2020/11/02 ついに完結！ はじめに 読みやすいコードは、コメントがなくても文章を読むように理解できます。 逆に、読みにくいコードはコメントがあってもさっぱり意味がわかりません。 文章を読むように理解できるコードを書くために普段気をつけていることや、コードレビューの際に重点的に見ているところをまとめました。 普段から読みやすいコードを心がけている方にとっては何も目新しい物はなく、当たり前に意識しているであろうことばかりです。 特にプロ

Agile Metrics入門 1. 1 Agile Metrics入門 株式会社SHIFT 太田健一郎 2. 2 • アジャイル開発のQCD+S • アジャイル開発におけるメトリクス取得の目的 • メトリクスのやってはいけない • メトリクスの入力元 • アジャイルメトリクス • メトリクス組合せ例 • 他社案件事例 • メトリクスツール • 参考情報 アジェンダ 3. 3 アジャイル開発のQCD+S 4. 4 • Quality – 品質→価値 • Cost – ポイント毎の実時間 x 総ストーリーポイント • Delivery – Agileでは通常固定 • Scope – スプリント毎に提供するストーリーの総量 – Agileでは開発するストーリーは交渉できる要素 QCD + S 5. 5 アジャイル開発におけるメトリクス取得の 目的 6. 6 • Measure – チームとプロ

2017年12月15日(金)に、JEITA（一般社団法人 電子情報技術産業協会）の「ソフトウェアエンジニアリング技術ワークショップ2017」に参加してきました。プログラムなどはこちらをご覧ください。 テーマは「人工知能ブームの中でのソフトウェアエンジニアリング」。とても勉強になった催しでしたので、許される（であろう）範囲でシェアしたいと思います。 なお、わたしはディープラーニング初学レベル以下です（堂々）。講演者の方のご発言の趣旨を正しく理解できず、間違った要約をしてしまっているかもしれません。申し訳ありませんが、その際はご指摘いただければ修正・削除いたします。 基調講演: 機械学習工学に向けて 株式会社Preferred Networksの丸山宏さんの基調講演では、機械学習の概要や潮流について、幅広くお話しいただきました。どちらかといえば、機械学習のすばらしさよりも、限界や注意点に重点を

のぞみ全車指定のJR西日本、「お乗りになってから初めて自由席がないことにお気付きのお客様」とつい煽ってしまう

新NISAが始まっても投資に手を出してはいけない…経済学者が｢老後に備えるならコレ｣と唯一勧める金融商品【2023上半期BEST5】

なぜあの上司に人はついていくのか──。彼らが無意識にでも実践しているリーダーシップ哲学がある。もはや「オレについてこい！」だけで部下は動かない。今、注目を集める理論を紹介しよう。 「優しい人」とはどこが違うのか？ 「召し使い」を意味する「サーバント」と、組織を導く「リーダーシップ」という正反対の言葉を結合させたサーバント・リーダーシップとは「リーダーである人は、まず相手に奉仕し、その後に相手を導くものである」というリーダーシップ哲学である。この理論は部下に対して明確なミッションやビジョンを示し、それを遂行するメンバーに奉仕するリーダーシップと定義される。 上司は自分のミッション、ビジョンを実現させるための道具として部下がいると考えるのではない。それを実現するためにメンバーが行動してくれる。ゆえにそのメンバーがより活躍しやすいようにと環境を整え、支えるのがリーダーの役割だと考えるのだ。 サー

スクラムは基本的にはスクラムガイドに背くことで失敗しやすくなります。 そんな中でもよくあるアンチパターンと一言解説をまとめました。 スクラムマスター(SM)の失敗 SMがDevを兼任する スクラムマスターの仕事はそうなくならない どちらかの作業が片方の作業のボトルネックになる Devとしての作業量が不安定でベロシティを計画のために利用しづらくなる SMがPOを兼任する POとSMはそれぞれの責任に関する作業のみでボトルネックになりやすい 時にはPOの立場（プロダクト寄りの視点）とSMの立場（チーム寄りの視点）がコンフリクトを起こすこともある SMがチームに奉仕していない サーバント・リーダーシップがない SMはチームが抱えるあらゆる障壁の解消に努める（全部自分でやらずとも周りと話をするなど） SMがチームをマイクロマネジメントしている マイクロマネジメントは自己組織化につながらない チーム

みなさんこんにちは。@ryuzeeです。 以前お客様先でスクラムのトレーニングを実施した際に、プロダクトバックログアイテムとタスクの見積りについて質問をいただきました。 見積りについてはもっとも質問をいただく項目の1つでもあるので、ここでスクラムにおける見積りについて書いておくことにします。 プロダクトバックログアイテムの見積りまずはプロダクトバックログアイテムの見積りについて考えてみましょう。 なぜプロダクトバックログアイテムを見積もるのか？なぜプロダクトバックログを見積もるかといえば以下の理由です。 そのプロダクトの全体を把握する。全体のサイズが分からないと現在の進捗が把握できません。もちろん全てのプロダクトバックログアイテムを絶対に作るかといえばそうではなく、途中でプロダクトバックログアイテムが追加されたり削除されたりしますが、それでも全体の概要を把握しようとすることには意味がありま

アジャイル開発において、プロダクトや組織の現状を把握するのに役立つメトリクスを知りたいと思い、「agile kpi」などでググって上位のサイトを読むという丁寧なサーベイを敢行。20個くらい読んでいくとだいぶネタも尽きてきたので、整理してみました*1。参考にしたサイトについては、記事の最後に載せておきます。 なお以下では、アジャイル開発とスクラム開発をほぼ同じ意味で使っていますが、怒らないでいただきたいですね。 メトリクスとKPI メトリクス（metric / metrics*2）とKPIはごちゃごちゃに使われがちです。こちらの資料では、以下のように説明しています。 Agile KPIs from Gaetano Mazzanti www.slideshare.net メトリック: プロセス・プロダクト・チームの定量的な評価・制御・改善のための物差し、またはその組み合わせ KPI: 戦略的な

サーバレス構成のWebアプリ開発を担当し、そこでVue.jsを使ってみたので採用した経緯と、Vue.jsの何を使ったかを紹介する。 これまでのWebアプリ開発 JavaのWebアプリ開発ならThymeleafやFreemarkerなどのテンプレートエンジンを使用していた。 サーバレスだと、HTMLとJavaScriptで表示の処理を行うため、JavaScriptの処理が増える。 よく使われるのはjQueryによってDOMを操作し、HTMLを動的に変更する方法だろう。 jQueryのDOM操作は辛いよ jQueryを使ったことがあればお分かりだと思うが、jQueryによるDOM操作は「このイベントで、このvalueがxxxなら、このDOMを変更する」という手続き型のコードになる。 JavaScriptの処理が増えると、この手続き型のコードが増えてデータと状態の管理が煩雑になる。 また、Jav

JavaOne2016 #CON5929 Time-Saving Tips and Tricks for Building Quality Java Ap...Yusuke Yamamoto

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

元記事: Awesome Java Awesome List in Qiita Awesome Ruby Awesome JavaScript Awesome Node.js Awesome Python Awesome Go Awesome Selenium Awesome Appium Bean マッピング Bean マッピングを容易にするフレームワーク dOOv - 型安全なドメインモデルの検証とマッピングのための API を提供します. アノテーション, コード生成, および型安全 DSL を使用して, Bean の検証とマッピングを迅速かつ簡単にします. Dozer - アノテーション, API または XML 設定を使用して, あるオブジェクトから別のオブジェクトへデータをコピーするマッパー. JMapper - 高速コードマッピングのためにバイトコード操作を使用. アノテーシ

第60回 プログラミング・シンポジウム

心理的安全性の高いチームを作るためにサーバントマネージャーに徹する話などを聞くことがありますが、なんか大変そうだなーと考えてたら、これは組織設計の課題だと思ったわけです。 サーバントマネージャーは過渡期と割り切って、本来の仕事である課題解決に時間を使えるようにしていったほうがいいです。 心理的安全性とは他者の反応に怯えたり羞恥心を感じることなく、自然体の自分を曝け出すことのできる環境や雰囲気のことを指します。 だそうです。失敗するかも…と早めに言えることはアジャイルな組織には必須です。 心理的安全性は1人のメンバーが日常的にコミュニケーションする相手との視座、視野、視点が近いと高くなると仮説を立ててみました。 視座、視野、視点の図 https://tech.drecom.co.jp/viewpoint-of-being-leader/視座が離れてる例：リーダーが超ベテランでメンバーが超若い

以前から気になっていた「次世代 Web カンファレンス 2019」を、ようやく聴きに行くことができました。 たくさんのトークがありましたが、ここではHTTPS (hashtag: #nwc_https)をメモしておきます。なお、このセッションが間違いなく一番アツく、一番面白かったです! 当日の動画 https://www.youtube.com/watch?v=_8dCa8wj8QY togetter https://togetter.com/li/1268794 以下、当日参加した、もしくは動画を見たという前提でのメモなので、見てない人はぜひ見ましょう。 PKI 「低レイヤから行きましょう」ということで、はじめはPKI絡み。Symantecのdistrustと、日本のGPKIの話でした。 トーク中に何度か出てきましたが、認証局(厳密にはCAとRAを分けて書くべきですが、どうせみんな一緒な

<タイトル> 大規模負荷テストの負荷かけ手法とトラブルシュート 副題JMeterとうまく付き合う方法 <内容> 負荷試験で、負荷を"かける側"の話(ミドルウェアのチューニングの話ではないです) <想定する対象者> 負荷試験とかJMeterってどんなものか、なんとなく知ってる人 負荷試験で負荷がうまくかからなくて、苦しんだ人 将来、大規模負荷試験してみたい人 <前提条件など> 使用する負荷試験ツールは JMeter3.0 -> GUIモードでシナリオを作り、CUIモードで動作させる 秒間2000 〜 10000 request ぐらいの負荷試験を想定 言葉の定義 - ストレスサーバ ... 負荷を***かける側***のサーバ - アプリサーバ　 ... 負荷を***かけられる側***のサーバ - シナリオ　　　 ... JMeterで実行する負荷試験ファイル(.jmx

『アッオー』でおなじみICQからIRC,Yahooメッセンジャー,HipChat,Slack,GoogleTalkの共通点は、すべて通信にXMLベースのXMPPプロトコルを利用していることです。インスタントメッセージサービスは目まぐるしく移り変わっていくため、変わらないコアの部分を抑えることが重要だと思います。 XMPPプロトコルを喋ると、大半のメッセージサービスを利用できるBotが作れます。この記事ではXMPPを開発・公開したJabber社のライブラリを利用して複数のメッセージサービスに対応したBotを実装していきます。 作るもの 起動したらHipChatとSlackに両方ログインしていて、話かけたらdeployしたりコマンド実行したりするBot。海外はSlack、国内はHipChatを使う特殊事例が発生して開発することになりました。過渡期つらい 新しいものを、どんどん取り入れていくこと

2015年12月06日 西プロ（福岡市西区プログラミング勉強会資料） オープンなメッセージングとプレゼンス情報の交換のためのプロトコル、XMPPについての紹介。

テクノロジーに興味がある人なら、身近な製品の裏側って気になるもの。そんな知的欲求を満たしてくれるセッションが、昨年の夏に行なわれたre:Union 2018 Osakaには用意されていた。Nintendo Switchの裏側にあるシステムを紹介する「Nintendo Switch向けプッシュ通知システム『NPNS』」と題して、任天堂 ネットワークシステム部の渡邉 大洋さんが語ったセッションだ。フレンド登録したユーザーのゲームプレイ通知など、見慣れたあのメッセージは、こうやって送られていたのだ。 想定同時接続数1億台のリアルタイム通信インフラをAWSに構築 「実はこのセッション、AWS Summit Tokyoでもやったので聴いたことがある人がいるかもしれません。が、そこは今日初めて聴いたようなテンションで聴いてください」（渡邉さん） という出足で会場の笑いをさらった渡邉さんにならって私も書

APIの定義を書く：Excel仕様書はもういやだ RESTful APIを提供するサーバと、そのAPIを利用するクライアント（たとえばSPA）とを並行で開発しようとするとき、まずAPIを定義して、それに基づいてサーバ／クライアント双方の実装を進めようと考えるのは自然だと思う。 そうと決まれば、「API仕様書_20190110.xlsx」と題するファイルを新規作成し、シート別にリソース毎の定義を書き始め・・・てはいけない。せっかくAPIを定義したドキュメントを作成するなら、するのなら、ソースコードの自動生成などの恩恵も受けたい。受けられるはずだ。 少しググってみる。どうやらSwaggerというものを使えばいいらしい。Swaggerに興味を持ったタイミングで、ちょうど書店に平積みになっていた『WEB+DB PRESS Vol.108』の表紙が目に入った。そこには、「スキーマ駆動Web API開

業種の壁を越えて人材が移動する「越境転職」が盛んだ。中心にIT（情報技術）業界があり、メーカーや小売りなど幅広い業種へ移ると同時に、コミュニケーション能力にたけた営業人材が異業種から流入している。デジタル革命や人手不足を背景に企業が中途採用を積極化しているうえ、年功序列が崩れてきており働く側もポストを外に求め始めている。新卒で採用されると4月に一斉に入社するが、中途採用は春と秋が多い。1～3月

すでにJava12はRampdownフェーズに入り、機能がほぼ確定しており、順調に行けば3月19日にリリースされます。->されました。 ということで、Java12に入る機能をJEP、API、その他にわけてまとめます。 JDK 12 Early-Access Builds JEP まずは大きな機能をまとめたJEPベースの変更 http://openjdk.java.net/projects/jdk/12/ 全部で8個のJEPが入ってます。ふつうのJavaプログラマに影響ありそうなのは上の3つとDefault CDSですかね。残念ながらRaw String Literalsはドロップされました。 189: Shenandoah: A Low-Pause-Time Garbage Collector (Experimental) 230: Microbenchmark Suite 325: Sw