YAMAGUCHI::weblog

海水パンツとゴーグルで、巨万の富を築きました。カリブの怪物、フリーアルバイター瞳です。

次世代Webカンファレンスに参加しました #nextwebconf

はじめに

こんにちは、Go界のエビスビールです。今日、法政大学外壕校舎で開催された次世代Webカンファレンスに聴衆として参加してきました。

以下自分のメモです。

server_perf (10:00-11:00) #405

メモ

  • パフォーマンスの勘所としてクライアント側の変化があると思う
    • @mirakui: スマホのWebとアプリの比率があがってる
    • @xcir: デスクトップからのリクエストは減って、スマホのネイティブアプリでの処理が増えている。APIアクセスが主。
    • @cubicdaiya: Webからのリクエストが1割もなくて、ほぼネイティブクライアントからのリクエスト。15000qps。
    • APIリクエストが主になったことによりJSONのやり取りだけの単純なものになったが、リクエスト数は増えた。
  • 高速化しにくい部分をどうパフォーマンスさせる?
    • @cubicdaiya: 非同期処理できるところはできるだけやっている。APIサーバになるべく負荷をかけさせない。
      • キャッシュの作成、DBのインデックス作成など。IOの処理を上げる場合には札束で殴るしかない。
    • @xcir: 自分でコード書いていないことが多いので改善しづらい。仕様を変えることで改善するしかない。
  • キャッシュ戦略
    • @xcir: キャッシュ生成コスト vs 閲覧数。どのレイヤでキャッシュを作るか。
    • @cubicdaiya: 各レイヤで共通の部分で使うデータをキャッシュする。(
  • 文化
    • @mirakui: ログインしてるとキャッシュしない。(A/Bテストの妨げになる)
  • 言語
    • @mirakui: Rubyは運用しやすい言語である、と思うことにしている。
    • @xcir: PHPにしてる。理由付けができればなんでもいいと思う。
    • @cubicdaiya: GoとかCとか。ずい分前からCPU1コアでの性能は頭打ちでマルチコアで処理しようとしているので、それに対応した言語が良い。
    • @cubicdaiya: APIはルーティングだければできればいいと思っているので、軽量な物を使っている。
    • @xcir: キャッシュできないものをどうやって処理するか
  • ミドルウェア
    • @xcir: VernishでESIやってます。ngx_small_light使ってます。
    • @cubicdaiya: nginxではモジュール書いたりとか、Luaやmrubyで簡単なアプリケーションサーバを書いてる。
    • @cubicdaiya: 私はngx_small_light使ってません。あれはApacheのmod_small_lightの移植で、Apacheはrequest per childで制限できるのでImageMagicが多少リークしてもメモリ死しない安心感がある。nginxはそれがない。
    • @cubicdaiya: nginxはマルチプロセスシングルスレッドなので、できるだけノンブロッキングにしないと死ぬ。
  • 海外展開
    • @cubicdaiya: 国土の広さが関係することが結構ある。TLSハンドシェイクを早くする、証明書の失効確認を早くする
    • @xcir: 「AWSさんよろしくお願いします」
    • @mirakui: 「us-eastに置いておけば大体どこからでも等しく遅い」
    • @mirakui: 海外はネットワークがすぐに切れる。大雨でネットが断線とか。
      • @xcir: ベトナムではカジュアルに海底ケーブルが切れる
      • @cubicdaiya: 東南アジアだとアプリのサイズが大きいと全然ダウンロードされない。
      • @mirakui: Opera Turboはすごい。勝手に画像を縮小。JSを展開。なぜか動いている。開発者はデバッグ地獄。
  • CDN
    • @xcir: 使ってます。
    • @cubicdaiya: 使ってるし昔は自社でCDNを使ってる会社にいた。画像など。
    • @mirakuri: 次世代CDNが来ると思う。CDN内で処理を完結させる。(画像変換や動的キャッシングなど)
  • 録画はあとで公開されます。

話題に出たもの

ui/ux (11:10-12:30) #407

メモ

  • このセッションの「ui/ux」という表記について
    • @kotarok: 僕は「UI/UXと言うな派」だったんだけど皆がどう思うかが気になる。
      • UIというのは表層にあるものであって、直接ユーザが直接触ることができるもの。
      • UXはユーザが感じた体験。直接設計できるものではないと考えている。
    • @manabuueno: 言葉の定義=プロトコル。相手に伝わるのであれば良いかなと。
      • 例:UX/UI, UI/UX, UI+UX, UIUX
      • デザインする対象は個人的には「UI」でいいかなと思っている。
    • @yukio_andoh: 僕は言ってもいい派。
      • ただし一緒に働くなら、それぞれをどういう意味で使っているかをちゃんと見極める必要がある。
      • 唯一気になるのは「求人の時にUI/UXデザイナー募集」という文言。別の仕事だからね。
    • @theodoorjp: 僕は転向派。「いうな派」→「いいよ派」
      • 「ユーザ体験」という言葉が表すものが難しい。
      • エモーショナルデザイン
  • 「ユーザ」とは
    • @yukio_andoh: 「使う前の人」「いつも使ってる人」「使ったけどいまは休眠してる人」全部ユーザ。
      • エモーショナル・デザインの表紙のレモン絞り器はとても美しいけど使ってみるととても使いづらい。使いづらいというのも「経験」
    • @manabuueno: 「ユーザ」っていうのがいま流行っている。(eg. 山手線ユーザ)
      • コンピュータ用語が日常的に使われるようになった。(ユーザ、フラグ、デフォルト)
      • 以前は「ヒューマン」という言葉が使われていた。アメリカでは顧客というぐらいの意味合いで使っているのだろう。
  • 現世代と旧世代の境目は?
    • @theodoorjp: iPhoneの登場によって変わったと思う
    • @yukio_andoh: 直接的なタイミングはiPhoneの登場だと思う
      • 緩やかな行こうとしてはURLが意味を持たなくなってしまった
    • @manabuueno: 若い社員は自分の会社のサイトすらググってる
    • @yukio_andoh: 10代の人間はもうブックマークすら使わない
    • @manabuueno: 自分が感じる変化のタイミングとしては「iPhoneの登場」「APIを公開し始めたころ」
      • 自分の感覚で「ブラウザ」と「ウェブ」が対応してる時点で旧世代
      • 今はウェブと言ってもクライアントはネイティブで持っている
    • @kotarok: 「ハッカーと画家」が書かれたころはネイティブアプリを更新するのが難しい前提でHTML UIを押している。
      • いまはGoogle Play StoreやAppStoreがあるおかげでそれは解消されている。
      • そういう意味で逆行している気がする
  • いまあるネイティブとHTMLの揺り戻しを踏まえて次は何が来るか
    • @theodoorjp: スマホのネイティブアプリのUIはある程度もう定跡化してしまっている。あれが最高系だとは思わない。
      • Google NowやSiriをはじめとする人工知能的なインターフェースは新しいなと感じている。
      • Facebookで個別コメントができるようになっているのはヘビーユーザーだけ。
    • @yukio_andoh: 理想形は楽器のように「だれでも簡単に音を出せるけど、使いこなすのは難しい」
      • 個々人でUIが異なると操作を伝えづらい
    • @kotarok: インターフェースの学習曲線というものを考えないといけないと思う
  • ハイパーリンクハイパーテキストという大発明
    • @kotarok: インターフェースとコンテンツの同化
    • @manabuueno: 「文字が押せる」というのはわかるが課題がある。
      • 対象の文字の長さが短いと押せる領域が減る=重要でないように見える
    • @kotarok: 現世代Webは文章を起点にしているのでリンクは動画や音声といったコンテンツに対してのポインターとして無理がないか
  • 文章に依らないウェブ性
    • @yukio_andoh: リンクを自分で辿らないといけない、というのが次世代ではなくなるのではないか。
      • YouTubeのおすすめのようにどんどん提示されてくるもの
    • @theodoorjp: 「リンク」はいま「人間が読めるもの」と「機械だけが読めるもの」が半々ぐらいになっている気がする。
      • もうちょっとルール付けが合っても良いと思う。
    • @yukio_andoh: rendorman formatやMIDIのような30年持つ規格を定義するというのは大変なこと。
  • URLの軽視
    • @kotarok: あるコンテンツの塊に対して一意なURLを振ることをもっと考えたほうがいいのでは
    • @manabuueno: 1つのURLに対して動的にコンテンツが変化するのは?
    • @manabuueno: 製作者側が良いと思うものを1つのURLに対応させればよいのではないか
  • いまのインターフェース
    • @kotarok: かつてiPhoneが出た頃にすべてHTML5で行くとJobsが宣言した。Facebook
    • @manabuueno: いまこの会場にいる人は何ができて何ができないか知ってるのでほっといていい。そうじゃない人を考えていかないといけない。
      • ネイティブのアプリみたいに「アイコンを押すことですぐにTwitterが使える」という状態をユーザが近く感じるのではないか。
      • そういう意味でブラウザがメインでなくなっているいまの状況は「半分ウェブが死んでるのでは」
    • @theodoorjp: 次世代はブラウザがメインでないのだとしても、いまの通信プロトコルは使われ続けるのだと思う。
    • @manabuueno: 我々が「次世代Web」のようなテーマで語るときは「人類愛」のようなテーマを感じる
  • コンテンツの保存
    • @yukio_andoh: 残そうと思うものはほっといても残る。そうでないものをどう残すか。
      • 本はずーっと残っていく。どうでもいい日々の発言こそ残したい。
    • @theodoorjp: 僕は逆で忘れたい。それをどう設計するか。
    • @manabuueno: たかだか5年前のウェブページが見れなかったりする。
      • 自分とコンテンツの距離が保存される限りにおいてはすべて保存すべきだと思う。
  • さいごに
    • @manabuueno: iPhoneなんだよ。Appleは神。
      • iPhoneが出る前にまったく議論されなかったマルチタッチの話が出た直後に活発になされた。
    • @theodoorjp: いまのスマートフォンのUIから脱却していくんだと思う。
    • @yukio_andoh: スマートフォンの登場によって、「使いやすい」「使いにくい」という感覚が研ぎ澄まされて、評価がなされ、みんながUXの人になっていく。
    • @manabuueno: ウェブの多様性多態性があるので、次世代も大丈夫。

話題に出たもの

webrtc (13:30-14:30) #407

メモ

  • WebRTCってぶっちゃけいまどうなの
    • @tonofo: ひとことで言うと割と辛い。過去の資産を無理やり使ってる。非常に多くの知識を必要とする。
    • @voluntas: 割と辛い。
    • @iwashi86: 本当に辛い。よくあるのは「つながらない」「SDKほしい」。RFCの山。
  • なぜつながらないか
    • @voluntas: ChromeFirefoxとEdgeで全部仕様が違う。さらに6週間でブラウザが自動更新されて死ぬ。
      • クライアント側で頑張ってやる場合はJSで頑張るしかない。
  • 辛い話
    • @tonofo: SDPとCandidateが読めないと絶対運用できない。運用環境で何が起きてるかはCandidateしかない。
      • @voluntas: ブラウザの世界にテレビ会議SIPでやってたことが降りてきただけ。
      • @tonofo: 繋がる最強のやつはLTE回線。社内ネットワークは結構厳しい。
      • @voluntas: 企業内のネットワークはUDPに関してかなり厳しい制限がある。TURNでやる場合は中央サーバが必要になってしまう。
        • NAT超えのためにTURNやSTUNをちゃんと理解していないといけない。
    • @voluntas: 利権に合わせていくしかない。
    • @iwashi86: 現状Firefox以外は独自仕様。
  • ORTC
    • @iwashi86: 期待している。
    • @voluntas: 期待してない。Skypeのために策定しているようにしか見えないので1.0の間は傍観。
    • @tonofo: どこまで仕様通りにできるようになるのかは疑問。
  • WebRTC 1.0の仕様がそろそろ決まろうとしている
    • @voluntas: WebRTCの残念なところとして1つの解像度の映像しか送れない。
      • 同時サイマルキャストが実装されないと厳しい。多人数テレビ会議
      • Chrome実装済みだが、オリジナル実装なので独特なSDPを書かないといけない。
      • SFUで辛いのは暗号化が重い。
    • @tonofo: GPUを使ったMCUなどハードウェア側で頑張らないと辛い。
    • @voluntas: 「WebRTC = RTCP何じゃないかと思ってる」
    • @tonofo:
  • テストどうするんですか、あるいはクライアントの話
    • @tonofo: 社内であればChromeのバージョンもコントロール
      • Electronはとても良い
      • クライアントのバージョンはネイティブで固定できる。ただしOSバージョンは固定できない。
    • @voluntas: Firefoxは仕様にすぐに追従するし素晴らしい。Chromeはつらい。
  • 組み込み
    • @tonofo: RasPi2超速い。H.264のハードウェアエンコーダ積んでる。
    • @voluntas: エンコーディングだけでCPUパワー持ってく。
  • 使っていく話
    • @voluntas: プラットフォーマーは辛い。運用をするのが辛い。
      • ただそれに乗っかればプラットフォーマーが各種スタックを用意してくれているのでそれが良い戦略。
    • @iwashi86: 正直付加価値としてWebRTCを使っていくというのが正攻法。
      • これまで他のことでやっていたものを置き換える、補強するという感じ。
    • @tonofo: SDK側が辛い部分を吸収するので、SDK使ってる分にはある程度楽。
    • @voluntas: 動画や音声みたいな簡単に見えるものの裏側にある困難な部分をいかにプラットフォーマーが吸収するか。
    • @tonofo: WebRTCってこれまでのウェブの形と違う形になっているので面白いと思う。
  • これからの想定ユースケース
    • @voluntas: たとえばSFC/MCU前提でやってみてだめだったらP2Pに落ちるとか
    • @tonofo: Facebookチャットも一度TURNで繋いでから様子をうかがってP2Pに落としたりしている
    • @iwashi86: SVCについても触れたい
    • @voluntas: MCUではSVCのメリットないんで、結局SFU頑張れっていうことになる。
  • あらためてWebRTC 1.0が12月までに決まる
    • @voluntas: サイマルキャストが入って仕様が落ち着けば結構期待できる
    • @iwashi86: 海外ではWebRTC系のビジネスが結構活発。資金調達も結構大型のものもある。
      • 日本でも遅れてブームが来ればいいな。

話題に出たもの

identity (14:40-16:00) #407

メモ

  • これからRP(Relying Party)は何を使ったらいいのか
    • @_nat: OpenID Connectに対応していればOpenID Connectのライブラリだけでいけるようになるはず
    • @nov: TwitterはずっとOAuth1.0で、更新の兆しなし。
  • リスク情報共有
    • @_nat: あるアカウントがある1つのサービスでアカウントテイクオーバーされた場合に他のサービスに即座に知らせて2次被害を防ぐ
      • 他のサービスにあるアカウントが所属している
  • OAuth PKCE
    • @_nat: 後方互換だし、IdPもRPも全部コレ使ってたらいいんじゃないの
    • @nov: 最終的に悪意の第三者にアクセストークンが渡らないように作った仕組みがPKCE
    • @_nat: ランダム文字列をチャレンジ時、それのハッシュをベリファイ時に送ることで、
  • Proof of posession token
    • @_nat: interpolやFBIの溜飲を下げるためには一段セキュリティの高い認証方法が必要
      • Bearar tokenは持ってったらすぐに使えるトークン(例: JRの切符)
      • Proof of posession tokenは使用時に所有者の確認を行うトークン(例: 飛行機のチケット)
  • @_nat: 「パスワードは公害」「パスワード税をかけたほうがいい」「総量規制をかけたほうがいい」
    • なぜパスワードでやるかといえば「安く導入できるから」
    • 税金と両壁をなすのは「保険」がある。情報漏えいした場合にどれくらい補填できるか。
    • パスワードが悪いんじゃなくて、実際にはヘボいパスワードシステムが悪い。
      • Googleはパスワードシステムに見えて他の要素も含めて判断している。300人チームでやっている。それだけのコストを掛けてやりたいのか。
  • ログインやログアウトってなんで必要なんだっけ
    • @nov: authenticatedされた状態が必要なだけだよね
    • @_nat: ローカルデバイス、特に個人デバイスであれば一度認証したらずっと使えていればいいはずだしそうあるべき
    • @mad_p: キオスク端末の場合は個人端末の認証情報を渡せる仕組みがあればいいだけのはず
  • 認証と識別
  • ユースケース毎のリスク評価

話題に出たもの

monitoring (16:10-17:30) #407

メモ

  • 監視とは何か
    • @mikeda: 稼働率を上げるもの。
    • @fujiwara: 落ちないようにするため。それは現在も将来も含めて。(キャパシティプランニングなど)
    • @songmu: 稼働率を最適にするだけでなく、キャパシティを最適にする
      • テストやコンフィグもコードになっていったのと同じように、監視もコードになっていくんだと思う。
    • @rrreeeyyy: サービス提供者側が提供されるべきレベルを保つためのもの
  • チェック監視とメトリック監視
    • @songmu: 最近の傾向としてメトリック監視が増えている
    • @mikeda: 昔に比べると細かい値を取り始めた
    • @fujiwara: チェック監視とメトリック監視は各々役割が違う気がする
    • @mikeda: メトリック監視で割といけることが増えてきたかなという印象
  • 監視の間隔
    • @fujiwara: 数日間は1秒単位のデータを取得したい。
      • 1分間隔だとたまに起きる短い間隔でのスパイクを拾えない。
  • 監視難しい問題
    • @rrreeeyyy: 言語によってどこを監視していいかわからない事が多い。
    • @mikeda: 監視テンプレートをもっと公開してほしい
    • @songmu: Chefが良かったのは個々人が秘伝のシェルスクリプトでやってたことが公開されてシェアされた
      • 管理もそういうふうになればいいな
  • アプリケーションエンジニアとインフラエンジニアの棲み分け
    • @rrreeeyyy: お客様によってはアラートごとに連絡ほしいという人もいれば、対応策まで考えてから連絡してほしいという人もいる
    • @fujiwara: アプリケーションエンジニアにもアラートを感じてもわらないとサービスはよくできないと思う
      • ただ一応段階をわけてアラートを出している
  • どういうチームを作ればよいのか
    • @mikeda: 少人数で24時間の監視体制を回すのは現実的ではないのに、それをやってるのがこの業界。
    • @fujiwara: 特殊なチームメンバーの状況に依存すべきではない。どうしても対応できないならMSPなどに任せましょう。
  • 監視周辺技術
    • @songmu: MackerelではGraphiteを使っている
    • @mikeda: オープンソースを使ってる人が多いのでZabbix使ってます
    • @rrreeeyyy: これからは監視とクラスタマネージメントはセットとなるのでConsulには注目してる。
    • @fujiwara: 時系列データベースどれつかったらいいですか
    • @songmu: Graphiteかと。datadog結構すごいと思う。
  • fluentdが与えた衝撃
    • @mikeda: アレのおかげで各社でログをどんどんあつめてグラフ化するという流れができた気がする
    • @fujiwara: どんどんログの処理がストリーム処理に近づいている
  • SaaS使ってる?
    • @mikeda: 一部datadog使ってるけど大した規模ではないです。(金銭的な理由)
    • @rrreeeyyy: MSPという事業の性質上、当然自前でやっているが、
    • @fujiwara: いまいまはZabbixで全部やってるけどいずれ外出ししたい。監視の監視までしたくない。
    • @mikeda: 他社の監視の事例を見てると、zabbixやnew relicが多いが、いまはdatadogやmackerelなどがだいぶ増えている。
  • 原因特定・未来予測
    • @mikeda: 未来予測系はまだやってない
    • @rrreeeyyy: あんまりやってない。ただやりたいと思う。
    • @fujiwara: アラート上げるときに0 or 1ではなくて「何か違うよ」を入れたい。
    • @mikeda: 未来予測や任意の異常値の検出などは難しいかもしれないけど、検知の自動化はしたい。
  • RDSのようなサービスを使うことによって監視は楽になったか
    • @rrreeeyyy: 管理は楽になったが、監視がどれくらい楽になったかはわからない
    • @fujiwara: クラウドベンダー内でブラックボックスにされたものは何も見れないのが良し悪し
    • @songmu: 自動修復をしてくれるおかげで監視をする部分が減ってるというのはある
  • 繋ぎっぱなしのサービスが増えてきた
    • @songmu: WebSocketやHTTP/2などが出てくればますます接続に関しての監視は難しい
    • @rrreeeyyy: 実際難しくなっていているが、どうするかは考えていかないといけない
    • @fujiwara: そういう場合はアプリケーション側がログを出してあげないといけない
    • @songmu: アプリケーション側だけでなくミドルウェアも考慮してあげないといけない
  • これからの監視
    • @mikeda: 目の前の監視を続けていきます
    • @rrreeeyyy: 次世代には監視業務はなくなればいいなと思うが当分なくならないので良くしていきましょう
    • @fujiwara: 要するに夜寝たいので、監視システムを育てていきましょう
    • @songmu: インフラエンジニアがなくなると言われた時期もあったが、なくなるどころか複雑化している。

話題に出たもの

感想

とにかくまず運営および登壇者の皆様お疲れ様でした。参加率はいかほどだったかわかりませんが、あれだけの人数を登壇者だけでつつがなくさばいたというのは本当にすごいです。事前打ち合わせなど何回ぐらいあったんでしょうか。いずれにせよ、カンファレンスの運営が次世代な感じでした。

内容に関して言うと、自分が想像していた「次世代」よりはずっと手前側の話になっていたような気がしますが、それもあれだけの参加者がいて聴衆に気を遣ってもらうとどうしてもそうなってしまうのかなとも思います。現に自分がIdentityのセッションに参加した時はRFCやISOのドキュメント番号がどんどん出てきて、話を聞きながらそれを追うのに必死という状況で、現状把握ですら大変なのに、それ以降の話となったら追いつけなかったと思います。

今後開催されるかはわかりませんが、久々に自分のフィールドにない話題をその道のプロから聞ける良い機会でした。一参加者としてとても楽しかったです。ありがとうございました。

Goオールスターズでpackage managementについて話してきました

はじめに

こんにちは。Gopherファンクラブ会員番号3番です。去る、10月11日にdots.さん主催の「Goオールスターズ」で登壇してGoでのpackage managementについて話してきました。

ツイートのまとめや他の登壇者の方の資料はこちらです。

資料

資料はこちらです。

大体の流れはこんな感じです。

  • 当面はGo本体では当面は「ソースコードの明示性」「下位互換性」を保つためにgoツールでパッケージのバージョン管理をすることはしない
  • 代わりにGo1.5ではvendoringを「実験的に」サポート
  • すでにGo 1.4でもgb, godepなどvendoringをサポートする3rd partyツールがあるが、ディレクトリの切り方とか見るとgbが筋が良さそう

真のオールスターズ、あるいは #mattncon について

今回は「Goオールスターズ」というタイトルのイベントで登壇したわけですが、大変こっ恥ずかしい思いで登壇したわけです。というか、 @moriyoshit が一般参加で聞いている場で発表するというのは大変つらい。

で、ビアバッシュのあとで登壇者+αで、都内のエンジニアが大変お世話になっている渋谷の北海道で2次会をしたわですが、mattnさんが来てない時点で永遠に「オールスターズ」は開催されないという結論にいたり、 #mattncon 開催の機運が高まりました。

自分は途中で2次会を抜けてしまいましたが、その後もTwitter上では #mattncon について熱いツイートがされていたので、皆のテンションは高いままだったのでしょう。実現のために個々人に何ができるか考えていくことが大事だなと思いました。

イタリア旅行記

はじめに

こんにちは。気がつけばまたブログの更新が滞っていました。7月最終週〜8月第一週にかけてイタリアに旅行に行ってきたので、旅行記を残しておこうと思います。

旅程

今回の旅行ではイタリアの中央の3都市(フィレンツェベネチア、ローマ)を巡る旅行をしてきました。日程は7/28-8/5の7泊9日。事前情報でフィレンツェベネチアは街が小さいと聞いていたので、この2都市では2泊、ローマでは3泊の予定としました。各都市の移動は高速鉄道でした。

都市 日程
フィレンツェ 7/28-7/30
ベネチア 7/30-8/1
ローマ 8/1-8/4

またガイドブックは次のものを購入した。どれでも良かったけれど、立ち寄る3都市の情報が程よく均等に載っていたので。現地でもレストラン選びなどの時に役に立った。

イタリア (ララチッタ)

イタリア (ララチッタ)

気付き

色々と細かく書けると思うのですが、まずは旅程全体を通してと各都市での気付きを箇条書きで列挙。写真を見てからだとよりわかってもらえるかもしれないので置いときます。

全体として

  • イタリアではクレジットカード決済ではPIN番号を聞かれ、サインでの決済はほぼできない。おそらく偽装カード対策か。また現金払いのみのところも多い。
  • 英語は案外通じるが、イタリア語を幾つか覚えていったほうが当然楽しい。
    • 看板や印刷物などに対してはGoogle翻訳がものすごく便利。(後述)
  • 今回の日程(夏期)では日没は20:30前後で、街は日没に合わせて夜が始まる感じ。飲食店も日付が変わるまで開いている所も多い。
  • どの展示施設も事前にインターネット予約しておくべき。(後述)
    • 特にバチカン博物館は当日2時間近く炎天下で待つ人もいた。
  • 寺院などを巡る際は服装や荷物の大きさに注意。
    • 肌の露出があると入場拒否される可能性があるので、男性でも大きめのストールなどを持って行くと便利。(腰にまいて足全体を隠せる)
    • かばんもレンズ一本が入るカメラバック程度の大きさにおさえておかないと、クロークに預けなければならなかったり、下手をするとクロークすら無いので注意。
  • とにかく日差しが強く直射日光を浴びていると非常に暑い。一旦日陰などに入ると涼しい。帽子は持っていった方がいい。(自分は持って行かなかった)
  • 上記の状況なので水をとにかく飲んでいた。観光地の露店などでは500mlで€1とか取られるけど、スーパーなどにいけば1.5Lで€0.5とかで買える。
    • 何も言わないと炭酸入りが出てくる可能性もあるので、炭酸水(伊: frizzante)か自然水(伊: naturale)か表記を確認する。
    • 飲食店でも水は有料。1-1.5Lで€1-2くらい。その時も "still water" など水の種類を言うこと。
    • 街中に泉があり、飲用可のところが多数。水質は硬い。(後述)
  • 街中にトイレが少ない。
    • 食事のときや施設に行ったときトイレを都度借りたほうが良い。
    • 夏は特に水を四六時中飲んでいるのでトイレ探しは結構大事な要素。
    • 公衆トイレもあることもあるがたいてい有料。(ベネチアでは1回€1.5だった)
  • 公共WIfiはそんなにない。出来ることならSIMカードを買おう。(後述)
    • 飲食店でも「Free Wifi」の看板を掲げて入るものの、店員にいちいち聞くのは面倒。
    • 訪れた3都市では4Gが入りました。
  • 飲食店に飛び込みで入らないように注意。ボッタクリに合わないための対応。
    • 店に入る前にTripAdvisorやGoogle Placesで評価を確認。星の数が高くても「5つ星かつコメントなし」の評価ばかりのところは怪しい。日本語のレビューで高評価のところは結構信頼できる。
    • 疲れきっていたときにこれをしないで飛び込んだ店で見事にぼられた。(後述)
  • Google Mapsは最高に役に立った。
    • 周辺情報(レストラン、スーパー、薬局、観光スポット等々)
    • ルート検索での公共交通機関情報(バスのルート番号、水上バスの番号等々)
  • チップは本当にサービスに満足した時に支払う、という文化を感じた。
    • 向こうが欲しいと思っている場合はサービス料を予め上乗せしていたり、席料(コペルト)を取っていることも多い。

フィレンツェ

  • ルネサンス文化が色濃く残る街。街もルネサンス時代から残る建物が多く、景観の保存にも力を入れている印象。
  • 完全な観光都市というわけではなく、地元の人は観光以外の産業でも生活している印象。
    • 街も観光のみではなく、生活に必要な施設(スーパー、百貨店等々)も数多く見られる。
    • 飲食店・商品の価格も観光価格という印象はそこまで受けなかった。
  • 食事はトスカーナ料理なので肉が多い。
  • 主要箇所は全部徒歩で移動可能。むしろタクシーを捕まえるほうが難しい。
  • ウフィッツィ美術館をしっかり見たければ3時間以上は確保しておきたい。

ベネチア

  • 街並みは綺麗だが、水路は結構汚い。ただ臭くはなかった。路地は迷路のようで非常に楽しい。フィレンツェよりは広いものの、頑張れば全部徒歩で回れる広さ。
  • ご飯は他の都市に比べて2割ほど値段が高い。
    • ぼったくりも多い。旅行中唯一ぼったくられたのがベネチア
  • バーカロという立ち飲み居酒屋が最高に良い。ベネチアに行ったら食事の時間は気にせず、小腹が空いたらバーカロで軽く飲んで移動、というのが良いかもしれない。
  • 水上バスは時間帯によっては非常に混む。
  • ゴンドラは値段交渉をしようと思ったが軒並み公定料金で自分がまわったところでは交渉ができるところがなかった。
    • 値段は30分で€80と割高。二度と来ることもないと思ったので乗った。
    • ゴンドラに乗らなくても十分ベネチア観光は楽しめるので、乗らないという選択肢もあり。
  • サンマルコ広場は夜に行くと人も落ち着いていて綺麗。
    • サンマルコ寺院は荷物を預けないと入れない場合がある。
    • 満潮時に広場が浸水することがある。今回はたまたま少しだけ浸水した様子を見ることができた。
  • 完全な観光都市なので客引きなどは多い。

ローマ

  • 泉が街の至る所にある。
  • タクシーは色が白いものは安全。
  • カラカラ浴場跡での野外オペラの帰りはタクシーが必須。カーテンコール前に席を立てばすぐにタクシーに乗れる。
    • タクシー会社がタクシー待ちの列を整理していて、ボッタクリの心配もない。ホテルの人が「スペイン広場まで€13以上請求してくるようならすぐにぼったくりだと訴えろ」と事前に忠告してくれたが、見事€13で到着した。
  • スリが結構いる。細心の注意を。財布をポケットに入れておくなんて「スってくれ」と言っているようなもの。
  • 結構スーパーが多い。
  • 当たり前のように古代ローマ時代の遺跡が街中にある。とにかくスケールが大きく圧倒される。
  • バス網が発達していて非常に便利。地下鉄もそこそこ便利。
    • バス、地下鉄が時間を守ることはまずない。時間前に出発するとか当たり前。
    • バスではチケットを確認していない。適当。
  • ローマ市内から空港まではタクシーでのボッタクリが横行したため、最近は固定料金を設定することが多いとのこと。

細かなTipsなど

箇条書きで(後述)としたところに関して追記していきます。

インターネット予約

とにかく並びまくるので、出来る限りインターネットでチケットを予約していったほうが良い。またもし突発的にどこかの施設に行きたくなったとしても、携帯からインターネット予約でチケットが買えるならそのほうがよいこともある。とにかく炎天下長時間並ぶのは本当に疲れる。自分が予約していった施設は次。

Google翻訳

Word Lensを統合してから海外旅行に欠かせないアプリケーションになりました。人だったら英語でコミュニケーションをすることも可能ですが、掲示物・印刷物はGoogle翻訳がないと内容の確認が不可能です。試しにベネチア水上バスのチケットで見てみましょう。こちらがオリジナル。イタリア語だけでまったくわかりません。

これをGoogle翻訳にかけるとこうなります。

f:id:ymotongpoo:20150809210318p:plain

なんとなく分かる!

他にも店舗の営業時間やお店のメニューの解読にも役に立ちます。(後述)

プリペイドSIMカード

この時代なので旅行中に現地で情報を集めることはあたりまえだと思う。海外用のWifiルーターを借りてもいいんだろうけど、割高だし余計な荷物が増えるのは面倒。イタリアではVodafone、TIM、3IT、Windなどいくつかのキャリアがありますが、Vodafoneの情報が多かったのと、最初に泊まる都市のフィレンツェVodafoneのショップがあったので、そこで購入しました。

購入したのは「Vodafone Holiday」というプランのプリペイドSIM。300分の通話、SMS300通、4G回線の接続で2GBまでのデータ通信がついて€30という良心的な価格設定。

購入は簡単で、Vodafoneの店舗へ行き、「プリペイドSIMをくれ」と言ってパスポートを提示しただけです。するとユニバーサルSIMをくれるので裏面のスクラッチを削ってPIN番号を取得。

自分が使っている携帯はSIMフリー端末なので、挿して再起動したらPIN番号を聞かれるので入力したら使えました。注意事項として、SIMを挿してからアクティベーションまでに2時間は携帯の電源をオンにしてはいけないとのこと。その間に電源をオンにすると、SIMのサーバ側での設定がおかしくなることがあるそうです。というか自分がそうなりました。

ぼったくりについて

ぼったくりには遭わないように気をつけていたのですが、ベネチアで歩きまわりすぎて疲れてたので、レビューを調べもせずに適当に入ったトラットリアでふっかけられて口論になりました。値下げはしてもらったものの予算より1500円ほど多く取られました。こちらのサイト にあるところの重量制というやつです。「おすすめですよ」と言われたので「お腹は空いていないから、1人分を2人で分けるけどいいかな」と聞いたら「もちろんOK」と言われたのでそのまま注文。(その時は重量制であることを知らず、ただ具材についての説明を受けただけ。)

食べ終わって会計が出てきたら表示の価格€9に対しての4倍の€36という値段。これはおかしいとメインのウェイターを呼ぶと

  • ウェイター「これは重量制なのは当たり前だ」
  • 私「中身について聞いた時に何も言わなかっただろ」
  • ウェイター「それは中身についてしか聞かれてないからだ」
  • 私「特筆すべきことは無いかと聞いただろ」
  • ウェイター「俺の仕事は中身を説明することだけだ」
  • 私「中身の説明にグラム数が入ってないだろ!」
  • ウェイター「グラム数を説明する義務はない」
  • 私「言い値じゃないか。大体お腹いっぱいだから1人前の量だと言ったのに、他のパスタも400gもだすのか。」
  • ウェイター「それは違う。これだけ特別」
  • 私「あきらかに値段ふっかけてるじゃないか」

と押し問答の末、€20になりました。とはいえ、まずくはなかったものの、そこまで美味しいかったわけでもなく...完全なぼったくりではなかったものの、良い勉強になりました。

そもそもこれはメニューをもらった時点でGoogle翻訳にかけておけばよかったのですが、他のページのメニューはすべて英語が表記してあったので油断してました。こういうこともあって、それ以降は特に慎重にお店に入る前にかならずTripAdvisorやGoogle Placesでレビューをきちんと確認するようになりました。

泉について

まさしく回復の泉の街のあちこちにある。24時間出続けていて冷たい。タオルを濡らして涼んだりすることもできる。硬水だけど、そのまま飲んだりすることも可能。

参考

旅行の際に参考にしたサイトや書籍など。

「逆引きGolang」で気になったところ

はじめに

こんにちは、タゾチャイティーラテです。最近急に蒸し暑くなったり、寒かったり中途半端な天気が多いですね。逆引きGolang というサイトが公開されてて面白いなあと思って見てたんですが、僕だったらこう書くなというものがいくつかあったので覚書きです。

文字列

部分文字列を置き換える

これは無理に strings 使わないほうが楽なんじゃないかと思いますがどうでしょう。自分で関数定義するのは面倒かもしれませんが。

package main

import "fmt"

func main() {
    s := "Apple Banana Orange"
    r1 := replace(0, 5, []rune(s), []rune("Vine"))
    fmt.Println(string(r1))
    r2 := replace(5, 6, r1, []rune("Lemon"))
    fmt.Println(string(r2))
}

func replace(start, length int, orig, target []rune) []rune {
    ret := make([]rune, len(orig)+len(target)-length)
    copy(ret, orig[0:start])
    copy(ret[start:], target)
    copy(ret[start+len(target):], orig[start+length:])
    return ret
}

16進文字列を整数に変換する

コメントに "0xを含んではいけない" とありますが、含んでも大丈夫です。その場合はbaseを0にします。baseを0にした場合は文字列の見て0が先頭にあれば8進数、0xであれば16進数と判断します。

package main

import (
    "fmt"
    "strconv"
)

func main() {
    s := "0xff"
    sh, _ := strconv.ParseInt(s, 0, 64)
    fmt.Println(sh)
}

漢字コードを変換する

たぶん書きかけなんだろうけど、直接 EUCJP は呼べないので japanese.EUCJP.NewEncoder() としないと動かない。

日付と時刻

これは別に本文と関係ないけど、 time パッケージにはRFCとかで定義されてるフォーマットは定数で事前定義されてるっていうのをFYI。

const (
        ANSIC       = "Mon Jan _2 15:04:05 2006"
        UnixDate    = "Mon Jan _2 15:04:05 MST 2006"
        RubyDate    = "Mon Jan 02 15:04:05 -0700 2006"
        RFC822      = "02 Jan 06 15:04 MST"
        RFC822Z     = "02 Jan 06 15:04 -0700" // RFC822 with numeric zone
        RFC850      = "Monday, 02-Jan-06 15:04:05 MST"
        RFC1123     = "Mon, 02 Jan 2006 15:04:05 MST"
        RFC1123Z    = "Mon, 02 Jan 2006 15:04:05 -0700" // RFC1123 with numeric zone
        RFC3339     = "2006-01-02T15:04:05Z07:00"
        RFC3339Nano = "2006-01-02T15:04:05.999999999Z07:00"
        Kitchen     = "3:04PM"
        // Handy time stamps.
        Stamp      = "Jan _2 15:04:05"
        StampMilli = "Jan _2 15:04:05.000"
        StampMicro = "Jan _2 15:04:05.000000"
        StampNano  = "Jan _2 15:04:05.000000000"
)

配列

配列に要素を追加する

append 使えばいいんですが、あんまり回数が多いと効率が悪いので、長さがわかってるならばバッファを確保したほうがよいと思う。

一致する要素を全て取り除く

まず全然関係ないけど、全体的にアンダースコア区切りの関数名がよく見られるけど、Goの慣習的には変数名も関数名もキャメルケースです。詳しくは ここ 参照。あと複数パッケージimportするときは括弧で囲ったほうが読みやすいかなあ。

deleteStrings()はまっすぐ書いたほうがスッキリ書けそう。

package main

import "fmt"

func main() {
    a := []string{"apple", "orange", "lemon", "apple", "vine"}

    str, a, err := deleteStrings(a, "apple")
    fmt.Println(str) // => "apple"
    fmt.Println(a)   // => "[orange lemon vine]"
    fmt.Println(err) // => "<nil>"

    str, a, err = deleteStrings(a, "apple")
    fmt.Println(str) // => ""
    fmt.Println(a)   // => "[orange lemon vine]"
    fmt.Println(err) // => "Couldn't find"
}

func deleteStrings(slice []string, s string) (string, []string, error) {
    ret := make([]string, len(slice))
    i := 0
    for _, x := range slice {
        if s != x {
            ret[i] = x
            i++
        }
    }
    if len(ret[:i]) == len(slice) {
        return "", slice, fmt.Errorf("Couldn't find")
    }
    return s, ret[:i], nil
}

おわりに

公式ドキュメントでは文法などはわかりやすく書いてあって、あのサイトだけひと通り読んでれば普通に書けるようになるのですが、やはり逆引き的にスニペットがあると便利ですね。これからも更新頑張ってください。

Ubuntu 15.04のサーバをWake on LANできるようにした

はじめに

最近、とある用途のために眠ってたマシンを引っ張り出してきた。こいつがまたいい働きをしてるんだけど、いくらファンが静か目とはいえうるさい。ということでWoLの設定をして、いい感じに必要なときだけ起動できる下地を作っておこうと思った。

BIOSの設定

まずBIOSの設定だけど当然使ってるマザーボードによって設定は違う。俺のおんぼろマザボ785GM-P45) の設定だと Power Management Setup → Wake Up Event Setup → Resume By PCI-E Device で Enable の設定をするだけ。

