レインボー・シックスのシックスは、なぜ指揮官を意味するのか、そのわけ

f:id:habitmaker:20160920081615p:plain

トム・クランシーの小説をベースにした、戦術×FPSというジャンルのゲーム、レインボー・シックス

シリーズ最新作のSiegeが発売されています。

多国籍の特殊部隊である、レインボー(Rainbow、虹)という組織。 レインボー・シックス(Rainbow Six)は、「レインボーの指揮官」という意味になります。

なぜシックス(six、6)が指揮官という意味なのか、調べてみました。

こちらに解答がありました。

http://www.urbandictionary.com/define.php?term=six&defid=419799

six
In military terms, six refers to either the commanding officer in a particular group, since the commander is usually "in the rear" or at the 6-o'clock position compared to the other members of the group. Or it can mean behind you (your 6-o'clock).
1) Bravo-Two, this is Bravo-Six, over? 
2) Check your six!


6
軍事用語において、6は特定の集団の指揮をとる将校を指す、なぜなら指揮官は普通は「背後」におり、つまりチーム内の仲間と比べて6時の方向に位置するからである。もしくは、単に人の背後を指す。(あなたの6時の方向。)
1) ブラボー2へ、こちらブラボー6(指揮官)である、どうぞ。
2) 背後を確かめろ!

なるほど、指揮官は大抵、背後から指示を出すので、背後=6時の方向でシックスなんですねー。

watch your six!で「背後に気をつけろ!」という意味になります。かっこいい表現なので覚えておこう。

PCで見たサイトをすぐスマホで見たい→Pushbulletが超便利【2クリックで転送】

photo by daspader

こんにちは、habitmakerです。

日常生活で、PCで見ていたページを、今すぐスマホで見たいというシーンが増えていると感じます。

  • PCでスマホアプリのダウンロードリンクが出て、スマホですぐダウンロードしたい
  • 出かける前にPCで調べて、そのページをスマホに送ってから家を出たい
  • 自分のブログがスマホからどう見えるか調べたい

こういうときに、みなさんはどうしていますか?

GmailEvernoteの下書きにURLをコピーして、スマホで同期させたりするのはクールではありません。

2クリックで済むPushbulletを強くオススメします。


目次

続きを読む

さいたま市図書館、パワーアップリニューアルの衝撃【電子書籍サービスも開始】

photo by jessamyn

こんにちは、さいたま市図書館ファンのhabitmakerです。

2016年2月22日から3月2日まで、さいたま市の全図書館、休館。

f:id:habitmaker:20160305163415p:plain

2016年3月3日 さいたま市図書館、リニューアル、開館。
(PDFリンク)

この日を、私より心待ちにしていた人がいただろうか。いや、いない。(反語表現)

というわけで、今回は何がどうパワーアップしたのかまとめました!!

予想を遥かに超えた進化でした。図書館を支える人々とシステムに畏敬の念をもって、書きたいと思います。

合わせて、サイトの使い方も説明しています。

前回の記事を呼んでいない方は、こちらを先に読むことをオススメします!

habitmaker.hatenablog.com


目次

  • 1 貸出ルールの改善
    • 回数制限なく最貸出ができるようになった
  • 2 ホームページのリニューアル
    • トップページ
    • 全25図書館の連携は健在!!
    • 新機能:マイページの「わたしの本棚」
    • ① わたしの本棚(お気に入り資料照会)
    • ② わたしの本棚(読書記録)
    • サイトには読み上げ補助機能や、多言語対応も
  • 3 スマホページがリッチに!
    • トップページ
    • 貸出状況照会
    • 予約状況照会
  • 4 New! さいたま市電子書籍サービス
    • 使用レポート:kindle, Audibleのごとく
    • スマホブラウザでも使いやすさ抜群
    • 電子書籍数はまだ少ないが、今後発展のポテンシャルを大きく秘める
  • まとめ:偉大なリニューアルプロジェクト
続きを読む

記事に画像が多いはてなブロガーは、Evernoteで書くのが超オススメ

photo by /Sizemore/

記事に画像が多いはてなブロガー、habitmakerです。

はてなブログには、Evernoteで記事を書いて、それを取り込む機能があることをご存知でしょうか?

この機能が使えて助かるので、ご存じない方へ紹介したいと思います。

どう助かるのかというと画像編集・アップロードまわりに関してです。この記事の読者対象は、記事に画像をたくさん入れたいはてなブロガーです。


目次

続きを読む

Macでモニターは買う必要なし!TotalSpaces2で、Mac1台で複数スクリーンを操る

(※注:最初に書きますがTotalSpace2は現時点でOSX 10.11 El Capitanには完全には対応していません。しかし動かす方法はあるようです。詳しくはこちら。10.10以前はOK)

私のMac作業効率を劇的に変えたTotalSpaces2

