Quantcast
Channel: もぎゃろぐ

[titanium] regionChangedの抑制

$
0
0

Titanium™ Advent Calendar 2013 - Adventar の7日目は、大さん橋を見ながら@mogyaがお送りします。

1466042_10152052877289243_273095704_n.jpg

山下公園でコード書くとかかっこよくない?と思ったんだけど、寒くてコードどころじゃない感じでした...

さてさて、TitaniumにはMapViewというのがあって、これを使うと簡単に地図アプリが作れるのですが、GoogleMapsSDKのバージョンが上がった関係で、現在Androidでは標準のMapViewではなくてModules.Mapを使うように言われていて、ちょっと混乱期にあります。3.2.0で旧バージョンが削除されるらしいので、来年には落ち着くんじゃないかと思うのですけど。現行だと、こんなかんじで書かないといけません。

map_view.js

さらにさらに、MapViewを使って、地図をドラッグした時に発生するregionChangedイベント(これも最近名前がregionchangedイベントに変わりましたw)を契機としてモバイラーズオアシスAPIを呼び出すようにすれば、電源が使えるお店を一覧するアプリを作ることが出来ます。

実際作ってみるとわかるのですが、このつくりだと微妙に使い勝手の悪いアプリになります。ちょっと離れた位置を見ようとして移動を繰り返すと、画面がちょっと動くたびにデータをロードしに行くので、処理がたまってだんだん重くなってしまうのです。

ブラウザ上のGoogleMapsSDKで開発する場合には、処理が落ち着いた時に呼び出してくれるidleイベントというのが存在するので、これを使えば綺麗に実装することが出来ます。

[GoogleMapsAPI] APIと組み合わせる時のイベントはidleを使う - もぎゃろぐ

で、idleイベントが存在しないAndroidやiOSのSDKでどうするか、というのがこの記事のテーマです(前置き長すぎだろうw)

idleイベントと近そうなイベントとして、completeイベントというのがあって、これを使うのも一つのアイデアです。ただこのイベントは、地図のロードが完全に終わってから呼び出されるので、これで実装すると、「ユーザーがドラッグ→地図がロードされる→(一呼吸)→店舗が表示される」という、これまた使い勝手の微妙なアプリになります。スポット数が少なかったり、通信環境が安定していてAPIが高速に応答してくれていれば、余りばれないのですけど・・・

今年リリースした電源検索新バージョンや、iPhone版の電源検索では、regionChangedイベントでそのままAPIを呼び出さずに、キューにイベント情報を積んでおいて、一定時間regionChangedイベントが発生しなくなったら、最後の一回分だけAPIを呼び出す、という実装を行いました。

data_task.js

data_task.js部分が問題のロジックをカプセル化したものです。
regionChangeイベントが発生したらとりあえず全部requestでDataTaskにあずけてしまいます。

	mapview.addEventListener(regionchanged,function(evt){
		datatask.request(evt);
	});

DataTaskは内部でタイマーを持っていて、一定時間が経つと、最後に呼び出したrequestの引数を使って、actionコールバックを呼び出します。

actionコールバックの中でAPI呼び出しを行うようにすれば、おおむね、ユーザーが地図をドラッグしおわったタイミングでAPI呼び出しを行うことが出来ます。

var taskAction = function(self,evt){
		Titanium.API.info('taskAction '+evt.longitude+','+evt.latitude);
	};
	var DataTask = require('data_task');
	var datatask = new DataTask({
		interval:3000,
		action:taskAction,
		caller:this			
	}); 
	datatask.start();

Dalvik_Debug_Monitor.png

書きながら「そこまで頑張る必要があったんだろうか。実はcompleteイベントでいいんだったりして」とちょっと不安になってきたのですけど・・・大丈夫なはずだ。神は細部に宿る!

明日はryugooさん@ChatWorkです。よろしくお願いしますー。


sauceLabsをつかってブラウザテストを自動化する

$
0
0
SauceLabs2.jpg

Sauce Labsというサービスがあって、WindowsやMac、iOSやAndroid等の各種OS上の各種ブラウザを仮想マシン上に立ち上げて、ブラウザ上でブラウザを操作することができるサービスです。
当初これがあればWindowsマシンを持ち歩かなくてもIE6のテストが出来るね!くらいの認識だったのですけど、説明を見ていると、どうやらSelenium WebDriver経由でユニットテストを実施することが本来の用途らしいので、コードをコミットしたら各種ブラウザでテストを実施してダメだったら教えてくれる環境というのを構築してみました。
selenium webdriverが登場した頃から、理屈の上ではできると言われていたテストですけど、あれこれの環境を個人で維持するのは現実的でないので、こういうのをサービスとして提供してくれるのは嬉しいですよね。

