チームでのやりとりはSlackですが、仕事の依頼とか外部との仕事関係でのやりとりってFacebook Messengerが多いです。多くないですか？
しかしFacebook Messengerってちょくちょくチェックするにはとても不便で、何故かというとチェックするたびにFacebookのTimelineが目に入って、
「この動画おもしろいな。知り合いにURLを送って置こう。・・・そういえば俺は何をしてたんだっけ？」
となることが頻繁にあるからです。
なのでMacでFacebook Messenger専用のクライアントを色々探してたんですがgoofyが自分の中で決定版で文句無しです。
$ brew cask install goofy
見た目もかわいいし、複数人チャットできるし、無料だし。
あと秋元さんがPHPプログラマー探してるそうなのでご存知の方はぜひ。（ついで感）
追記：
https://www.messenger.com がまさかのスピンオフしたのでブラウザでこのサイトを見るのが一番ですね。
「おい、Nexus6あくしろよ。」
しょっちゅうチェックしてると仕事に影響が出るので書いた。
hurry_up_nexus6/clock.rb at master · komagata/hurry_up_nexus6:
require 'open-uri'
require 'mail'
require 'css_selector'
require 'clockwork'
include Clockwork
NEXUS6_URL = 'https://play.google.com/store/devices/details/Nexus_6_64_GB_%E3%82%AF%E3%83%A9%E3%82%A6%E3%83%89_%E3%83%9B%E3%83%AF%E3%82%A4%E3%83%88?id=nexus_6_white_64gb&hl=ja'
Mail.defaults do
delivery_method :smtp, {
address: 'smtp.sendgrid.net',
port: '587',
domain: 'heroku.com',
user_name: ENV['SENDGRID_USERNAME'],
password: ENV['SENDGRID_PASSWORD'],
authentication: :plain,
enable_starttls_auto: true
}
end
handler do |job, time|
html = open(NEXUS6_URL) { |f| f.read }
status = CssSelector.new.parse(html, '.shipping-status').strip
if status != '現在在庫切れです。しばらくしてからもう一度ご確認ください。'
Mail.deliver do
from 'komagata@gmail.com'
to ENV['MAIL_SEND_TO']
subject 'Nexus6 is now available!'
body "Go fast! #{NEXUS6_URL}"
end
else
puts 'Not available...'
end
end
every(1.minute, 'check_nexus6')「FRINGE／フリンジ」の J.J. エイブラムスと「ダークナイト」の脚本家ジョナサン･ノーランが贈るわけではない、IT業界のタブーに切り込んだサスペンス実話。
（私本人は真剣にレガシーPHPに取り組んでおります。）
レガシーPHP改善・コンサルティングはこちらから承っております。お気軽にどうぞ。
レガシーPHP診断を作りました。
回答結果はこちらで見られます。
基本的に選択肢の上の方がよりおすすめという感じです。まずは自社の環境がどのような状態か把握するチェックリストとして使っていただければいいかなと思いました。
改善に関してはPHP: The Right Wayが参考になると思います。
デデドン！
「Adobeのバカ！（Case sensitiveなファイルシステムを恐れるなんて）いくじなし！」
PDFの編集、文字とかだったらPreviewで行けるんですが、画像を追加とかできないですよね。何か良いソフトありますかねぇ？
初日、行ってまいりました。
流行りの環境うんぬんは単なる手段であり、"経営陣を含めたマインドセットの更新が大事"ってのはありますが、そんな話みんな読みたくないでしょ？
僕が調べた現状と、こういう風に持って行きたいという理想の環境を書き出してみました。
@komagata 記事を読ませていただきました! コーディングスタイルの規約はPSR-4ではなく、PSR-2 http://t.co/yM2wqwmtji かと(4はオートローダーのための名前空間のための規約)
— tanasinnな∴(･)∴∴(･)∴ (@tadsan) 2015, 2月 12正直レガシーPHPの現場というと、"鳴り止まぬクレーム電話"、"デスマ続きで死んだ目をしたプログラマの群れ"などをイメージしてたんですが、現行のシステムでちゃんと商売が回って売上が上がっているし、現状を良くしていきたいというポジティブな雰囲気があったのでそれだけで行ける気がしました。
現行のツール類や開発フローに関しては、皆さんも思ったかもしれませんが、"懐かしい"の一語に付きます。昔は僕らだってみんなこうだったんだよ！
これはレガシーPHP（Legacy PHP）というより古き良きPHP（The good old PHP）と呼びたい感じ。
こうやってカテゴリ分けしてみると昔と今で同じ方向ですべてのツールが進んでるように感じます。
昔（って言い切るのはひどいですが）は社内で閉じていて外からは使えません。今のツール群はオープンでどこからでもスマホなどいろんなデバイスで使える傾向にあります。
また、昔のツールは１人または少人数で同期的に使うように出来ていますが、今のツールは多人数・非同期で作業することが前提となっています。
要は「場所・人数・時間」を選ばないように進化してきてるってことですかね。
理想に近づけるのにまずやる必要があるのが、みんながひとつの開発環境を使っている現状から個別のローカルで開発してコミットするというフローに変更するところ。
たくさんのサイトが社内の共通開発環境で動いてるのですが、デザイナーも含めてWindowsでローカル開発に変えるには今だとどうするのが一番いいんでしょうか？
XAMPP？Vagrant？Docker？どっかのサーバーに全員分の環境を作る？
もしおすすめがあったら教えていただけるとありがたいです。
レガシーPHPを改善する一連のフローを毎回苦労して行うのは無駄ですよね。レガシーPHPを改善したいと思っている会社さんはたくさんあると思うし、それができる小さい会社やフリーランスのプログラマーもたくさんいると思いますし、求人・お仕事のマッチングもたくさん生まれるのではないかと思います。（前回ご一緒させていただいた @kaz_29さんや@kjirouなど僕が出会えてる人はその本当一部なので）
そこで、上手くいきそうだったらレガシーPHP改善のノウハウを共有するイベントや実際に改善していく集団・コミュニティーが出来たらいいなとおもいます。
レガシー坂は終わっていなかった。
３年前のレガシーPHP改善日記を見てレガシーPHPと開発フローの改善したいとのご依頼があったので再びレガシーPHPと格闘することになりました。
今回は皆さんWindowsをお使いとのこと。そこに若干の不安。どうなることやら・・・。
Mac版Office 2011は読み取り専用で使うなら無料なんですね。homebrewから入れられるのが嬉しい。
$ brew cask install microsoft-office
"Use Office to view your files for free"を選べばOK。
他社から複雑なレイアウトのExcelとか送られてきた時に。（←腹立つ）
brew doectorして知ったんですが、Mac OS Xデフォってcase-insensitiveだったんですね・・・。どうもAdobeとかSteamのゲームとかインストール時に文句言われるなあとかおもってたんですが・・・。
formatするときにcase-sensitiveにするかcase-insensitiveにするか聞かれたら前者選んじゃうのが人情ってもんじゃないですかあ。
% brew doctor
Please note that these warnings are just used to help the Homebrew maintainers
with debugging if you file an issue. If everything you use Homebrew for is
working fine: please don't worry and just ignore them. Thanks!
Warning: The filesystem on / appears to be case-sensitive.
The default OS X filesystem is case-insensitive. Please report any apparent problems.じゃけん再クリーンインストールしましょうねぇ〜・・・
例えばコメント投稿のテスト。
# test/integration/post_comment_to_comic_test.rb:
require 'test_helper'
class PostCommentToComicTest < ActionDispatch::IntegrationTest
test 'Post a comment' do
visit comic_path comics(:comic)
within('#new_comment') do
fill_in 'comment[body]', with: 'コメントのテスト'
end
click_button '規約に同意してコメントする'
assert has_selector? '.content-comment__body-text',
text: 'コメントのテスト'
end
endよくあるこういうのを実行したら下記のエラーが。
% ruby -Itest test/integration/post_comment_to_comic_test.rb -n PostCommentToComicTest#test_Post_a_comment
Run options: -n PostCommentToComicTest#test_Post_a_comment --seed 29141
# Running:
E
Finished in 5.497046s, 0.1819 runs/s, 0.0000 assertions/s.
1) Error:
PostCommentToComicTest#test_Post_a_comment:
Capybara::Webkit::ClickFailed: Failed to click element /html/body/div[@id='content']/div[@id='comments']/div/div[1]/form[@id='new_comment']/div[@id='comment_action']/input because of overlapping element /html/body/div[@id='content']/nav/div/ul/li[2]/a/span at position 831, 1025;
A screenshot of the page at the time of the failure has been written to /var/folders/nb/5jp6psyd7h19my68chb0svvh0000gn/T/click_failed_W60479.png
test/integration/post_comment_to_comic_test.rb:23:in `block in '
1 runs, 0 assertions, 0 failures, 1 errors, 0 skips クリックできなかったElementのxpathを表示してくれる。そして何故クリックできなかったのか、overlapしているElementのpositionとxpathも表示してくれる。更にscreenshotここに撮っておいたからってどこまで至れり尽くせりだよ。
この場合、要はこんな感じになっててコメントボタンがクリックできない。
こんな方法でいいのかどうかわかりませんが、テスト前にexecute_scriptでoverlapしてるメニューをhideして対処。
# test/integration/post_comment_to_comic_test.rb:
require 'test_helper'
class PostCommentToComicTest < ActionDispatch::IntegrationTest
test 'Post a comment' do
visit comic_path comics(:comic)
execute_script("$('nav.other-pages-nav').hide()") # It's workaround.
within('#new_comment') do
fill_in 'comment[body]', with: 'コメントのテスト'
end
click_button '規約に同意してコメントする'
assert has_selector? '.content-comment__body-text',
text: 'コメントのテスト'
end
end更に背景と同色の文字問題とかもサポートしてくれたら手動QA不要とはいわないけどもっと自動テスト化できますね。