はてブでロードが終わらない現象をなんとかした
タイトルの通りなのだけど、最近 Chrome ではてなブックマークを閲覧するとロードが終わらないことがままあった。
作業自体にも影響が出てしまうので、何が原因か調べてみた。
Developer Tools の Network タブを見てみると、どうやら広告のトラッキング画像が延々と読み込まれないことが原因っぽい。
なので、Chrome の Cookie 設定よりブロックサイトの追加に問題のトラッキング画像のURLを追加したらある程度は改善した。
広告は出ていても全く気にしないのだけど、さすがにサイトが見れないのは辛かったので残念だけどブロックした。
個別で設定するのは嫌なので、折を見てブロックは外したい。
追記： 結局重いのが治らなかったので uBlock Origin を入れることに…うーむ
簡単にメモを取れる環境を作ってみる
簡単にメモを取るために使ってきたATOK Padが、MacOSをSierraにアップデートしたら全く入力を受けつけなくなってしまった。
実はATOK Padを使っていたときからいろいろ試して来たのだけど、これを気に一新してみることにした。
wri.peに登録する
今回はATOK Padの代わりにwri.peを使ってみることにしました。
サイトの説明にもある通り、シンプルな構成でショートカットキーも備えているのが良い。
GitHubアカウント（Facebookアカウントでも可）でSign inするだけなので楽ちん。
Fluidでアプリにする
次にFluidというアプリを使ってwri.peをアプリにする。
サイトからダウンロード・解凍したのちに、アプリケーションの下にでも移動させる。
で、Fluidのアプリを起動するとこんな感じのダイアログが出るので、URLに https://wri.pe/app を、Nameは wri.pe としてCreateする。
これでアプリケーションの下にwri.peのアプリができます。
アプリの設定を変更する
で、このままだとwri.peを起動してもログイン認証でブラウザに遷移してしまうのでちょっと変更。
wri.peを起動 → メニューにある Preference (⌘ + ,) → Whitelist から Allow browsing to any URL をチェックすればOK。
これで無事ログインできるはず。
うめのんさんのブログで書いてあったように、自分にとってwri.peが気持ちを乗せてくれるアプリに感じたので、これでいろいろ書いていきたいと思います。
おまけ
コピペでテキストを貼り付けた場合に、シングルクォートが勝手に変換されてしまうが、
システム環境設定 → キーボード → ユーザー辞書 → スマート引用符とスマートダッシュを使用
のチェックを外しておくと変換されなくなる。
なので気になる人はチェックを外しておくといいです。
NTTフレッツ光の初期設定をMacからWifiでする
表題ですが、ＮＴＴ東日本「フレッツ 光ネクスト」 でWifiの設定をしようとしたところ、簡単セットアップツールがWindowsしか対応していなかった＆MacBook Airしか手元になかったため、かなりハマってしまいました。
どうやって設定すれば良かったか共有として残しておこうと思います。
工事完了の確認
ＮＴＴ東日本の工事が完了し、ルータにSC-40NE2という無線LANカードアダプターが刺さった状態となっているか確認してください。
無線LANカードアダプターにあるACTとPWRのランプが点いていればOKです。
契約書の確認
ＮＴＴ東日本と契約をした際、プロバイダ（niftyとかのことです）とも契約をしていたと思いますが、そのプロバイダから封筒が届いていると思います。
まずはそれが手元にちゃんとあるか確認してください。
Wifi接続の設定
Macの場合、「システム環境設定」→「ネットワーク」よりWifi接続の設定ができます。
Wifiを選択すると「ネットワーク名」を選択できるので、そこからルータのラベルにある「SSID-1」を選んでください。
するとパスワードを聞かれるので、ルータのラベルにある「暗号化キー1」の内容を入力してください。
これでWifiの設定は終了です。
ブラウザから http://flets-east.jp/ のページにアクセスすると表示されますが、それ以外のサイトは見れない状態になると思います。
ルータパスワードの登録
次に、ルータにパスワードを登録します。
まずブラウザから http://ntt.setup/ にアクセスします。
するとパスワードの登録が求められるので適当なパスワードを登録してください。
これがルータのパスワードになります。忘れないようメモを取っておきましょう。
ルータの接続先設定
ＮＴＴ東日本のサイト等ではパソコン自体にPPPoEを登録するような記載があったりしますが、新し目のMacBook ProなどではLANケーブル自体が繋げません（Ethernetアダプタが必要）。
なのでルータに設定することにします。
先ほどアクセスした http://ntt.setup/ に再度アクセスします。
すると名前とパスワードが求められるようになります。
名前には 「user」を、パスワードには先ほど設定したパスワードを入力してOKを押してください。
これでルータの管理画面に入ることができます。
ではルータの管理画面より接続先を設定しましょう。
プロバイダから届いた封筒の中に「接続ユーザー名」と「接続パスワード」が入っていると思います。
これを接続先の設定に登録します。ちなみに接続先名は@niftyとか適当で問題ありません。
これで設定は全て完了しました。yahooなどにアクセスしてみてちゃんと表示されるか確認してみてください。
以上、お疲れ様でした！
paiza会たのしい
Mackerelから見た、サービスの思想と機能について - DevLOVE関西#102
今回もDevLOVE関西主催のイベントに参加してきました。
というわけで、@daiksyさんや@Posauneさんの話を通じて、サービスの思想についての僕なりの気づきを書いておこうと思います。
Mackerelの思想と機能
Mackerelというサービスの説明は、エンジニアをワクワクさせる『直感的サーバ監視サービス』となっています。
今回あったMackerelについての話を振り返ってみると、公式ブログやニュースレターにリリースを毎週欠かさず告知することで、今週はどういう機能が追加されたんだろう？と期待させたり、エンジニア心をくすぐるmackerel-agent-pluginsなどの拡張機能や、監視設定自体をコード化できるといった機能を次々と追加したりと、ワクワクさせる仕掛けがいろいろありました。
そして、それらの機能が直感的に導入できるよう、コピペするだけで動くように作られていると。
実際に導入デモをやっていましたが、5分くらいで動いていました（！！）。
つまり、Mackerelの全ての機能は説明にある一言に沿っているかどうかを基準に実装されているようです。
ちなみに、ユーザーの要望を取り入れるかどうかは、その機能がワクワクするかどうかを基準に考えるみたいなことを、質疑応答の時間で@daiksyさんが言っていたような気がします（自信ない）。
思想を一言で表す
こうやってサービスの思想を一言で言い表すことで、チームが目指すべきユーザーに与えたい価値がはっきりするし、その価値に共感するユーザーが集まる構図になりますよね。 また、サービスの思想に対してある程度の市場規模があるかどうかをあらかじめ調べておくことで、そのサービスがスケールするかどうかも見えるんじゃないかなーと思いました。
以上、DevLove関西運営のみなさん、今回もめっちゃいいイベントありがとうございました。
「レビュー」をもっとうまくやってみる - DevLOVE関西#93
DevLOVE関西主催の勉強会にまたまた参加してみました。というわけで遅くなりましたが書き起こしを。
個人的なメモかつだいぶ忘れてしまっている内容なので変なところも多々あると思いますがご了承ください。
シナリオレビューの紹介
登壇者：森崎修司(@smorisaki)
名古屋大学 大学院情報科学研究科 准教授
レビューの効果
テストのタイミングで確認して修正するとなると遅い
なのでレビューのタイミングで確認したほうがもちろんいいよね
ただし…
テストの工数が削減できるという観点のレビューでないと意味ない
じゃあどういうレビュー内容がテストの工数を削減できるのか？
レビューのアンチパターン
- 一部だけしか見ない
インデントはスペース4つで統一してください。とか - 人格攻撃
こんなのもわからないなんてエンジニアとしてどうなんですか？とか - 説明会とか進行がおかしい
ではこれから説明会レビュー会を始めます。お手元の資料を…とか
ではどうしたらいいか
レビューの準備
レビューの準備に必要なことは、レビュー前に適切な目的を設定し合意しておくということ
具体的には「問題種別の抽出する」と「検出シナリオを決めておく」（後述）
これらをみんなで合意することが一番大事！
レビューによる問題の検出
事前に設定した問題種別に沿って検出する
→どこをどうチェックしたかは予めチェックリストを作ることで明らかにしておく
レビュー技法
Defect-based reading Perspective-based reading
Defect-based readingとは
漏れ・曖昧・誤りの3つの観点でレビューを実施する技法
ちなみに漏れ（一番難しい）
漏れ
検討漏れ
→そもそも検討ができていない場合がある
あなたにとっての「常識」とは？
→使う人にとっての常識を定義する
ドキュメントを読んでしまうと先入観が入ってしまう
→ドキュメントを読む前にソフトウェアのあるべき姿を想像して望む曖昧
読み手にとって複数の解釈ができてしまうものは、読み手の想定や定義が必要となる誤り
外部や内部で定義されたドキュメントやコードの不整合が原因であることが多い
Perspective-based reading
そもそもテスターはテストを実施できるのか？
のようににテスター・発注者・利用部門・プログラマそれぞれの立場で考えてレビューを実施する技法
シナリオレビュー
レビューの目的を共通認識として持つ
レビューの効果に応じて濃淡をつける
指摘は網羅性を確認する
（この辺駆け足だったのでメモできず…）
ワークショップ
その1
http://www.miyazaki-ac.jp/?action=cabinet_action_main_download&block_id=100&room_id=1&cabinet_id=1&file_id=1140&upload_id=3180
これをレビューして問題になりそうな箇所を5つ挙げて下さい。
問題種別の設定方法
トップダウンの例
「グローバルで使われる案件ワークフローシステム」について考えてみる
→どこが一番価値のある品質か
→システムが停止しては困る
→大容量ファイルを処理できる
→日次処理に影響が出ないようにする
↓
システムの停止の際に原因が分かるようにするとか
大容量ファイルは処理時間がどれくらい掛かるかとか複数アクセスされた場合どうなるかとか
↓
つまりレビューで何を見るべきか、また何が大事かはそのシステムにとっての価値で決める
それを決めるのがシナリオである
ワークショップ
その2
http://www.city.matsusaka.mie.jp/www/contents/1340350276686/files/120188-3.pdf
このシステムにとっての価値を順位が高いものから5つ挙げて下さい。
まとめ
ワークショップは3人1組でやったのですが、その1ではレビューの観点がバラバラだったのが、その2では価値順位も含め、かなり近しい観点にまとまりました。
その価値順位に対してお互いが合意してからレビューをすれば、かなりいいレビューとなりそうです。
あとレビュー本すごく良さそうでした。
なぜ重大な問題を見逃すのか？間違いだらけの設計レビュー改訂版（日経BP Next ICT選書）
- 作者: 森崎修司
- 出版社/メーカー: 日経BP社
- 発売日: 2015/10/06
- メディア: Kindle版
- この商品を含むブログを見る
Qiita:Teamとesa.ioを使ってみた感想
はじめに
今の会社ではQiita:Teamを使っている。
一番古いのを見たら1年以上前の投稿があったので、けっこう使ってますね。
で、使っているうちにいろいろ気になるところが出てきた。
なので、今お手伝いしている会社にesa.io使ってみません？と言ったら使ってくれることになった。 使ったのは大体5ヶ月くらい。
両方ガッツリ使ったので、誰かのために書いておこうと思う。
情報をどうやって分類するか
Qiita:Teamではストック型ツールにもかかわらず情報が流れちゃうっていうのにすごくストレスが溜まっていた。
投稿した時に分類がされないから、どんどんいろいろな情報が流れていってしまう（日報とか書いてたときはエライことになってしまってた）。
まあ、気をつけてタグ付けしていったらいいんだろうけど、タグ付け自体エンジニア以外の人にとってはハードルが高い。
esa.ioは/で区切ってね。と教えるだけで階層分けしてもらえた。
このアイデアは素晴らしいと思う。
記事が書きやすいか
僕もエンジニアなのでそんなに気にならなかったんだけど、どうやらQiita:TeamのUIは記事を書きにくいらしい。
個人の資質とか企業文化とかももちろんあるんだろうけど、投稿してる人の属性がかなり違う。
Qiita:Teamに記事を投稿するのは9割がたエンジニアばかりなんだけど、esa.ioはそれが6割くらいになっている。
UIについてはそんなに詳しくないからなんとも言えないんだけど、データ的にはそんな感じで、esa.ioは非エンジニアにとってはすごく書きやすいみたい。
他の人がどういったことに興味があるか
Qiita:Teamの前のバージョンではその記事を誰がストックしているかが見れていたんだけど、なぜか見れなくなってしまった。
その記事に誰が興味あるかって結構大事だと思う。
esa.ioではwatchっていうのがストックに当たるんだけど、これは誰でも見れる。
XXXさんがこの案件に関わっているのにwatchしてなかったら、watchしといてねと言えば暗黙知もなくなると思う。
まとめ
エンジニアがほとんどの会社だったらQiita:Teamでいいんじゃないかな。
もともとQiitaから派生したものなので、使い心地は似ているし。
ただ、その分ストック型ツールとしては非エンジニアが使いにくい部分も多い。
@bash0C7さんも言ってたけど、エンジニア以外の職種の人にも書いてほしいならesa.ioのほうがいいと思う。
あと、Qiita:TeamはちょっとずつUIとかも変わったりしていってるんだけど、どこが変わったのかをユーザーに教えてくれないのはすごくもったいないなーと思ってしまう（先日大幅に変わった時くらい？）。
リリースノートとかもそうだけど、esa.ioはユーザーとの距離感をいちばん大事にしている会社だと思う。
不具合修正の対応とか見ててもOSSみたい。
サービス運営のあり方として見習いたいところです。
追記
ちなみにesa.ioはExcelもアップできちゃう。Qiita:Teamもそのうちできるようになるのかな。