たとえばこういう、Google.comに行って検索した結果のページを表示するテストを実施するコードを用意して...

capsのところはSauce Labs: Supported Device, OS, and Browser Platformsからコピペすることが出来て、必要な設定に書き換えればMacのChromeでもWindowsXPのIE6でも、iOS7でもAndroidでも、任意のブラウザで同じテストを実施することが出来ます。

ということで、環境変数BROWSERでブラウザの種類を指定してunittestができる仕組みを作ってみました。

#Special thanks to Ruby-ML

通常の Test::Unit::TestCaseの代わりに SaucelabsTestCasePCを継承してテストを作れば、環境変数BROWSERで指定したブラウザでテストを実施することができるようになります。

	$ env BROWSER=mac_chrome ruby pc/search.rb
	Loaded suite pc/search
	Started
	.
	Finished in 23.795709 seconds.
	
	1 tests, 1 assertions, 0 failures, 0 errors, 0 skips
	
	Test run options: --seed 21266
	$ env BROWSER=win_ie6 ruby pc/search.rb
	:

テスト結果はunittestとして成功失敗を判定する以外にも、Saucelabs上ではこのようにキャプチャ画像や動画として保存されているものを見ることも出来ます。

SauceLabs7.jpg SauceLabs6.jpg

ここまでできれば、あとはいつもどおりにunittestを書いてjenkinsさんにお願いしておけば、コードをコミットするだけで各種ブラウザの動作確認をしてくれるようになりますね。すばらしい。

ちなみにSauce Labsは月額課金のサービスで、月一時間位までは無料で使うことが出来ます。
1テスト30sくらいで実行できるので、全部のテストを一度通してみるくらいなら無料でも行けるけれど、本当にコミットするたびに全テスト走らせるのであれば、$12のManual会員か、$49のAutomated会員くらいは必要になるかもしれないですね。
今これを書きながら気づいたのですけど、githubに公開してあるコードは無料でテストできるらしいです。Sauce Labs: OSS

swap領域の把握にはsar -Sを使う

$
0
0
「sar -r」でメモリと一緒に把握するように書いている記事が多いけど、それはsysstat7までの話で、sysstat8からはスワップメモリについて出力する"sar -S"というmetricsが追加されている。近年のlinuxマシンだったら、ほとんどは"sar -S"を使うことになるはず。
$ sar -r
Linux 3.12.9-x86-linode56 (linode6.mogya.com) 02/16/14 _i686_ (8 CPU)

00:00:02 kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit
00:10:01 28284 998736 97.25 90452 435064 582540 45.19
00:20:01 27424 999596 97.33 90720 435080 582388 45.18
00:30:01 25792 1001228 97.49 90920 435264 584120 45.31
00:40:01 60456 966564 94.11 93360 400776 582312 45.17
00:50:01 60024 966996 94.16 93560 400812 582492 45.18
$ sar -S
Linux 3.12.9-x86-linode56 (linode6.mogya.com) 02/16/14 _i686_ (8 CPU)

00:00:02 kbswpfree kbswpused %swpused kbswpcad %swpcad
00:10:01 254208 7932 3.03 2496 31.47
00:20:01 254208 7932 3.03 2496 31.47
00:30:01 254208 7932 3.03 2496 31.47
00:40:01 253928 8212 3.13 2492 30.35
00:50:01 253928 8212 3.13 2492 30.35
SYSSTAT Features
man SYSSTAT

respond.jsが効かないもうひとつの理由

$
0
0
modern.ieでIE8の動作確認していて、昨日まで動いていたはずのデザインが突如崩壊した!リリース直前なのに!respond.jsが効いてない!?なんで? コードを戻してみたり、「respond.js 効かない」でググってみても直らない。迫るリリース時刻!電車の動き出す音! って時は、そのVirtualMachineが外部ネットワークに接続できるかどうか確認することをおすすめします。CDN上のrespond.jsはネットワークにつながってないと当然動きません。 ホストマシンのrailsでテストしていると意外と気づかないので、パニックになった時は一度ご確認を。 ・・・あー。びっくりした。