私は長年Macbook AiriMacを使っており、モニターと繋げて本体と2画面で仕事をしていました。

しかしこのアプリを入れてからはすべてが変わりました。

totalspaces.binaryage.com

続きを読む

ベトナムの社員旅行に参加して感じた、ベトナム人の「素直さ」

ベトナムホーチミン市にあるオフショア開発ラボが参加する、合同の社員旅行に行ってきました。

行き先はベトナムの中部のダラット。 軽井沢のような冷涼な気候でした。

チームビルディングというアクティビティがありました。
100人以上の参加者で

  • 列を作ってダンス
  • バナナボートに人を乗せて、ボールを網の中に入れたら成功
  • 水風船を二人で投げて、キャッチできたら成功
  • 二人三脚
  • カラフルな豆をお皿に貼り付けて、その美しさを競う

のような運動会のような競技を行いました。

もし日本の会社でこのような会をやったら、

  • 「なんでこんな子供みたいなことをやらされるんだ」
  • 「意味が分からない」

のような意見が出て、しらけて誰も真面目にやらないと思います。

しかしベトナム人の社員の人たちは、全力で参加して、本当に楽しそうに上記のような競技を行っていました。

この姿勢はとても衝撃的でした。

用意された環境・ネタに対して、その裏などを考えず、素直に乗っかって楽しむ。

この気質は、日本人の姿勢と対照的に感じました。

【英語】オフショアWEB開発でよく使う英語表現・実際の会話例

f:id:yonotown:20151003180341j:plain

2015年6月からベトナム・ホーチミン市にて、オフショア開発(web)のPMとして働いています。 ベトナム人開発者に仕様を伝え、開発を管理し進める仕事です。

コミュニケーション手段は

  • redmineなど文章は全て英語で記載する
  • 対面も、英語で話して伝える
  • 複雑な内容のみ、ベトナム人通訳スタッフ(日本語<->ベトナム語)に伝えてもらう

というスタイルで、可能な限り英語で仕事を進めています。

今回は、Web開発で使う英語を知りたいという人向けに記事を書きます。

  1. 毎日の業務でよく使っている表現を、思いつく限りまとめてみました。
    これらの表現できちんと通じて仕事が進んでいるので、一応実戦的なオフショア開発の英語になると思います。

  2. 開発シーンでの実際の英語のやりとりを書きおこしてみました。
    参考になれば幸いです!

1. 開発でよく使う英語表現

specification

仕様。specとも略される。 システムがどのように作られるべきかを定義、規定したもの

  • spec document 仕様書
  • The specification is complicated(complexed). 仕様が複雑だ。

implement

実装する。 仕様が決まった上で、それに沿って「作り上げる」という意味合い。

  • Please implement this function. この機能を実装してください。
  • Do you understand how to implement? 実装のイメージはついていますか?

design

設計する。designの1単語だけだと設計という意味が伝わらないので、後ろに目的語を付ける

  • design DB scheme DB設計する(直訳だとデータベーススキーマをデザインする)
  • design classes and methods クラスやメソッドの設計をする

architecture も設計という意味だが、それに加え「そのように設計された思想・理念」という意味も含む。設計思想。アーキテクチャ。

execute

実行する。ターミナルで打ち込むコマンド、SQL文、バッチなど何にでも使える。

  • Chef-solo will be executed in the server. chef soloがサーバーで実行される
  • I executed SQL to the production DB. 本番DBに対してSQLを実行しました

wrap

システム(APIなど)が別のシステムの受け口となっている。ラップしている。

  • The API wraps the search engine, so you don't have to understand how the search engine works precisely, you can just concentrate on how you use API.
  • APIが検索エンジンをラップしているので、検索エンジンの細かい挙動について完全に理解する必要はありません、APIを(仕様通りに)使うことに集中してください。

take time

(問題を解決するのに)時間がかかる。

  • I took time to introduce capistrano. capistranoを導入するのに時間がかかりました。

solve

(問題を)解決する

  • I took time to solve the issue(problem). 問題を解決するのに時間がかかりました。

see

システムがDBなどを見ている、そちらに向いている

  • This app sees staging DB, not production DB. このアプリは本番DBではなくステージングDBを向いています。

〜 so that S can V

SがVできるように〜する
この構文はかなり使える。

  • Please fix so that the number of items is displayed correctly. 商品の数が正しく表示されるよう、修正してください。
  • Please update wiki so that every developer can understand the spec of the system. 開発者全員がシステムの仕様を把握できるよう、wikiを更新してください。

work

システムが想定された通りに正しく動く。

  • I deployed to staging environment, but it's not working. Please check.
  • ステージング環境にデプロイしたけど正しく動いていません。確認お願いします。

make sure

(念のため、きちんと)確かめる。
システムのテストのときによく使われる。

  • Please make sure that it works in the staging server. ステージング環境で正しく動くことをきちんと確かめて下さい。

want 人 to V

