複業で個人事業主を1年やってみた。 - うさぎ組
2019年1月から「うさぎ組」という個人事業主をしています。 会社員との複業でやっていて、半分ずつくらいという感じです。 1年でどんな仕事をしてきたのか、どんな感じなのかなどをまとめておきます。 概要 個人事業主で半分くらいを仕事できた。値下げなし。 つながらない仕事もたくさんあるのは会社員と一緒だった。 友達にたくさんたすけてもらった。 kyon-mm.com 開業 知ってもらう 仕事の内容 スポンサー 発表 Youtubeでトーク 売上など 育休 最後に 開業 個人事業主をやるとはどういうことなのか、法人にするとどうなのかみたいなのかは、周りのエンジニア、アジャイルコーチ、零細企業の社長などにきいてまわりました。結果として個人事業主をつくって複業スタートが楽そうだとなりました。 開業は freee というウェブサービスをつかっておこないました。また管理も freee をつかっています。
ある改善、プラクティスやTryをいつやめるのか。もしくは5000枚のKPTの理由。 #scrumosaka #rsgt2019 - うさぎ組
先日、 Scrum Fest Osaka 2019というカンファレンスでとある方からこんな質問をうけました。 きょんさんのチームでは、何度かやればうまくいきそうなTryとかプラクティスがあるときに、いつまで挑戦するとか、いつになったらやめるとかそういった基準とかはありますか？ これ聞かれたときに昔の自分だったら「やれなくなるまでは挑戦しつづける」って答えていたとおもうんですよね。でも、今は違うなーと。 僕が答えたのは「やりたい意思がある限り続ける。やりたくないものをやるのは楽しくない。」で、もっと端的にいうと チームにできるプラクティスは残るし、できないプラクティスは残らない。 というものです。ある種の適者生存というか。プラクティスが正しいから残るのではないというかんじですかね。 ただ、それだと怠惰でルールのないチームは一向に成長しないので、成長するための仕掛けは必要だとはおもいます。 で
OOじゃないDDDについて - うさぎ組
概要 モデリングについていろいろ - Togetterまとめを読んでいて、前にも何度か言ったことがあるけれど、もう一度言っておこうかー的な感じです。多分ブログには書いていませんでしたので。 端的に言えば、パイプ&フィルターパターンがアプリケーションドメインであるアプリケーションもあって、そういったものはオブジェクト指向より関数型的なほうがうまく適合する可能性もあるという話。 DDDとプログラミングパラダイムやプログラミングスタイルは直交するはずだ Eric Evansから提案されたDDDはクラスベースOOを主体とした実例が多かったわけですが、DDDという概念はOOを前提としていないと僕は捉えています。特に、ユビキタス言語、コンテキストの明示、モデリングと密接な開発といった部分は多くのソフトウェア開発において役立つと言えそうですし、おそらくはプロダクト開発全体でも言えそうです。 エンティティ
2014年に読んだ技術書で良かったもの - うさぎ組
概要 新刊にかぎらず、今年読んでいて「あー、良書だなー」って思ったものをあげています。これ、ダメじゃないの？とか、あー、やっぱりこれいいよねっていうコメントもらえると嬉しいです。 基本は、.NETにおけるWeb APIやFW開発でQA * POな人が思う良書です。今年は技術書より論文、言語仕様書、実装を読んでいることが多かったので、去年の半分の30冊くらいしか読んでいないかな。 開発チーム系 エッセンシャル スクラム 作者: Kenneth S. Rubin出版社/メーカー: 翔泳社発売日: 2014/08/01メディア: Kindle版この商品を含むブログを見る スクラムなんとなくわかっているんですけど、自分以外の状況よくわからんしなー、進め方変じゃないかなぁっていうときに、読むとめっちゃ参考になります。 組織パターン 作者: James O. Coplien,Neil B. Harri
テストをテストする方法-ミューテーションテスト- #gadvent - うさぎ組
はじめに これはG* Advent Calendarの12日目の記事です。今日はミューテーションテストについて書きます。明日はid:nobusue さんです。 概要 PITというツールの紹介です。「Javaプロダクトコードを機械的に変更してからテストを実行したときに、テストはそれを検知できるのか？」ということを調べてくれるツールで、SpockのテストやGradleからの実行に対応しています。 ミューテーションテスト ミューテーションテストとはざっくりと言えば「プロダクトコードを変更したなら、その振る舞いも変わるはず。テストはその変更された振る舞いを網羅できているかを調べる」というテストです。 対象規模が小さければ手動で毎回やってもいいわけですけど、ツール化されていると楽なことこの上ないです。ということで、今回はJavaプロダクトコードをミューテートするライブラリであるPITについて紹介しま
Gradleを入門する方法から更に知る方法まで #gadvent - うさぎ組
はじめに これはG* Advent Calendarの1日目の記事です。今日はGradleの勉強方法について書きます。明日はid:kyon_mm さんの「Spock1.0でBDDする」です。 概要 GradleというGroovy製のビルドツールが最近人気になってきていますが、なにを参考に勉強するのがよいのかをここで示します。社内で広めるときの参考にしていただければ幸いです。 全体のステップ おそらく多くの人にとっての入門のステップとしては次がよいかと思われます。 Gradle徹底入門 Gradleユーザーガイド（日本語あり） Gradleのsamplesディレクトリのサンプルプロジェクト 各種ブログなど Gradle Forum（英語） Gradle DSL Reference（日本語あり） 各種プラグインのSource Code Gradle本体のSource Code まずはまとまった
テスト全体の良い書き方について。 #swtest_jp - うさぎ組
概要 テストをつくるときにどうやって書いたらいいのか困るという話をよく聞きます。とても簡単な例ですが、これをするだけでもずいぶんと違うという意味で、自分がよく使う例を書いてみます。（実際にはリスクベースドテストとして成立させるために更に項目を追加したものを使っています。ですが、基本はこの形であり、ここにある考え方が重要だと思っています。 つまり、ツールを使えばもっと綺麗に出来るけど、まずはMarkdownでもExcelでもなんでもいいからやれる感じで整理できる方法というところです。 僕がこの考え方を気に入っているのは、プロジェクトのリスク管理手法とあまり違わないので、別にテストではなくて、例えば「こういった人が必要」とか「こういったツールがいる」とかになるという点です。 まとめすぎると「BDD-Styleに対して、リスクという親要素を加える」というくらいです。 構成のテンプレ 基本的に3段
技術書を買ったけどなかなか読了できない理由 - うさぎ組
読みたいと思った技術書を買ったけれど、半年たっても読了できていないとか、最初の10ページだけ読んであとは読んでいない。読み終わったけど最初の方は忘れていて書籍の内容が自分の中で体系化できていない。そしてそれを後悔しているという人がいると度々聞きます。 自分もそういうことがあるのでなんでそうなってしまうのか振り返ってみました。みんなどうせこうだろ？とかではなくって、僕はこうだったわーっていう感じ。 基本的には次の3つかなぁと思います。 先送りにしてしまう 前回読んでから今回読むまでの期間が長過ぎる 書いてあることを復唱するだけになっている つまり 先送りにしない 出来るだけ短い期間で読み切る 要約と応用事例を考える を徹底すればだいたい読めます。これを出来ないときは買わない方がいい。と僕は割り切って書籍を買ったり借りたりするようになりました。（課される場合は別です。） 先送りにしてしまう 皆
テスト仕様書がExcelで何が悪い - うさぎ組
僕もExcelでテスト仕様書を書くのは嫌なときがあります。全員OrgMode使えば幸せなのに！！！って何度思い、CucumberのフィーチャファイルはOrgModeから書けないという点をのぞいてすばらしいとか思っています。 でも、Excelのテスト仕様書をすごく嫌う人って、たいていはその人が使っているフォーマットがすごく気に食わないだけな気がしています。 なんでそう思うかって言うと、「さぁテストケースを書いて僕に見せてよ」とか言うと、8割くらいのひとはスプレッドシートをつかっています。（僕の勉強会観測範囲）その人たちがExcelのテストドキュメントをいやがっているかどうかは未だにわかっていませんが、結局使いやすいから使っているんじゃないでしょうか。 なので、「こういったフォーマットがいやだー」っていうのはわかるけど、でもスプレッドシート使いやすいんでしょ？とか、じゃあ、きれいなテストドキュ
ソフトウェア開発では出来るだけ言葉遣いに気をつけよう。さもなくばマサカリを受けろ。 - うさぎ組
はじめに 言いたい事はわかるんですけど、ふわっと言葉を使っていると間違っていることもあります。 ということで、ほとんど自戒なのですが、今や私も気になる部分は多々あるので、私が思う気を付けたらいいよっていう言葉のリストを以下にあげます。気をつけましょう。 なお、本稿では実際の定義は皆様に調べていただく方向ですので、書いておきません。これ調べたらいいよ的なガイドワードくらいです。 証明する 例えば「このテストによって証明されている」これやばいですね。 テスト界隈からも証明プログラミング界隈からも数学界隈からも目を付けられます。 少なくともそれはなごやに囲まれる事を意味します。 基礎 書籍や記事やイベントで「基礎」とみかけますが、結構な割合で入門と勘違いしているケースがあります。それはよくないです。基礎 と 入門は違います。入門向けな予定なのに、基礎と書いたがために、こわい人たちが大挙した勉強会
コードカバレッジで見落とされがちだと思う事 - うさぎ組
はじめに みなさんがいろいろ言いたい事はあるだろうから、むしろみなさんの意見を聞きたい。はてなブックマークのコメントとかではなく、直接このブログのコメントか引用した自身のブログで書いてくれれば幸いだ。 コードカバレッジ 日本語で20冊くらい書籍がでているようなプログラミング言語で、しかもテスティングフレームワークについても紹介されているような言語であれば、最近ではだいたいは「テストコードの実行によって実行されたプロダクトコードのパスカバレッジを計測するツール」であるところのコードカバレッジツールはあるでしょう。 JavaであればJaCoCoというツールがありますし、最近だとCoverallsというサービスもありますね。 どれくらいだといいのか？ コードカバレッジがバグ検出と強い因果関係にはなさそうであるというのが、自分の周りで聞く事が多くなりました。また、先日そういった論文も発表されたよう
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