RubyHiroba2014のLTについて

$
0
0

RubyHirobaのLTについていくつかお話できることを。

結果的につまらないプレゼンで時間をとってしまって、さらに運営に余計な対応をさせるはめになってしまったことはホント申し訳ないと思っております。

今回話題が公になったので、引き続き議論していただくための参考資料として、僕の側から見て何が起きていたのかを説明させていただきます。

前日まで

 RubyMLのメールでLT募集のことを知りました。

[ruby-list:49953] 9/21(日) RubyHiroba2014の参加受付中です

 これは面白いんじゃないかな、と思って、今回のようなLTをやろうと思っている旨を当人に相談した所、OKが出たので、LTthon | RubyHiroba 2014を見て、応募フォームからタイトル書いて申し込みました。この時、アンチハラスメントポリシーにはぜんぜん気付かなかったです。わりとギリギリの話題をやろうとしている自覚はあったので、気づいていたら止めてたと思います。

 LT申し込みフォームにタイトル記入欄があったから、内容が明快にわかるように「社長が美人で何がわるい」というタイトルで申し込みました。ダメならここで止めてくれるだろうと思ってました。
 結果的には、工数がないからノーチェックで通ってしまったのだそうです。ボランティアだからそうなることは仕方ないと思うのですけど、この時点でそんな可能性はまったく思いつかなくて、当日の案内メールが来たことで「あ、OKなんだな」と理解してしまいました。

当日

 一人目の人が欠席で、結果的にぼくがトップで発表することになりました。

 発表が*終わってから* 「ところでRubyHirobaにはアンチハラスメントポリシーというのがあります」といわれて、ドキっと思わなくもなかったのですが、その後「PHPをDisったりするのは禁止です」というから、「あ、これは場を盛り上げるためにぼくのネタを引き継いで冗談を言っているのだな」と理解しました。

 その後も、Tシャツ取りに行った時とか、「ここで食事しても大丈夫ですか?」ってスタッフの方に確認に行った時とか、どこかのタイミングで直接言っていただけたら、記事の公開を見合わせるとかもありえたのですけど、上述の通り冗談をいわれていると思っていたので、ぎりぎりオッケイなおもしろいプレゼンをしたつもりでいました。

 時間があればもう一個枠をいただいてRails+GoogleAnalysticsの話もやろうと思っていたのですけど、前日から体調不良気味だったし、午後になって枠がいっぱいになっていたので、無理せず帰宅しました。ひょっとしたら運営の方は、終わってからお話をしたかったのかもしれないですね。

月曜日

 土曜日のRuby関西同窓会で、LTと同様の話をしてスカウトした方がオフィスに来てくれたので、僕としては成功したつもりになってました。
そこで、資料に出ている当人にプレゼンを見せて、「公開してもいい?」と聞いたところ、「いいよ」とのことだったので、ノリノリで資料も公開しました。

半日後くらいにRubyHiroba運営の方からメールを頂いて、ここで初めて事態を悟りました。
指示に従って資料は非公開にして、連絡を待っていたのですが、今日になって、「RubyHirobaの アンチハラスメントポリシーに明確に抵触するものではない、という結論になりました」というメールを頂きました。WEBサイトで「残念ながら、ジェンダーや性的な表現について、アンチハラスメントポリシーに抵触する発表がありました」と書かれていることとの整合性については、僕にはよくわからないです。

LTthonで行っていただいたプレゼンですが、運営で協議したところ、RubyHirobaの アンチハラスメントポリシーに明確に抵触するものではない、という結論になりました。 曖昧な言い方で大変申し訳ないのですが、「あのようなポリシーを掲げているイベント での発表としてはあまり好ましくない。しかし、どこがダメで誰に対してのハラスメント であるかを明確にすることが難しい」という判断です。

ただ、ポリシーに抵触するのかしないのかはさして重要ではなくて、くだらないLTのために運営に余計な手間を取らせてしまったことはほんと申し訳ないし、調子のってたなーと思っております。以後気をつけます。

管理画面チラ見せナイト#2 をガン見してきた

$
0
0

管理画面チラ見せ♡ナイト#2 (#admin_night)見て思ったこと。「管理画面にも銀の弾丸はない」

