サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
衆院選
craftsman-software.com
クラフトマンソフトウェアでは、ShouldBeeの開発をアジャイル開発方法論のひとつである「スクラム」を使って行っています。 また、レンタルCTOサービスにおいてもスクラムマスターとしてスクラムの導入のご協力をさせて頂いています。 今回は、スクラムで最強のチームを作る方法を書こうと思います。 > KPTをGKPTにKPTをGKPTに ShouldBee開発チームでは、スプリントの振り返りの際にPDCAを行なうためKPTを採用しています。スプリントが進むにつれ、振り返りの文化が自分達のチームに最適なものとなってきました。KPTが派生し、GKPTという概念が生まれました。 KPTは、(Keep, Problem, Try)ですが、これにGoodを足してGKPTです。 Goodはそのスプリントでよかった事や達成したことを書きます。Goodの中から今後も続けていくことをKeepに移します。 > ど
Slackで簡単に「日報」ならぬ「分報」をチームで実現する3ステップ 〜Problemが10分で解決するチャットを作ろう〜 開発プロジェクトを進めていくと、チームは様々な課題に直面する。こうした課題は、週次のミーティングや日報で共有して解決していくことが多い。 課題は大小様々だが、特に数時間で解決できるような小さな課題をいかにリアルタイムで解決していくかで、チームのスピード感が大きく変わってくる。 僕のチームでは、リアルタイムの課題解決の為に、社内チャットSlackを社内Twitterのようにする邪道な使い方「分報」という取り組みを実践している。 > 日報の弱点日報の弱点 日報は一日の業務の報告書で、一般的に「進捗状況」「体験」「学習」「課題」が記載される。これらをチームで共有することで暗黙知を減らし、個人とチームを成長されることが目的だ。報告方法はチームによって様々だが、メールをはじめ、
こんにちは、現在ShouldBeeではReact.jsを用いたUIの開発をしています。 ReactにはModalを実装した公開コンポーネントがいくつかあるのですが、React betaに対応していなかったのとアニメーション等の細かい設定を自分で設定したかったので自前で実装しました、今回はその紹介をしたいと思います! コンポーネント本体は下記のようになります。 親コンポーネントのstateをisActiveとして受け取り表示、非表示を切り替えています。 またモーダルを閉じるとき親コンポーネントのstateを更新する必要があるので、親コンポーネントのstate更新関数(onClose)を受け取っています。 アニメーションはAnimate.cssを使用しています。 import React from "react"; import classNames from "classnames"; ex
シェルスクリプトは長くなると処理の境界が不鮮明になりがち。 コメントで処理の境界を表現する工夫はよく見かけるが、もっと良い方法はないか考えてみた。 :コマンド、&&演算子、複合コマンド()や{}を組み合わせて書くと、処理の境界線がはっきりする。
1時間0.007ドル(約0.8円)で使える非常に安価なレンタルサーバ「DigitalOcean」をコマンドから操作する方法を紹介する。 > DigitalOceanをコマンドで操作できる「tugboat」DigitalOceanをコマンドで操作できる「tugboat」 tugboatは、Ruby製のDigitalOceanをコマンドで扱うためのツールだ。DigitalOceanはドロップレット(サーバインスタンス)の操作をREST APIで行うことができ、同ツールはこれを利用してドロップレットの作成などをコマンドラインで行う。 > APIトークンを取得するAPIトークンを取得する tugboatを使う前に、DigitalOceanの管理画面からAPIトークンを取得する必要がある。トークンの取得方法は次の通り。 > APIページを開くAPIページを開く Digital Oceanの管理画面に
一週間前に僕のチームで実践している分報について『Slackで簡単に「日報」ならぬ「分報」をチームで実現する3ステップ』という記事で公開したところ、分報を始めてみたという反響が多くあったので、その一部を紹介する。 質問もいくつか頂いたので、それにこたえる形で僕のチームではどのように分報を行っているかについても紹介する。 > 分報を導入したチームからの反響分報を導入したチームからの反響 人に話しかけるときも DM 送るんじゃなくて、相手の Twitter ごっこチャンネルに乗り込んでいって話すほうが割り込んでる感じもしないし、別の人が助け船だしてくれたりする。これは発見 — Naoya Ito (@naoya_ito) November 12, 2015 早速チームに導入している!社内Twitter感覚でやれてる。一人ひとりのステータスの確認がしやすいのでGOOD!:Slackで簡単に「日報」
Nativefierでどんなウェブアプリも一撃Macアプリ化!ブラウザとアプリの用途を分けて仕事を効率化しよう HTML5やJavaScriptでの表現力が非常に高くなった昨今、アプリをウェブだけで提供しているサービスは少なくない。今回はそうしたアプリをあたかもネイティブMacアプリのように変換できるNativefierについて紹介したい。 > アプリとブラウザを分けるメリットアプリとブラウザを分けるメリット 仕事をする上で、昨今のブラウザは2つの目的で使われる。 情報収集 特定業務の遂行 1つ目は、情報収集のツールとしてブラウザを使う。知りたいこと分からないことなどをGoogleなどの検索エンジンで検索し、調べ、業務の課題を解決するために使う。2つ目は、特定業務の遂行を目的に使う。例えばチャットツールのChatWorkやチケット管理のRedmineといったツールを動かすためにブラウザが使
Google Analyticsには直帰率という集計データがある。直帰率とは、1セッションが1ページビューだけで終了しているかを割合で表した値だ。例えばオーソドックスなケースを言うと、ユーザが1ページだけ見てブラウザバックした場合、直帰となる。直帰率が低ければ、ユーザが他のコンテンツも見てくれているということになる。 > 直帰率が70%台から突如2%台に!?直帰率が70%台から突如2%台に!? 直帰率が突然現象してしまった 会社ブログでもGoogleアナリティクスでアクセス解析しているが、普段の直帰率は70%台だった。ところが、数日前から直帰率が2%台になっていた。 特に直帰率に大きなインパクトを与える施策をしたわけではない。全く心当たりのない数値変動だ。従って、何かトラッキングの方法が失敗しているのではないかと疑ってみることにした。 > 原因はイベントのトラッキングだった原因はイベントの
もし、会議の場で参加者から「〜と感じる」という発表があったとき、 僕は 「どういう出来ごとがあって、そう感じたのですか?」 と質問するようにしています。 スクラムの「スプリントの振り返り」会議では、課題(Problem)を上げ、みんなで知恵を振り絞り「これだ!」という解決方法を見つけます。 解決方法を見つけるときに、ブレインストーミングしてアイディアを上げていきますが、 アイディア出しより 先に関連する「事実」を列挙していく ことをお勧めしています。 全員で事実を発表しまくり、それを参考にブレインストーミングすると、アイディアの質も量も良くなるからです。 事実は、全員にとって客観的で異議のないものです。事実以外はNGです。 例えば、「開発が遅い」は感想であって事実としてはNGです。 「納期に1週間遅れた」は事実なのでOKです。 「見積もりをもっと多めにしておくべきだった」は意見であって事実
スクラムの導入は、わからない事が多くて知っている人がいないと導入が難しいという意見をよく聞きます。そこで、ステップバイステップで手順に沿って実施していくと、スクラムの導入がある程度完了していることを目指す説明をしたいと思います。 > スクラムとは?スクラムとは? スクラムはアジャイル開発手法の1つで、スクラムは「柔軟かつ全人的なプロダクト開発ストラテジーであり、共通のゴールに到達するため、開発チームが一体となって働くこと」とされています。スクラムはフレームワークであり、スクラムガイドというスクラム標準の定義もあります。 > 大事な用語大事な用語 スクラムを実施するに当って、スクラムの文脈で頻出する用語の定義を説明します。 > 役割に関する用語役割に関する用語 【プロダクトオーナー】 プロダクトオーナーは、そのプロダクトについて何をどの順番で作るのかについて責任を持っています。 【スクラムマ
こんにちは、れおです。 スクラム導入支援でスクラムマスターとして参加しているプロジェクトの参加者から、「レビューと振り返りの違いってなんですか?」という質問がでました。 スプリント振り返り は、スプリントレトロスペクティブ とも言います。レトロスペクティブは、"すでに起こった出来事を振り返ること。" という意味なので、同じ意味ですね。 > スプリントレビューとスプリント振り返りの違いとは?スプリントレビューとスプリント振り返りの違いとは? スプリントレビューは、スプリント実施で行った製品開発活動にフォーカスしています。一方スプリント振り返りとは、スクラムチームがスクラムやスプリントに取り組むプロセスそのものに対して振り返りを行い、問題や課題を発見し改善を行いプロセスやチームの文化を成長させていく活動です。 > スプリントレビュースプリントレビュー スプリントレビューは、多くの参加者がスプリ
こんにちは、スクラムマスターやってるsuinです! スクラムのスプリントサイクルの最後の活動といえば「スプリントの振り返り(Sprint Retrospective)」ですね。 スプリントの振り返りでは、スプリントを省みてプロセス改善するというのは、reoringがスプリントレビューとスプリント振り返りの違いとは?などで説明してきました。 今日は、この振り返りを明るくするライフハックを紹介します。 > KPTで振り返るのはいいKPTで振り返るのはいい 振り返りでよく使われるフレームワークに、KPTというものがあります。 Keep, Problem, Tryの頭文字をとったもので、 Keep「今後も続ける良い活動」、Problem「解決したい課題」、Try「改善すること」を考えるフレームワークです。 スクラムマスターが開発チームに 「今回の課題はなんですかー?」 「次のスプリントも続けること
こんにちは、suinです! suinの会社で提供しているテスト自動化サービスShouldBeeですが、 有償のプランもあり、クレジットカードで課金もできるのですが、 実は請求書の発行はスタッフが手作業でやっています。 請求書手動発行は、ユーザが増えてくるとミスも多くなりそうなので、自動発行の開発に着手しています。 ただ、請求書の自動発行と一言で言っても、細かいところを考えると疑問が結構出てきます。 請求書はどんなデザインか?何を記載しているか? どんな用語を用いているか? 請求書のメール通知はどうなっているか?PDFを添付しているか? 請求書のPDFはどのツールで生成しているか? PDFのファイル名はどうなっているか? クレジットカード明細の利用店名はどういう表記にしているか? そこで今回は、他のBtoBのウェブサービスが、どんな請求書を出しているのか調査して比較してみることにしました。
最近、ShouldBeeのUIをReact.jsで作り始めています。 Babelを使ってES6のclass構文でReactのComponentを作っているのですが、どうもコールバックのメソッドでthisがundefinedになってしまいます。 例えば、下のJSはボタンのコンポーネントで、クリックしたときに、onClickメソッドが呼ばれます。onClickメソッドの中で、thisを参照していますが、undefinedになります。 import React from "react"; export default class Button extends React.Component { onClick() { console.log(this); // undefined } render() { return ( <button onClick={this.onClick}>Butto
import React from "react"; import ReactDom from "react-dom"; import {PulseLoader} from "halogen"; ReactDom.render( <div> <PulseLoader color="#26A65B" /> </div>, document.getElementById("demo1") ); ローダーは16種類提供されています。 PulseLoader RotateLoader BeatLoader RiseLoader SyncLoader GridLoader ClipLoader FadeLoader ScaleLoader SquareLoader PacmanLoader SkewLoader RingLoader MoonLoader DotLoader BounceLoader
こんにちは、t-hiroyoshiです。 最近はReactやreduxを使ってUIを開発しているのですが、両方ともガンガン更新されていくので追いかけるのがとても楽しい日々を過ごしています。 突然ですが、Reactで開発していて次のようなWarningを見たことはありませんか? Warning: setState(...): Can only update a mounted or mounting component. This usually means you called setState() on an unmounted component. This is a no-op. Please check the code for the undefined component. これはUnmountされたコンポーネントのsetState()を呼んだ時に出るもので、回避する方法があり
「今日からReactを始めたい」 「とりあえずReactで何か動かしてみたい」 ここは、そういった方が、Reactを始めみるためのチュートリアルです。 今回は、Reactを使ってFacebookのいいねボタンのようなコンポーネントを実装していきます。 > 今回作る「いいねボタン」のデモ今回作る「いいねボタン」のデモ 実際に押せます↓ > チュートリアルの目標チュートリアルの目標 Reactのコンポーネントを実装できるようになる Reactコンポーネントのイベントをハンドリングできるようになる Reactコンポーネントの状態(state)を実装できるようになる Reactの雰囲気をつかめる! > このチュートリアルについてこのチュートリアルについて なお、このチュートリアルは、下記のバージョンで動作確認しています。 npm 2.14.2 react 0.14 react-dom 0.14 w
こんにちは! れおりんです!! 朝と夜は大分肌寒くなってきましたね〜! 今回は、Reactコンポーネントの「react-date-range」を紹介していきます! > デモデモ 以下のようにスタイリッシュな日付範囲選択コンポーネントが作れます。 ↓ 実際に操作できます render() { const { rangePicker, linked, datePicker, predefined } = this.state; const format = 'dddd, D MMMM YYYY'; return ( <main className={styles['Main']}> <DateRange startDate='10/11/2015' endDate={ now => { return '11/12/2015'; }} onInit={ this.handleChange.bin
ES6ではexportとimportが追加されてモジュール化が明示的にできるようになりました。 自分はサーバサイドをScalaで書いているのですが、 Scalaのimportなどと比べると、ES6は結構違ったので、 気づいた点をまとめてみました。 > ファイル名が明示的ファイル名が明示的 ScalaやGoにはコンパイルがあるので、importを宣言する場合ファイル名を指定する必要がないが、ES6ではimportするときファイル名を明示する必要になる。 つまり、Scalaのimport FooはES6ではimport Foo from "./Foo"となる。これはどうしようもない。同じスクリプト言語のPHPですらオートローダーがあるのに…。 > ES6は"public"であることを明示する派ES6は"public"であることを明示する派 ScalaにもES6にもパッケージのプライバシーがある
Ruby風のシンタクスで静的型チェックのある言語「Crystal」をMacにインストールし、Hello Worldするところまでやってみたいと思います。 > Crystalの特徴Crystalの特徴 Rubyにインスパイヤされたシンタクス 静的型チェックがあるが、メソッドの引数や変数の型指定を省略できる Crystalでバインディングを書くことでCのコードを呼び出せる コンパイル時評価とコード生成を提供し、ボイラープレートコードを避ける 効率のいいネイティブコードを生成する 個人的に最近Go言語をやっていて、 『動的言語だけやってた僕が、38日間Go言語を書いて学んだこと』などを書いたりもしているのですが、 速度が要求されるプログラムや配布する必要があるCLIツールなど、Go言語でコードを書いて解決しているものをRuby風のシンタクスでやれたら、それは便利だなと思います。 > Crysta
どうもこんにちは! こんばんは! れおりんです! プログラミングをしてテストを記述するときに、モックオブジェクトとか、スタブとかフェイクとか色々な用語があって混乱しますね? 僕は混乱します。開発の打ち合わせなどで開発者間で用語の統一ができておらず、さらに混乱するという場面もありますね。 今回は、それらの違いを説明してみたいと思います。 > スタブスタブ スタブは日本語だと、「代用部品」となるようです。 スタブは、実際の挙動をシミュレートしてテスト実行の支援をするためのものです。スタブとなっているオブジェクトは入力によって出力が変化するようなもの作れますが、とにかく一定の値を返すようなオブジェクトをスタブと呼ぶときが多いように感じます。 オブジェクトの関連のなかで、スタブは他のオブジェクトには依存しません。単純に値やオブジェクトを返却するだけです。 class UserDatabaseStu
ソフトウェアには不具合はつきものです。お客さんからバグ報告が上がってくると、厳しい現場ではハラハラするものです。僕も以前、受託開発の現場にいたので、バグ報告を受けるたびにヒヤヒヤしながらバグ原因の特定と修正をしていました。 僕は今でこそ、どんな不具合でも特定できると思えるくらいになりましたが、新米エンジニアだったころは、バグの特定は決して得意といえるものではありませんでした。 当時、僕がデバッグに詰まっていると、先輩や上司のエンジニアは一緒に原因特定を手伝ってくれたり、アドバイスをくれたりしました。その中で僕が学んだことや、当時お世話になったベテランエンジニアのデバッグアプローチを書いてみたいと思います。 # 今日、たまたま丸一日かけるようなデバッグの仕事があり、ちょうどいい機会だと思い記事を書くことにしました。 > バグ報告を「勘違い」と決めつけないバグ報告を「勘違い」と決めつけない と
サービスは絶対に止めたくない! サービスが止まれば、機会損失や信頼問題につながってしまいます。社内向けのサービスであれば、社員の業務を止めてしまうこともあります。だから、サービスは絶対に止めたくない。インフラは安定稼働が至上命題です。しかし… 強固なインフラを作るのが難しい しかし、止まらないインフラを作るのは簡単ではありません。安定稼働するインフラを作るには、あらゆる障害局面を熟知している必要があります。ところが、社内だけでは経験値が不足していたり、24時間365日の運用体制を敷くための人員確保ができなかったりと、理想と現実のギャップに悩まされます。 セキュリティが心配で夜も眠れない… サービスはオープンしてからが本番です。運用開始後もっとも気になることはセキュリティです。もしも社外秘や個人情報が漏えいしたらと考えると不安です。これまで無事でも、今後も大丈夫とは限りません。今この瞬間、そ
このページを最初にブックマークしてみませんか?
『Craftsman Software』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く