人にVして欲しい。
この構文もよく使う。
would like (= want) で、マイルドにした言い方になる。

  • I want him to solve this problem. 彼にこの問題を解決して欲しい。
  • I would like you to understand the spec. あなたに、仕様をきちんと理解してほしい。

2. 実録:開発シーンでのやりとり

最後に、開発での実際のやりとりがどんなものなのか、書きたいと思います。

状況

  • ECサイトの管理画面、csvファイルの商品アップロード機能を開発中
  • 商品追加でDBのトランザクションが使われているが、トランザクション中に実行されるクエリが多すぎてテーブルロックがかかり、DBが重いという問題がおきている
  • サーバータイムアウトが発生し、アップロードに失敗する状況
  • その解決方法についてskypeで話し合っている

Aさん(日本人PM)の発言

I think too many queries are executed in one transaction.
I think transaction should be used like this:

BEGIN
only 2 or 3 queries
COMMIT or ROLLBACK

to avoid the lock in DB for a long time but we don't have enough time to fix all...

B-san, please tell me your opinion about this issue.

(和訳)

1つのトランザクションでクエリの実行数が多すぎると思います。
トランザクションはこのように使われるべきだと思います:

BEGIN
2つか3つのクエリ
COMMIT か ROLLBACK

DBで長時間のロックが発生しないようにするためです
でもこれを全部直す時間はないですね...

Bさん、この件について意見を聞かせてください。

Bさん(ベトナム人開発者)の返信

For Big Task vs Server Performance - issue, generally there are 2 approaches:

  1. Split the work into small parts
  2. Put the task into background process, and report the result asynchronously with the call.
  3. Increase hardward configuration (timeout, memory, cpu..) <--- worst case, not use.
大きなタスク vs サーバーパフォーマンスの問題は、概して2つのアプローチがあります:

1. タスクを小さなパーツに分割する
2. タスクをバックグラウンドプロセスとして実行し、終了したら結果を非同期に通知する
3. ハードウェアの設定をあげる(タイムアウト、メモリ、CPUなど) <-- 最悪のケースのみ、使わない

We are thinking on approach 1. Split the work.

a) Split on server:
Like what you said, BEGIN insert 5 products COMMIT
If user insert 100 products, and it failed at product 11, i.e the first 10 products are committed,
we can send back to user the file contain list of 90 products that is not added.
They will update the file and upload those 90 products again.

But this does not solve the 'timeout problem'.
The browser still wait for a long time to see the result, and it will be time out if number of products increase.

我々はアプローチ1をとります。1.タスクを分割する方法です。

方法a) サーバー側で分割する
あなたがさきほど言っていたように、 BEGIN、5つの商品を追加、そしてCOMMITします。
もしユーザーが100商品追加して、11商品目で処理失敗したとき、つまり10商品がコミットされたとき
追加されなかった90商品のリストのファイルをユーザーに送り返せます。
ユーザーはファイルを修正し、再度90商品をアップロードできます。

しかしこの方法では「タイムアウト問題」は解決されません。
ブラウザが結果を長時間待つことは変わりなく、商品数が増えればタイムアウトが起こります。

We need
b) Split on client (browser):
javascript parse the csv file, and split into many parts,

100 products = 20 parts x 5 products.

Javascript will ajax submit each part into server, and get the result instantly for each part.
It will report interactively to user.

For example:
5 products upload successfully
5 products upload failed
5 products upload successfully
5 products upload failed
5 products upload successfully
5 products upload successfully
....

Then finally it let user download the report, will all the failed product, for them to upload again.

我々が必要なのは
方法b) クライアント(ブラウザ)側で分割する です。
JavaScriptでcsvファイルをパースし、多くのパーツに分割します。

100商品 = 20パーツ x 5商品

JavaScriptは各パーツをサーバーへAjaxで送り、各パーツについてすぐに(処理が成功か失敗の)結果を得ます。
結果はすぐにユーザーに通知されます。

例えばこのような表示です:
5商品アップロード成功
5商品アップロード失敗
5商品アップロード成功
5商品アップロード失敗
5商品アップロード成功
5商品アップロード成功
...

最終的にユーザーが失敗した商品をダウンロードできるようにして、再度アップロードできるようにします。

Aさん(日本人PM)からの返信

Plan b) sounds good.
It's also good that we don't have to fix PHP logic of uploading so much.

Would you start implementing in plan b? If you need, you can assign task to me, ○○-san or ○○-san.

方法b) は良さそうですね。
PHP側のアップロードロジックをそんなに修正しなくて済むというのもよいですね。

方法b)で実装を始めてもらえますか?
必要なら、私や○○さん、xxさんにタスクを割り振ってください。

Bさん(ベトナム人開発者)からの返信

Yes, A-san
I'll start implement. I'm preparing the environment

はい、Aさん
実装を開始します。環境の準備をしています。