個別の話も面白かったんだけど、それよりも、会場で質問している人と、登壇して自分の作った管理画面を説明している人の対照が面白いなーと思った。
僕もそうなんだけど、「うまくいかないんです」と質問している人たちはたいてい、本業とのリソース配分に悩んでいて、「どのくらいのリソース配分でやったんですか?」「何日くらいで作ったんですか?」と聞いていた。
それに対する回答は「マネージャさんの要求に答えて作っていたスクリプトが管理画面になりました」「本業の合間に楽しいから作ってました」というものばっかりで、具体的に工数確保した人がぜんぜんいなかった。
あと当然だけど、「これを使ったら一瞬で管理画面ができたんですハッピー!」みたいな話もなかった。

ベンチャー企業にリソースが足りないのは当たり前の話なので、そこで工数確保とか考え始めるとなんにも動かなくなってしまう。
エンジニア一人で開発からメンテナンスサポートまでやっている状態で管理画面を作るのと、サーバエンジニアが副業で作るのでは後者のほうがちょっとリッチかもしれないけれど、まあその程度の差で、ダブダブにお金があまってるから管理画面にデザイナとエンジニアを貼り付けられるような会社なんて存在しない。

その中でどうするかといえば、本業の開発と一緒で、やることが多すぎる状況の中でほんとに必要なのはどれか見極めるとか、エンジニアが楽しいから勝手にやっちゃうとか、そんな解決方法しかないんだと思う。

その他のメモ

  • おだんみつさんは @masuidriveに這いよる謎人だと思っていたけど、21cafeの頼りになるお姉さんだと見解を改めた
  • 「管理画面のデザインの良さはオペレーターのやる気に繋がる」
  • 「本業よりもクイックに喜びの声が上がるのでむしろやる気が出る」
  • 「画面横幅は貴重なリソースなのでムダにしない」
  • datadog 管理画面的にいろんな情報を集約してくれるサービス

スタートアップツールをチラ見せしてきた

$
0
0

スタートアップツールチラ見せ♡ナイトというイベントでAnytimesのツール導入状況についてお話してきました。

  • 社内でLINEが実用的に使われているところが笑わせどころのつもりだったのですが、案外みんな使っていることが判明して、LINEすげーと思いました。
  • 新しいツールを導入する時は、ゆるさが一つのポイントになる。
    • slackだったら高橋くんみたいなおもしろロボットをいれておくとか。
      トレタでの「slack」活用を紹介してみる - @hitoshi annex on hatena
    • Anytimesの場合は、そこまで手はかけ(られ)なかったのですけど、デザイナさんがslackbotのカスタマイズ(だれかが「いいね」と言ったら「いいねいいね!」と返すとか)で遊びはじめたのが良いきっかけになりました
    • slackでbotを導入する時はアイコンが命。男性の多い会社だったらアイドルとかアニメとか、そうでなかったら会長とか社内の有名人とか、そんなのを使って親しみやすさを作る。

sssslideをモバイルで使う

$
0
0
(2015-01-13 追記) sssslide側で対応していただけたので、ここで紹介したスクリプトを使わずとも、本家に掲載されているブックマークレットがそのままスマホでも動作するようになりました! (追記終わり)

SSSSLIDEというサイトがあって、SlideShareSpeaker Deckにアップロードされているスライドを、縦に並べてみることができる。

実はPCだとそんなに必要性を感じないのだけれど、スマホで使うととても便利。

Screenshot_2015-01-12-22-09-02.png

slideshareのスマホViewは、横にスライドして読むようになってんだけど、普段左手でスマホ持っていると、この動作はちょっとやりづらい。縦にスライドするほうが楽だし、全部表示されていたほうが断然早く読めるよね。


WEBページの内容を一時的に書き換えるテクニック

$
0
0

この記事は、以前書いた「不要なところは削除してやりたい放題できる『編集』 - もぎゃろぐ」の再掲です。需要はあると思うのになぜか広まらないのでもう一回書いてみる!

WEBサイトをキャプチャするとき、微妙に都合の悪い要素を削りたい時ってあるじゃないですか。広告とか、ユーザーさんのお名前を伏せ字にするとか。普通そういう処理は画像編集ソフトでやるのですけど、めんどくさいじゃないですか。動画とかそう簡単じゃないし。
そういう時、ブラウザで見ているページの中身を一時的に書き換えることができます。

編集

このリンクを右クリックして「お気に入りに追加」します。
alert.JPG

こういう警告が出ます。警告の内容は書いてある通りなので、信用できる方だけ「はい」を押してください。


