How to involve those who are taciturn into discussion


There is taciturn person in discussion. I introduce the way to let such a person speak. (I omit ice-breaking because it is the method for all persons.)

Premise

Preparation for discussion like clarifying the goal of it is already done. I suppose 1 or 2 person is taciturn in discussion.

( If any valuable opinion doesn’t appear, you may have problem in preparation or proceeding.)

Why you want to hear opinions from all members?

What does occur when there is taciturn person?

  • He say “I thought XX is the best solution” after the discussion.
  • You can’t reach everyone’s agreement and you can’t reach best solution.

Namely, discussion purpose fades away, I think.

Control the number of discussion members, first. It is difficult to discuss over all members when the number of members is greater than 10. I think appropriate number is 6. Please rethink it according to discussion format and content.

Now, I introduce the way to involve everyone into discussion.

Method

Give a role to the person

“I would be appreciated if you could talk from the aspect of XXX in the next discussion. So please join.”

The word should be changed according to your position. Like above, telling “What I want to do” in advance helps him to understand what kind of opinion to speak and how to look the discussion, and make it easy for him to express his opinion.

Ask the person for his opinion in advance

Ask him “What do you think about it?” in advance, individually. Then, if he become taciturn in discussion, you can spread discussion by saying “You have opinion that XXX is YYY, right?”.

Give a task to the person in advance

Opinion doesn’t appear if there is no hint. So give him a task in advance. “Prepare 2 or 3 solution about XXX.” In the discussion, you can proceed with prepared opinions.

That’s a matter of course to prepare for discussion in advance, but some people never prepare until they said to prepare.

Workshop for a small groups

This is effective when discussion member is many. Divide members into groups consists of 3 members and ask them write opinions on post-it. (Or write opinions individually.) In this way, the person who can’t speak in discussion tend to write opinion. Paste written post-it to whiteboard and make discussion deep. It relates to affinity diagram.

You can make discussion deep for each opinion (or selected opinion or categorized opinion), so you can trigger to make him speak by saying “Could you explain what this opinion saying?”

It is OK to write opinion onto post-it by 3 member group with discussing, and to write opinion individually.

Ask the person about his specialty

Suppose members gathered from several sections. Then, ask him “Mr. X, how can you see this issue from YYY aspect?” And after his answer, “Thank you. I was really helped, there’s no person with YYY specialty knowledge.” Thus, involve taciturn persons.

The case this method can be used is may be limited.

Make a rule

Make a rule, “Everyone should put opinion”. Opinion doesn’t appear however strongly he said to put, but such rule make him think about to putting opinion.

Expect Next Time

If he didn’t put any opinion in spite of your really struggling, ask him “Was there something wrong, you looked somehow curious?” Please, take attention to the telling way. This method tells him “we want you to put your opinion” softly.


「やりがいのある仕事」という幻想


「やりがいのある仕事」という幻想

「やりがいのある仕事」という幻想を読みました。仕事に悩んだときにおすすめの本です。

あたりまえのことを 極限まで客観視して書かれた本です。

今の仕事は天職か?

楽しいことを仕事にしたり、仕事をがんばることに意味を見出したり、そういうやり方もあります。 しかし著者はもっと広く考えていました。

仕事が楽しくなければ一体なにが楽しいのか?

ひとつ本書の記述を紹介します。 もっと楽しいことを探してそれを「やる」時間を持つ、 それもひとつのやり方だと書かれています。

これを読んだからといって、明日から大きく考え方が変わるということもないし、どの職業がいいといったことも書かれていない。 だけれども、 転職したい、 仕事やりたくない、 やりがいのある仕事につきたい、 と思い悩んでいる人には 別の考え方で自分を見直す機会を作るという意味で、 とてもいい本だと思う。


FuelPHP migration to multi databases


I’ll explain the way to migration to multi databases in FuelPHP 1.7.2.

In FuelPHP, php oil g model item name:string generate codes of model and migration. And php oil g scaffold ... also generates migration code. Add some essences into the migration code to be generated, and you will handle with multi databases.

Code before editing

Code after editing

I added db_config_key. This parameter specifies which database to use. Specifically, the parameter value is the key described at config/db.php. For example, 'default' is the value of the parameter. If you don’t pass any value, 'default' will be used.

In such way, you can use multi databases, with indicate database to use for each migration code.

