最近のスタンディングデスク事情を調べてみたら、かなりバリエーションが増えていて驚いた！！ (https://commons.wikimedia.org/wiki/File:Sit-Stand-Adjustable-Desk-FlexTable.jpg) 2年前からスタンディングデスクによる作業環境を構築して利用している。座りの作業も併用しながらも、メインをスタンディングにしてすっかり慣れていた。 スタンディング環境を半年続けてわかったこと 自宅の作業環境をスタンディング環境（スタンディングデスク）に変えてから約半年が過ぎた。今の時点で気づいたこと（よい点、困った点）をまとめてみる。 最近、自宅近くに事務所をかまえることになり、良い機会なので市販のスタンディング可能なデスクを購入しようと思って調べてみたら、2年調べた頃よりずっと多くのメーカーが製品を出していることに気づいたので、調べた結果を
2017年10月26日のブックマーク (21件)
-
kakeda 2017/10/26
-
ハタラキカタはイキカタから 〜 IT技術者の働き方改革イベントで登壇してきた話
9/3に行われた、CHANGE WORK 「IT技術者の働き方改革」セミナーに登壇してきました。東京で愛媛に移った自分の話をするのは、2014年にDevLOVEのイベント「とある愛媛県の実践者」で話して以来です。 私の前は、Joy,incの翻訳者の川口さん、安井さん、私の後は、TOCの岸良さんと豪華メンバーなので、私の話が期待されていないのは一目瞭然。とはいえ、自分で今話せることとして、愛媛に移ってからの働き方や生活の変化のストーリーを話してきました。 前段のJoy,incの話のように「喜び」という感情を大切にすること、後段のTOCの組織改革のように、希少リソース（ボトルネック）を特定して解消し、全体最適を実現していくことは、私の話とゆるやかに結びついていたのが面白かったです。 枠組みだけに頼ることなく、個人からできることは？今回、メッセージはハタラキカタの前にイキカタを考える、ハタラキカ
-
40代から始めたレガシーボディ改善物語
2016年5月31日に開催された アジャイルジャパン2016 の会場にて、EM ZERO vol.9の配布を開始いたしました。 アジャイル開発入門（西河 誠） 「アジャイル」「DevOps」「クラウド」言う前にすべきだったこと（渋川よし… 当時、久しぶりに真面目に書いた記事だったので、ちゃんと公開したいなぁと思いつつ、１年以上が過ぎてしまいました。たまたま見つけたので、今回ここで加筆修正して公開することにしました。 オリジナル記事は、マナスリンクの野口さんにレビューして頂きました。重ねてお礼申し上げます。 はじめに久しぶりのEM ZEROへの執筆ということでワクワクしています。今回は、ここ数年取り組んでいるヘルスハック（健康増進の工夫）について触れてみたいと思います。 失敗の数々これまで、人生の中で多くの失敗をしてきました。その中でも特筆すべきなのはダイエットの失敗です。 子供の頃から大柄
-
-
-
「トレーニングの全体最適」としてのParkour Strength Training、Methode Naturelleについて
『Parkour Strength Training』XP祭り2017でワークショップをしにいったのですが、野良LTが昼休みに行われると聞いて、急遽当日スライドを作って（午前中）参戦してきました。ネタは「筋トレ（またはトレーニング）」です。といっても午前中のセッションを聞きながら作ったので適当ですけどね。 ランだけじゃ補えない体づくり私を知ってる人は「あいつは走ってばっかり」の印象をお持ちでしょうが（実際その通りですｗ）、昨年末から、上半身も含めたトレーニングも徐々に行ってきたので、そのことを野良LTで発表してきました。 ただの筋トレは飽きるし続かない自分はいわゆる「筋トレ」はすぐに飽きてしまいます。一時期は自重トレ用のアプリを導入して自宅でやっていましたが、結局続きませんでした。よくあるジム通いは、場所や時間の制約がある時点で行かないことは自明です（元々走った理由の1つが、自分のやりたい
-
-
ソフトウェア開発の基本的な問題〜 18年前からXPが提示するリスクの紹介
自分が、ここ数年アジャイルのトレーニングの際に必ず示している図がある。それが「エクストリームプログラミング」の第一版から第一章で提示されている、ソフトウェア開発に関するリスクについての図だ。 先日、Agile459のオンライン読書会で紹介したら好評だったので図を貼って置くことにする。 念のため、エクストリームプログラミングを読んだことのない人向けに説明しておくと、これらの元ネタは書籍（初版では１章まるごと、第二版・新訳版では１章で部分的に）では列挙されているが、本文に列挙されているだけなので、自分なりに整理してこのような図にしている。 実現できないスケジュールが遅れたり、度重なる遅延で実現の前に資金がなくなりプロジェクトが終わってしまうというリスクがまず最初にある。 動かないなんとか実現しても、欠陥が多くまともに動かなかったり、その結果としてシステムが劣化（＝メンテナンス不能に）になり、作
-
職住同一から職住近接になってわかったメリット・デメリット
神奈川トヨタ自動車の現場メカニックとして入社後、そこで挙げた成果をもとに「カイゼン」関連の執筆・講演活動を展開し、WEBマーケティング事業を推進する会社を設立するなど活躍されている原マサヒコさん。 そんな原さんがコワーキングスペースを契… 職住同一は強い結びつき（あえて同一にはしていない）元々、自宅を仕事場として利用していた。自分の最近の仕事は、客先へ行ってのコンサルティングと、オンラインでのコンサルティングが多いので、オンラインミーティングを頻繁に実施している。出張や客先に行くときはその限りではないが、PC上の仕事は自宅で完結できる。いわゆる職住同一だ。 以前は、松山市の中心部のコワーキングスペースやカフェに行って仕事をしていた。しかし今やっている仕事は多数の文献を参照しなくてはならなく、移動にそれらの文献を持参していくのはさすがに大変なため、次第に外出して仕事をする機会が減ってしまった
-
君はWard Cunninghamを知っているか？（前篇）
AmazonでAndrew Hunt, David Thomas, 村上雅章の新装版 達人プログラマー 職人から名匠への道。アマゾンならポイント還元本が多数。Andrew Hunt, David Thomas, 村上雅章作品ほか、お急ぎ… 君はWard Cunninghamを知っているか？が、その前に寄り道です。今回は、達人プログラマーの序文を書いた Ward Cunningham(ウォード・カニンガム. 以下 Wardと略す)に触れたいと思います。Ward は、今のソフトウェア開発の歴史に影響を与えた活動と成果が幾つかあります。それは、Wiki、パターン、CRCカード、エクストリームプログラミング（XP）、Fit、そして技術的負債です。Ward の名前を知らなかったとしても、いくつかの言葉は聞いたことがあるでしょう。 この記事を書こうと思ったのは、訪問先の若手2年目が達人プログラマーの序
-
君はWard Cunninghamを知っているか？（後篇）
Fit for Developing Software (https://goo.gl/FqRtmo)前篇に引き続き、Ward Cunningham（Wardと略） の活動について解説します。前回は、Wikiとパターンについて触れました。今回は、CRCカード、エクストリームプログラミング（XP）、Fit、そして技術的負債について触れます。 Ward CunninghamとKent Beckとの出会い前編でも触れましたが、ソフトウェア開発の歴史の上で Ward とKent Beck の出会いは大きかったと言ってよいでしょう。 http://wiki.c2.com/?WardAndKent 複数人でカードを使って対話しながら設計する CRCカード２人は、パターンの他に、Smalltalkの分野でいくつかのライブラリ−を公開し、CRCカードを使った設計アプローチの論文について1989年に公開しま
-
POStudyのLTを観に行ったら、やっていき、のっていきのバーンだった
「やっていき、のっていき、バーン」のプロダクト開発が、組織に新しいムーブメントを作るのにも生かせるのではないか、という話。
-
忙しい人のための「達人プログラマー」斜め読みガイド
より良いプログラマになるための実践的アプローチを説く名著 本書は、Andrew Hunt and David Thomas, The Pragmatic Programmer (Addison Wesley, 1999) の日本語版です… 頭から一気に読もうとしない「達人プログラマー」は少し分厚く、内容もスラスラと読めるタイプの本ではありません。内容が難しい箇所もあり、途中で読むのを諦めてしまうかもしれません。発表当時の技術要素でピンと来ない箇所もあるでしょう。（新装版では配慮されて、現代の技術要素も追記されています。）。でも、心配することはありません。エンジニアのキャリアを重ねるなかで、定期的にこの本を開くことで、どんどん味わい深くなるのがこの本の魅力です。 また、同僚とエンジニアとして大切にしたいことを「達人プログラマー」を通じて共有したくなる箇所がいくつか発見できるはずです。私の場合
-
タスクをどんどん、DONE（どーん！）しよう♪
https://www.flickr.com/photos/iyoupapa/30887372435/2017は、勢いよくどーんと行きましょう。今日は、僕の経験とスクラムをもとに、プログラマがどんどんタスクを終わらせ、DONE（どーん！）させるコツをお伝えします。極めて簡単なコツなのですが、アジャイルコーチをやると毎回指導しているのを思い出し書き出してみました。 何ができればDONE（どーん！）なのかタスクのゴールの条件を明らかにするプログラミングのお仕事は、１人で完結することはほぼありません。仕事の依頼主が期待する結果は何か、なにができればタスクが終わったと言えるのかを合意することは欠かせません。また、運用担当やテスト担当などの同僚へどのように引き渡せば、困らないかを把握する必要があります。終わりの条件が多すぎるのであれば、ステップ・バイ・ステップでゴールへ向かうことができるように、ちょ
-
CoolなソロとHotなペアプロのあいだ
チームでプログラミングをする際、幾つかのスタイルが存在します。どの場面でどのスタイルを使うかについて経験を元にご紹介します。 https://commons.wikimedia.org/wiki/File:Pair_programming_1.jpg一人が黙々とプログラミングするソロのスタイル、ソロでプログラミングしつつも「（WIP）プルリクエスト」のオンライン上「コードの共同所有」で集団で洗練させていくスタイル、２人が同じタスクを同じディスプレイを共有し対話しながら難しい問題を解いていく「ペアプログラミング」スタイル、複数人がホワイトボードと巨大なディスプレイに集まって寄ってたかって、議論しながら開発する「モブプログラミング」スタイル、などがプログラミングスタイルとしてよく知られています。 しかし、実際の開発の現場では、「ソロプログラミング」「プルリクエスト」「コードの共同所有」「ペアプ
-
Go言語をTDDで学んでみた話（続き）
前回からの続き前回に引き続き、Go言語をテスト駆動開発（TDD）を使いながら学びを進めてみます。前回の記事はこちらをお読みください。 さて、まずはここまでのTODOリストを見てみましょう。#TODOの下はこれからやるべきタスクで、#DONEの下はすでに完了したタスクになります。 #TODO 0の場合、4000の場合はエラー 4の場合はIV 9の場合はIX 5の場合はV 40の場合 50の場合 11の場合はXI (1-3999で抜け漏れをあとで...考える) gorename を試す VSCodeで保存したら即テスト実行の方法を探す# DONE 10,20の場合 1 => Iの変換ができること。 APIの見直し（オブジェクト指向風のメソッドに置き換え） Goでよく見かけるデータ駆動型のテストに置き換え 2 => IIの変換ができること。今回は、気になっていたエラーケース(0の場合、4000の
-
-
Medium
You can find (just about) anything on Medium — apparently even a page that doesn’t exist. Maybe these stories will take you somewhere new?
-
-
スタブ・モックは本当に悪者なのか？〜テスト駆動開発をやめて、なお残すべき習慣とは (2)
技術詳細は外側へ寄せるポイントは、中心となる対象ドメインは何か？中心から排除したい要素は何か？を考慮して区分けすることです。中心のドメインから排除したい項目の代表例が、データベースアクセスや外部Webシステムやメッセージングといった詳細の技術要素です。ドメイン駆動設計の設計判断を取り入れている場合は、オブジェクトへのアクセスするためのRepositoryのインタフェースのみを中心ドメインに入れ込み、Repositoryの実装（特定のデータベース種類やSQLなど実装詳細）は外側に追いやります。同様に、インタフェースのみを中心にいれてメッセージングや他のWebシステムのアクセス等の実装の詳細は外部に追いやります。 うまく区分けできれば、中央に残った純粋なビジネスについてのルールや状態遷移についてをユニットテストやリファクタリングを継続することができます。リファクタリングによる設計改善を継続する
-
あなたのテストの盲点はどこにある？〜テスト駆動開発をやめて、なお残すべき習慣とは(3)
http://studiototoro.com/musukarakka-471より改変前回、スタブ・モックの使いどころの再考について触れました。そのなかで、ユニットテストのみに頼るのは、盲点が生まれるという点を指摘しました。「群盲象を評す」という寓話があります。各々の盲目の人が象の一部を触って象を語るだけでは部分でしかありませんし、盲点も消えません。 象の部分を統合して初めて全体を語れるように、一つの視点では盲点ができてしまいますが、複数の視点があればそれを防ぐことができます。 今回は、アジャイルテストの４象限を使って、テスト観点の全体像をお伝えし、次回では多重のフィードバックループについて盲点を少なくする仕組みについて解説します。 テスト駆動開発のスタイルをやめたとしても、自分たちが作り続けているプロダクトが期待通り動き続け、プロダクトがユーザや市場によりフィットしていくようにするには、
-
- 2017年10月30日
- 2017年10月26日
- 2013年4月26日
公式Twitter
- @HatenaBookmark
リリース、障害情報などのサービスのお知らせ
- @hatebu
最新の人気エントリーの配信
キーボードショートカット一覧
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Copyright © 2005-2024 Hatena. All Rights Reserved.
設定を変更しました