先ほどのように、編集したいページに行ったら、そこでお気に入りから「編集」を選ぶと、WEBページにカーソルが出てきます。
Cursor_and_仕事管理___Any_Times・エニタイムズ.png
任意の箇所を変更することが出来ます。
Cursor_and_仕事管理___Any_Times・エニタイムズ 2.png
余計なところを削除したりできるのが、撮影の時に嬉しいです。
仕事管理___Any_Times・エニタイムズ 2.png
撮影に邪魔なカーソルは、どこか画面に映らない場所に移動させておきます。
あと、書き換えた画面は、もう一度ページを読み込み直すと元に戻ります。

GoogleグループでDocsの権限を管理する

$
0
0

今や会社でもドキュメントをGoogle Docsで作成してメンバー間で共有することは珍しくないと思うのですけど、これをやると、メンバー管理問題が発生します。
「もぎゃさーん、Aのドキュメント見えないので権限追加してください」「はいはい」
「Bさんが、ホゲホゲのドキュメントに対する編集権限をリクエストしています」
「ぼく総務部じゃないんだけど!」


ダイナミックに人が増えたり減ったりする組織になると、ドキュメント一個一個に対して共有なんてしてられないのですよね。

一般にこういう問題に対してはGoogle Apps For Workを使うことが勧められているのですけど、これだと自社ドメインのメールアドレスを持った人しか管理できないのですよね。

で、Googleグループ。実はGoogle DocsにはGoogleグループを指定して共有する機能があります。

tmp_txt_-_Google_ドキュメント_15_33_45.png

こうしておくと、Googleグループに参加している人に対してまとめて権限を付与できるようになるので、新しいメンバーが参加した時も、誰かいなくなった時も、Googleグループのメンバー管理機能を使って管理することが出来るようになります。
自社ドメインじゃないgmail.comのユーザーも追加できるし、いまやGoogleアカウントはgmail以外でも使うことができるので、実質的にどんなメールアドレスでも管理することができるのがメリットですね。

Google_グループ.png

メイドめーる終了のお知らせ

$
0
0

2008年の公開以来、沢山の皆様に使っていただいた「メイドめーる」ですが、サービスを終了させることにしました。

直接的な要因としては、GoogleカレンダーのAPIが更新されて、コードをバージョンアップしないと正常に動作しなくなっていたことです。このまま放置して意味不明なメールを送信し続けるよりは停止させたほうがいいと判断しました。

サービス終了の時、「社会環境が変化して役割を終えた」というのがよくありますが、メイドめーるに関しても同じことが言えます。
メイドめーるを開発した2008年は、iPhone3Gの発売直後、まだAndroidは存在すら怪しい時代でした。iPhoneでGoogleカレンダーを見るためには「同期」が必要で、Googleカレンダーと同期させる方法がブログネタとしてアクセス数を集めるような時代だったのです。

時は過ぎて、GoogleがAndroidOSを発表し、Googleのサービスはスマートフォンからアクセスできることが当たり前になりました。Google Nowでは、その日の予定をお知らせするのはもちろん、現地までの所要時間を計算して、「もうそろそろ出ないと遅刻しますよ」と通知までしてくれるようになりました。僕自身、GoogleNowのほうが便利なので、メイドめーるについては使わなくなってしまってずいぶん時間がたってしまっています。

まだガラケーのユーザーが残っているじゃないか、iPhoneのGoogleNowはそんなに便利じゃないぞ、というような状況は知っておりますし、メイドさんが好きだったのに、というユーザーさんがいてくださることはありがたいことなのですが、そもそもGoogleカレンダーを便利に使うためのサービスである以上、Googleと競争をするというのも馬鹿げた話ですから、これ以上の改善については、Googleにお任せするのが良いかと考えました。

お預かりしていたデータについて

メールアドレスやアクセストークンについては、責任をもって破棄させていただきます。
メイドめーるのサービスについては、ドメインを引き継いで運営したいという会社さんがおられるため、ひょっとしたら今後、運営会社が変更になってサービスが再開する可能性がないとは限らないのですが、その際にも、新たな会社さんにユーザーデータを勝手に譲渡したりすることはありません。

ソースコード

githubで公開しました。相当古い環境だし、テストも書かれていないのでこれをそのまま動かすことは困難だと思いますが、何かの参考になるかということで公開しておきます。

mogya/maidmail

オオカミ少年から学ぶメディアとの付き合い方

$
0
0