Create migration code with Model method

Let’s try to utilize Model methods.

It supposes Model_Item inherits Orm. Model_Item::connection() returns database key, Model_Item::table() returns table name, Model_Item::primary_key() returns primary key column name so you can utilize these methods for migrating if you set table name, database and primary key in model code. And in this way, you don’t have to change migration code when you change table name and so on. (But attention when you change about table name or $_connection of existing model, in db rollback.)


DIxAOP の Java Framework, Spring


Spring3 入門 (技術評論社)
Spring3入門 を Amazonで買う

DIxAOP ってなんだ? と思っていたら、 ある人が紹介してくれました。 DIxAOPについてはわかりやすく書かれているそうです。 パラパラっと見てみましたが、 EAADDD などのアーキテクチャを一通り知っている人が書いた本に見えます。 今回は第1章をじっくり読んでみました。 Spring フレームワーク の前書きみたいな内容で、 Spring を使ったことのない私にはちょうどいいです。

Spring の特徴

Spring の特徴として 際立っているのが DIxAOP だ。 第1章では紹介程度になっているのだが DIxAOP なくして Spring は成り立たないといっても過言ではなさそうだ。

Spring の DIxAOP 設計 は Webアプリケーション が抱える 3つの問題点 を解決する。 以下、簡単にまとめた。

オブジェクトのライフサイクルの問題
オブジェクトの生存期間をコントロールする作りこみが困難
部品化の問題
部品化をするためには実装非依存にする必要があるが、それなりにコストがかかる。 (注: 単にインターフェースを使えばいいという問題ではない。)
技術隠蔽や不適切な技術隠蔽
高レベルの技術を初級レベルの開発者に利用させて不具合を引き起こしてしまったり、不適切な技術隠蔽をしてその技術の利用が困難になってしまったりすることが開発現場でよく起こる。

Spring では、 上2つの問題を DIコンテナ が、 最後の問題を AOP が解決する。

Webフレームワーク というと Rails や FuelPHP, CakePHP などがあり、 「(アクティブレコードパターンの) 簡単にデータベースが使えるもの」という印象を受けてしまいがちですが、 Spring3 入門 では アーキテクチャ の考え方からしっかりと書かれていて EAAに見られるパターンの説明も(第1章では)随所で行われています。 第1章では特にレイヤの分離の説明が重点的に行われています(フレームワークを使う人には是非ともわかるようになっていてほしい内容です!)。 コードの例もあり、全体的にしっかりした印象を受けます。

以下、第1章の中で私が(個人的に)重要だと思った内容を簡単に書き留めました。

アプリケーションアーキテクチャ

プログラムを作る際には 最低でも 2つの方面からの要件・目標がある。

  • ユーザの要件: ユースケースなどで表される機能要求やレスポンスタイムなどの非機能要求
  • 開発者・運用者の目標: 開発期間の厳守、変更・機能追加のしやすさ、テストのやりやすさ

この本では 2つ目の 開発者・運用者の目標 からアーキテクチャの重要性が説かれている。

アーキテクチャに求められるもの

  • 開発効率
    • 意図を把握しやすく、理解しやすい構造
    • テストが容易に行える構造
  • 柔軟性
    • 変更しやすく、機能追加しやすい構造
    • 将来の環境の変動に耐えられる頑健な構造

ティアとレイヤ

Web アプリケーション の アーキテクチャ は ティア と レイヤ に分かれている。 ティア は 物理層 を表し、 レイヤ は 論理層 を表す。

ティア

クライアント層、中間層、 EIS(Enterprise Information System)層 の 3つに分かれるのが基本となっている。

各ティアの例
クライアント層 パソコン、スマートフォン
中間層 アプリケーションサーバ
EIS層 DB、レガシシステム

レイヤ

EAA の冒頭あたりにある分類と同じ分け方でレイヤが書かれている(プレゼンテーション層、ビジネスロジック層、データアクセス層 の3層)。 (もちろん異なる分け方もある。) 互いに隣接するレイヤ間では一方向のアクセスのみ許す。

トランザクション処理がどのレイヤに属するのかは迷うところだが、本書ではプレゼンテーション層とビジネスロジック層の境界と説明されている。

Spring3 入門 (技術評論社)
Spring3入門 を Amazonで買う