OSの設定

Ubuntu 15.04の方での設定は ethtool で実施。apt-getしようと思ったらすでに入ってた。

% sudo ethtool -s p5p1 wol g
% sudo ethtool p5p1
Settings for p5p1:
    Supported ports: [ TP ]
    Supported link modes:   10baseT/Half 10baseT/Full
                            100baseT/Half 100baseT/Full
                            1000baseT/Full
    Supported pause frame use: No
    Supports auto-negotiation: Yes
    Advertised link modes:  Not reported
    Advertised pause frame use: No
    Advertised auto-negotiation: Yes
    Speed: 1000Mb/s
    Duplex: Full
    Port: Twisted Pair
    PHYAD: 0
    Transceiver: internal
    Auto-negotiation: on
    MDI-X: Unknown
    Supports Wake-on: pg
    Wake-on: g
    Current message level: 0x0000003f (63)
                   drv probe link timer ifdown ifup

Wake-onが g になってるのを確認。このままだと再起動したら設定消えちゃうので、initスクリプトを新規作成。

% sudo vim /etc/init.d/wakeonlanconfig
#!/bin/bash
### BEGIN INIT INFO
# Provides:          wakeonlanconfig
# Required-Start:    $local_fs
# Required-Stop:     $local_fs
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: wakeonlanconfig
### END INIT INFO
ethtool -s p5p1 wol g
exit
% sudo chmod +x /etc/init.d/wakeonlanconfig