イソップ童話の「オオカミ少年」は、嘘をついた少年が狼に食われるという結末が有名ですが、もともとそんな結末はなくて、「村の羊はすっかり食べられてしまったとさ」というのが結末だったんだそうです。

日本ではイソップの話であるとして、狼に食べられるのは羊ではなく「羊飼いの少年」とする寓話がいくつも存在する。
(嘘をつく子供 - Wikipedia)

誰かが作り替えた話が、「そっちのほうがわかりやすいから」ということでどんどん広まっていって元の話を駆逐してしまう展開は、パクツイとかバイラルメディアでよく見られる現象ですね。

ところで、「村の羊はすっかり食べられてしまったとさ」という結論が元だとすると、これってどういう教訓だったんだろう、というのがfacebookで話題になりました。

食べられたのが少年じゃなくて村の羊ということは、村の人々の行動に問題があったということになります。ウソだかホントだかわからない話を鵜呑みにして、いきなり全員で武器を持って大騒ぎしちゃったことが問題なんじゃないでしょうか。
村人は、少年の話をきいた時点で、とりあえず武器を持った人を索敵に出して、他の人は冷静に待機しておくべきだったのです。
そういう対応なら、嘘だと判明しても「コラ!」って叱れば済む程度の話だっただろうし、対応コストが低いから、二回目以降も同じ行動を取り続けることが出来て、本当に狼が来た時には全力で事にあたることが出来たはずです。

センセーショナルな情報を見たからといって、真偽を確かめずに大騒ぎしてはいけない。

最近はバイラルメディアとかの流行りで、「わー!」「大変!」と言いたくなるようなタイトルの付いた記事があふれています。いちいちまともに受け取って騒いでいたら、体も心も疲れてしまいますよね。
本当に「これは大変だ」と思うのなら自分で真偽を確かめてから話題にすべきだし、そうでないのなら「ふーん」と言いながら判断を保留するくらいの態度がいいんじゃないでしょうか。オオカミ少年の話題を聞いてそんなことを思いました。

帰属意識が薄れない客先常駐の話

$
0
0

客先常駐という働き方はもうやめにできないか、っていう話が盛り上がっています。

実際自分が体験して、また仲間を現場に送りこむ立場になって思うのは、この働き方は働き手にあまりに負荷をかけるのではないかということです。
IT業界で客先常駐という働き方はもうやめにできないか - あいむあらいぶ

どういう問題があるのかについては、記事に書かれているとおりだと思いますので、元記事を読んでいただければと思います。

そういう問題が起きがちであることは認めつつも、それを解決することにほぼ成功していた会社で働いた経験があるので、この記事では、どういう対策が行われていたかを書いてみようと思います。

ずっと一緒にいる生活について

$
0
0

妻・夫を愛してるITエンジニア Advent Calendar 2016 - Adventar の8日目です。

自己紹介

フリーランスのWEBエンジニアです。街の電源検索サイトモバイラーズオアシスの運営をしたり、それに続くサービスの開発をしたりしています。
あと今年は、映画SNSのFilmarks(フィルマークス)のリニューアルをお手伝いさせていただきました。

あたたかくてやわらかいおくさま(愚妻じゃなくておくさまです!)と、かわいいインコの二人一羽で暮らしています。

自宅で仕事をする生活

ぼくは基本的に家で仕事をするスタイルで、打ち合わせとかのときだけ取引先にお伺いしたり、喫茶店で打ち合わせたらとっとと家に帰ってきます。今年の後半は、例外的にサラリーマンぽい通勤するスタイルの仕事をしてみたのですけど、やっぱり無理があることがわかったので、年明けから再び前のスタイルに戻ります。

おくさまも、フリーランスの翻訳者なので、やっぱり自宅で仕事をします。通訳じゃなくて翻訳なので、翻訳会社から電話で仕事を受注したらメールで原稿をやり取りするだけ、打ち合わせすらないので、ぼく以上に自宅を出る必要のない仕事です。

そういうわけで、ほぼ24時間、同じ家で暮らしていることになります。エンジニアとデザイナの夫婦とか、翻訳者夫妻というパターンはたまに聞きますが、それぞれ別々の仕事をしている二人というのはあまりないパターンみたいなので、どんな感じなのかご紹介します。

ふたりとも家で仕事をするので、自宅にはそれぞれの仕事部屋が確保されています。二人暮らしにしてはかなり広い家になってしまうのですが、ここは必要経費ですね(実際、仕事部屋のぶんは経費に計上しています)

