VOYAGE GROUP エンジニアブログ : 昼休みを利用して行った勉強会の2012年分をまとめました。
2012年11月20日16:14 カテゴリ勉強会 昼休みを利用して行った勉強会の2012年分をまとめました。 CTOからの挑戦状企画をやってから「あんなこともするんですねｗ」と言われている@makogaです。 年の瀬が近づいてきたということで(まだ11月なので早い気もしますが)昼休みを利用した行った勉強会の2012年分をまとめてみました。 ▼ 1/19(木) 制度を作るときに意識していること 年明け一発目は私が社内制度を設計・運用するときに意識していることについて話をしました。 例がエンジニアの技術力評価の制度だったため質問も多く盛り上がったと思います。 ▼1/31(火) Jumvo2.0におけるデザイナーとエンジニアの連携ボイスメッセージアプリJumvo 2.0のような使い勝手が超重要なアプリを開発するにあたり採用したプロトタイピング手法についてデザイナーの立場とエンジニアの立場からそ
自己組織化と変えられないもの - 未整理整頓@uedayo
10/28 のスクラム道EXPO、11/22 のDevLOVE #99 にて自己組織化をテーマとした事例紹介をさせていただきました。 スクラム道 EXPO 2012 後半まとめ #scrumdo - Yukarin’Note 10/28(日) Change The Future -Self Organized Team!- #devlove - Yukarin’Note 11/22(水) DevLOVE #99 のプログラムの流れとしては、 1) 私の経験談についてプレゼン 2) 各テーブルで解決したい悩みについてディスカッション 3) 全体でのディスカッション というものでした。両日共に私の発表の後にディスカッションを行い、皆の経験や考えをシェアするよい場になったと感じています。 よく聞かれたお悩み 3) の全体ディスカッションにおいて、以下の三つのお悩みが印象に残ったのでご紹介させて頂
NAKAHARA-LAB.NET 東京大学 中原淳研究室 - 大人の学びを科学する: 仕事を振ると「なぜですか?」と問われる : 「意味や理由」を求める若い世代!? にイラつく理由
中原淳（東京大学准教授）のブログです。経営学習論、人的資源開発論。「大人の学びを科学する」をテーマに、「企業・組織における人の学習・成長・コミュニケーション」を研究しています。 企業の人事関係の方とお会いしていると、頻繁に聞かれるボヤキ（最近、ボヤキばかりですね・・・すみません）がこれです。 「最近の新人は、口を開けば、"なんでですか？"。少し仕事を振ると、"これは、なぜやるんですか？"。"なんで？""なんで？""なんで？"の応酬で困ってしまいます。おまえは、"理由"や"意味"なんか知らなくていい、って思うのですが」 これは、いわゆる「最近の若者・・・はダメになった論」ですので、あまり真に受けて考えるのもどうかと思うのですが、なかなか「興味深い論点」だと思われるので、少しだけ、ゆるゆる、ダラダラと考えてみましょう。 ▼ 最初に断っておきますが、僕も、このボヤキには共感できるところはあります
アジャイル導入の壁〜ボトムアップでアジャイルが導入できるのか？ | Social Change!
「アジャイルを導入したいんですが、上司や会社に話が通じません。どうすればいいですか？」・・・アジャイルに触れたばかりの人からよく聞く質問です。 先日、Ultimate Agilist Tokyo というイベントに参加させていただき、壇上インタビューという形式で登壇させて頂きました。楽天の藤原さんからの質問に答えるという形で進みます。その中でも「よくある質問」として、この話が出ました。（決して楽天藤原さんが聞きたいと思っている訳ではなくて、こういう質問ってよく出ますよね、という対談です） そのときの私の回答は、ボトムアップでは難しいんじゃないか、というものでした。そのときは時間も足りなかったので、簡単に答えてしまいました。 この記事では、ボトムアップでアジャイルを導入することについて、壇上インタビューでは答えきれなかった部分も含めて考えてみます。 あなたのアジャイルは何をすることか？ 私は「
JUnitをGroovyで扱うための環境設定メモ(Eclipse4.2) #junitbook - Diary of absj31
JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus) 作者: 渡辺修司出版社/メーカー: 技術評論社発売日: 2012/11/21メディア: 単行本（ソフトカバー）購入: 14人 クリック: 273回この商品を含むブログ (69件) を見る先日11/21に発売し、関連する読書会も同時多発的に本日(11/23、札幌・東京・大阪)開催されるという盛り上がりを見せている書籍『JUnit実践入門 』。 私個人としても書籍写経に際し今回はJavaの他にもGroovyでJUnitテストコードを扱えるようになってみよう、と思い、ひとまずはEclipseでその辺の環境を整えるべく試してみました。以下その際の環境設定メモなど。 Eclipseインストールor日本語化設定 事前にJavaをインストール。 Mac OS X 開発環境構築手順：Java実行環境(jdk7)
JUnit実践入門の感想とJUnit依存具合と読書会と #junitbook - 日々常々
JUnit実践入門が 2012/11/21 に発売されました。献本ありがとうございます！ 初めてレビューもさせて頂きまして、執筆が進むにつれ話題に上げたいなぁとウズウズする毎日が続いておりました。最初に原型っぽいものを見せて頂いたのが 2011/11/23 で、丁度一年になりますか。見た瞬間に「まさにこれが欲しかった！早く世に出て欲しい！」と思ったのは今でも覚えています。 対象は、JUnitナニソレな方から、ある程度使ったことがある方まで。私がよく話してることの多くが、この本にはもっと詳しく書かれてたりします*1。本気でおすすめ。 感想 和田さんの推薦のことばとかぶってしまいますが、やはり特筆すべきは語彙の豊富さです。SUTや4フェーズテスト、テストダブルなどが説明なく通じれば色々捗ります。具体的な話をするときは、これらを下敷きにして話をしたいですね。 ユニットテストはみんな「した方がいい
「初心者が２ヶ月でプログラミングをマスターする方法」なんてない - カレーなる辛口Javaな加齢日記
http://we-b-blog.tumblr.com/post/36103252953/2 またも大嘘レベル．*1 こいつもブラック企業経営者かな？*2 どんな環境にしろ，初心者がプログラミングを二ヶ月でマスターなんて，まず無理．普通は十年はかかる．そこそこ書けるようになるだけでも１〜２年はかかるだろう．「二ヶ月でマスター」といってる時点で大嘘つき認定して問題ない． プログラマのためのサバイバルマニュアル 作者: Josh Carter,長尾高弘出版社/メーカー: オライリージャパン発売日: 2012/08/22メディア: 単行本（ソフトカバー）購入: 5人 クリック: 79回この商品を含むブログ (27件) を見るプログラマが知るべき97のこと 作者: 和田卓人,Kevlin Henney,夏目大出版社/メーカー: オライリージャパン発売日: 2010/12/18メディア: 単行本（ソ
RHEL6/CentOS6では、single-request-reopen を必須にしたい…
2012-11-02 結論から言えば、とりあえず RHLE6/CentOS6 な人は /etc/resolv.conf に options single-request-reopen を書いておこうという話です(全部小文字ですよ、念のため） なぜか？ RHEL5/CentOS5/Ubuntu 10.04なLinuxとかでは、FQDN の解決をするときに DNSキャッシュサーバに AAAA RR の Queryを投げる AAAA RR の Reply を受ける DNSキャッシュサーバに A RR の Queryを投げる A RR の Reply を受ける という挙動でしたが、RHEL6/CentOS6 では DNSキャッシュサーバに A RR の Queryを投げる DNSキャッシュサーバに AAAA RR の Queryを投げる A RR の Reply を受ける AAAA RR の Re
最速最強Webサーバーアーキテクチャ - Qiita
POST /post HTTP/1.1 Host: localhost Content-Type: application/x-www-form-urlencoded Content-Length: 7 foo=bar 1行目は request-line で、 method URI HTTP-version の形をしています。URIはホストを含めた絶対URIの場合と、ホストを含めない絶対パスの場合がありますが、絶対パスの方が一般的です。 2行目から空行までが request-header です。各行は field-name: field-value の形をしています。 field-name は大文字小文字を区別しません。 request-line から request-header とそれに続く空行まで、改行は CR LF になってます。Windowsでよく見る改行コードですね。 meth
文章に向いてない構造をいかに文章に向いた構造に直列化するかが大事 - きしだのHatena
Software Design 12月号の特集が「なぜエンジニアは文章が下手なのか？」というタイトルだったので、読んでみたら、ちょっと残念な内容だった。 「それは文章で書くべき情報なのか」という章があって、直列化した論理構造であれば文章には書きやすいけど、分岐やループがあるような構造だと書きにくいということが書いてあった。そこで文章化しにくい構造の例として地図があげてあって、暗にそういう構造は文章化をやめて図であらわせと言っているように読める。 けれども、図に書いたところで、書く側は文章化から逃げれて満足かもしれないけど、それを読み取る側は結局どこかから順番に解釈していく必要がある。図に逃げるのは、読み手に責任を押し付けているだけだと思う。 で、「ですから文章を書く前にまず論理構造を考える必要があります」と続いていて、では考えた論理構造が「文章に向かない論理構造」だったらどうするの？逃げる
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