これで再起動して起動後にちゃんとWake on LANが有効になってるか確認。

% sudo reboot
% sudo ethtool p5p1
Settings for p5p1:
...
    Wake-on: g
...

テストのために終了する。

% sudo shutdown -h now

MacWake on LANのクライアントの設定

MacPortsを使ってるんで探してみると便利なパッケージがあった。

% port info wol
wol @0.7.1 (net)
Variants:             universal

Description:          wol can send a Wake-On-Lan magic packet to a target ethernet address
Homepage:             http://wake-on-lan.sourceforge.net

Build Dependencies:   autoconf, automake, libtool
Platforms:            darwin, freebsd
License:              GPL-2+
Maintainers:          jeremyhu@macports.org, openmaintainer@macports.org

これをインストールして、試してみる。

% sudo port install wol
% wol <UbuntuマシンのMACアドレス>
Waking up XX:XX:XX:XX:XX:XX....

Ubuntuのマシンが起動した。便利。

Raspberry PiのWake on LANのクライアントの設定

Raspbianを使ってるんでaptで探してみると発見。

$ apt-cache show wakeonlan
Package: wakeonlan
Version: 0.41-11
Installed-Size: 56
Maintainer: Thijs Kinkhorst <thijs@debian.org>
Architecture: all
Depends: perl, perl-modules
Size: 11510
SHA256: d93c21fe7023fd98ec9461047a67f1099addae6a46278e2fb0aea97d55d73f60
SHA1: 988ce3c2f1c6d04f715da153b8a7bfc74dac895a
MD5sum: 6d4c609468083aeedc329a2df9b77079
Description: Sends 'magic packets' to wake-on-LAN enabled ethernet adapters
Homepage: http://gsd.di.uminho.pt/jpo/software/wakeonlan/
Description-md5: 1f4cb6ce85d821307a46719513c54d04
Tag: admin::boot, implemented-in::perl, interface::commandline,
 network::configuration, protocol::ethernet, protocol::udp,
 role::program, scope::utility, use::transmission
Section: net
Priority: optional
Filename: pool/main/w/wakeonlan/wakeonlan_0.41-11_all.deb

これをインストールして試してみる。

% sudo apt-get install wakeonlan
% wakeonlan <UbuntuマシンのMACアドレス>
Sending magic packet to 255.255.255.255:9 with XX:XX:XX:XX:XX:XX

起動した。

結論

便利なのでWoLをもっと気軽に使えるシステムを作りたい。