仕事

朝昼おやつ晩ごはんの時間が決めてあって、これ以外の時間は、だいたい部屋で仕事をしています。
ぼくの場合は、仕事でコードを書いていても、そうでないコードを書いていてもはたから見たらなにも区別がつかないので、だいたいずっとパソコンに向かっている感じです。
おくさまは、翻訳会社からの受注があれば猛然と仕事をして、そうでないときはのんびり本を読んでいることが多いようです。

どっちにせよ、部屋に閉じこもって仕事しているときは不必要に声をかけない代わりに、3時間おきくらいに部屋から出てくるので、買い物とか用事があればこのタイミングで相談する感じです。
ちなみに、自宅で仕事をすると食事の時間を守れずに後ろにズルズルと仕事をし続けてしまうという話はよく聞くのですが、うちの場合、時間どおりにカゴから出してあげないと大騒ぎするタイムキーパーがいるので、時間がずれることはめったにありませんw

1481030324987.jpg

家事

そういうわけでふたりとも家にいるし、子供がいないので、家事については分担する必要性が薄く、得意な方をやればいいじゃないという感じです。
例えば普段の食事はおくさまが作っています。別に僕が作れないわけではないのですけど、食材の在庫を覚えておいたり、食材の使い回しを考えたりする都合を考えると、台所は一人が把握したほうが効率的なのでおくさまにお願いしています。そのほうがおいしいし。

一方掃除はほぼぼくがやっています。おくさまはわりと物が散らかっていても気にならない性格で、ぼくは気になる性格なので、ぼくが勝手にやる感じです。
ぼくが得意じゃないお風呂洗いがデッドポジションになりがちなのですが、手の空いている方がやることでどうにかバランスを維持しています。
今年サラリーマン的な働き方をしてみたら負担が一気に奥さまに偏ってしまって、大変申し訳ない感じになってしまいました。

買い物については、原則二人で行くことにしています。
女性にとって、一日の中におしゃべりの時間が決まって確保してあることは大事なのだそうで、買い物の時間がこれにあたる感じです。

(おしゃべりの時間については、奥さまと妹が非同期に同じことを言っていたので、たぶん女性の方はこれ思う方がたくさんいます。新婚男性の方、ちょっと意識しておくとポイントアップですよ!)

おわりに

ホントはこの記事、「Googleカレンダーの通知機能を使うと、お互いがカレンダーに予定を書いただけで勝手に通知されて便利だよ」という内容を書こうとおもっていたのですが、みなさまののろけ具合を見ていると対抗しないといけない気がしてきたので、内容を変更してお送りしました。

Googleカレンダーの通知機能、日本語が変であることをのぞけば良い機能なので、「サプライズでケーキを買って帰ったら奥さんはその日飲み会で不在」みたいな悲しい目にあったことのある人はぜひ使ってみるといいですよ!

mail.png

slackの四文字アイコンを作るジェネレーターを作ったよ

$
0
0
去年後半は[つみき](http://tsumikiinc.com/)さんの映画SNS[Filmarks(フィルマークス)](https://filmarks.com/)のリニューアル開発に参加していました。 チームで開発すると、いろいろ新しい気付きがありますよね。nginxはぬぎっくすと読まないこととか。 一人だとなかなか使いにくいslackを久しぶりに使って、リアクションが楽しいなーと思いました。 random___mogya_Slack.png slackのreactionというと、[slack-reaction-decomoji](https://github.com/oti/slack-reaction-decomoji/blob/master/README_ja.md)が有名です。これ使えばほとんどの笑いは取れるのですが、やっぱり追加で欲しくなるじゃないですか。「できたよ」とか「ゴチです」とか。 でも、そのたびにAdobeツールを立ち上げるのは面倒すぎるので、四文字タイプするだけでアイコンを作れるツールを作りました。 [よんもじ](https://mogya.github.io/yonmoji/?text=%E3%82%88%E3%82%93%E3%82%82%E3%81%98&font=sans-serif&color=%231111dd) よんもじ.png 一目瞭然。四文字入れたらアイコンができます。たいていのブラウザでは、生成された画像をそのまま右クリックでpngとして保存できるはず。 入力されたパラメタはリアルタイムにURLに反映されているので、URLをコピペすればTwitter等で共有することもできます。 お楽しみいただけたら幸いです。





Latest Images