よしたく blog

ほぼ週刊で記事を書いています

Jupyter Notebook で IOPub data rate exceeded エラー

エラー内容

IOPub data rate exceeded.
The notebook server will temporarily stop sending output
to the client in order to avoid crashing it.

Google翻訳による日本語

IOPubデータレートを超えました。
ノートブックサーバーは一時的に出力の送信を停止します
クライアントをクラッシュさせないために。

発生の状況

Jupyter Notebookを使って大量のテキストデータを処理している時、処理結果をprint文で表示しようとしたらJupyter Notebookの画面上に出現した。試しにテキストデータをファイルに出力したところ4.6 MBあった。正確な閾値は確認していないが上記のファイルサイズが一つの指標になればと思い参考として載せておく。

解決策

  1. 一度Jupyter Notebookをすべて落とす
  2. 次のコマンドを実行し設定ファイルを作成する。
    • jupyter notebook --generate-config
    • 設定ファイルは~/.jupyter/jupyter_notebook_config.pyに出力される
  3. 作成した設定ファイルをテキストエディタで編集をする
  4. 編集前
    • #c.NotebookApp.iopub_data_rate_limit = 1000000
  5. 編集後
    • c.NotebookApp.iopub_data_rate_limit = 10000000
    • #コメントアウトを削除する
    • 0を一桁増やす
  6. Jupyter Notebookを起動する

技術ブランディングについて考える / 第4回 転職透明化らぼ-技術ブランディング編 にスタッフ参加した!

1ヶ月ほど前ですが第4回 転職透明化らぼ-技術ブランディング編にスタッフ参加してきました。「技術ブランディング」のテーマに惹かれて参加自体を決めたわけですが、参加枠である「求職者側」でも「採用者側」でもなかったこととてぃーびーさんを始めスタッフ側の人が全員知っている人だったので思い切ってスタッフに立候補してみました。元イベントスタッフバイトの経験を活かし、結果的に会全体がスムーズにおこなわれるよう支援できていたら嬉しいです。

rtlabo.connpass.com

転職透明化らぼとは?

転職透明化らぼとは?については、connpassにある説明を引用したいと思います。

「転職透明化らぼ」は、転職活動における企業と個人の情報差を埋めることで、求人企業はよりよい人材とマッチしやすくなり、求職者は自身にとってよりよい企業とマッチしやすくなることを目的としたイベントです。
労働人口の減少、特にエンジニア採用に関しては採用競争の激化の中、個人にとっても企業の採用担当者にとっても転職・選考の質が上がることは個人や組織の幸福につながることだと信じています。
転職をスッケスケにしていきましょう。

技術ブランディング

今回のテーマの技術ブランディング、こちらについてもまずはconnpassにある説明をまずは引用させてもらいます。

採用競争が激化するエンジニア採用。
そんな中、企業がなぜ技術ブランディングに取り組むのか?
そもそも技術ブランディングとはどのようなものなのか?
企業に所属する個人は技術ブランディングにどのように取り組むことを期待されるのか?
求職者個人は技術ブランディングができるとどのような恩恵があるのか?
採用企業、技術広報で関わるメディア、フリーランスといった多様な立場から、そのポイントを発表し、パネルで質問にこたえていただきます。

今回自分は次の項目が気になったために参加をしました。

自分の周りにいるエンジニアの多くは「この領域が好き!」「この領域が得意!」を1つはあると感じていて、そういう羨ましさから自分にもコアとなるようなものが欲しいと思っていました。気にしすぎても良くないと思う自分もいる中で、自分のコントロール範囲外のこのことを周りの人がどう感じているのか、どうしていきたいのか話す場はなかなかないので非常に楽しみでした。

本編

内容についてまとめたかったのですが、スタッフ業務をしていたこともあり気になるトピックしか聞けなかったため、全体の内容はこちらをご覧いただければと思います。非常によくまとまっていて参加レポートのお手本でした。自分はこの手のレポートものが苦手なので、今後参考にしたいと思います(笑)

yui-nishimura-log.hatenablog.com

mottox2さんの「プレイヤー視点の技術ブランディング

個人的に一番興味を持って聞けた部分は、 mottox2さんの「プレイヤー視点の技術ブランディング」でした。

ブランディングができている人って?

自己紹介部分に書かれていた「プレイヤー視点(マネージャー・経営層ではない)」の段階からターゲットが明確でしたし、また自身の経験から話されているのか話もわかりやすくて聞きやすかったです。「そもそも技術ブランディングができている個人は誰?」という問いかけから、「誰もが大物になれるわけではない」という流れがすっと入ってくるものでしたしあんまり気負いすぎるのも良くないなと思いました。モヤッとしていたものがクリアになった感覚ですね。次に少しスコープを狭めて、「特定の分野・活動で認知できる人」はいないかという質問でした。これは何人か思い浮かべることができ、このぐらいスコープが狭ければ「自分にもできそう!」という感覚や、自分の好きな分野を自信を持って伸ばしていこうと思えました。途中でのまとめとしては、個人の技術ブランディングとは、何ができる人なのかを発信し、対象に認知してもらうことと書かれていました。自分の活動を振り返っても出来たとは言えませんので反省ポイントです。

なんで発信をして認知をしてもらうのか

発信することによるメリットを「知られる立場」「伝える立場」から語られていました。これは自分もいくつかメリットを感じています。 「知られる立場」では、発信する人が集まってきたり、信頼度の初期値が上がるなどですね。週イチでブログを書く会である「Write-Blog-Every-Week」で知り合えた人もたくさんいましたし、社内外でアウトプットしている人という認知を貰えて信頼残高が非常に高い状態から始められて物事の進み具合がスムーズです。 「伝える立場」は、人に伝える回数が増えるので理解が深まる事が挙げられます。また伝えることを期待される回数も増えるので、自ずとインプットの量も増えますね。

どうやって実現するのか

ここはやはり積み重ねしかないんですね。これはブログを続けてきても思います。一回書いたぐらいでは認知というものは到底無理ですね。また、特定の分野について書き続けるというベクトルの方向性も大切になってきます。自分はこのベクトルを合わせるのが下手なので、技術面でのブランディングができていません。本気でブランディングを考えるならば、真剣に計画を建てなければいけないでしょう。

おわり

mottox2さんの内容を振り返りつつ、自分の実体験とともに感想を書いてみました。自身の環境も変わり、また年末の区切りのいいタイミングでもあるので来年に向けて正しいベクトルでのアウトプットを考えていきたいと思います。自身の活動を透明化していくことで信頼残高を上げ、今度は転職透明化らぼのスタッフ参加をお願いされるようになっていきたいですね。

write-blog-every-week から学ぶ、目的と継続の大切さ

この記事は、write-blog-every-week Advent Calendar 2019の4日目の記事です。

adventar.org

自分はwrite-blog-every-weekと言う「週一でブログを書くコミュニティ」を運営している。よく勘違いされるのだが、このコミュニティを作ったのは自分ではなくKojirockさんで、自分は2番目に入ったこともあり同じく初期メンバー数人と共に運営管理の立場でやらせてもらっている。むしろ運営管理に自分自身も関われているのが嬉しいし、賑やかすことが自分の中で得意だとも思っているので楽しくやれている。

yoshitaku-jp.hatenablog.com

そんなコミュニティも立ち上がってから1年が経ち、特に問題もなくやってきた(自分の知らないところで問題があったり、感じてたらすみません)。自分自身も無事にブログ更新が100週を超え、記事数も100を超えコミュニティには感謝している。コミュニティの内部としては、もちろんメンバーの入れ替わりはもちろんあったが、なぜここまでコミュニティとして続けてこられたからと言うと、やはり参加者が自分の中でブログの継続という「目的」がはっきりしていたからだと思う。

現在自分が所属する会社で統計学の勉強会が発足されていてるのだが、参加者の「統計を学びたい」という目的が明確なので、この記事を書いた各段階で5回目となるが誰も脱落することなく続いている。もちろん一人で継続できるのが制約が少なく良いとは思うのだが、同じ目的を持った人が集まることで情報の共有もできたり、みんながやっているから自分もやらなきゃとモチベーションの低下も防げるのでコミュニティを形成することは非常に良いと思う。

また、目的の他にも週1が「習慣化のリズム」として一番やりやすいと感じている。コミュニティの決まりごととして週1で更新することを定めているが、月1でも週2でもうまくいかなかったように感じる。誰しも平日5日間の中でエンジニアリングを通して解決できたことや、躓いたことが1つはあるはずだし、仮になかったとしても通勤や休日の間に見つけるといったリカバーが可能なギリギリの範囲であると思っている。

これも社内での統計学勉強会での例になるが、月1だと各々のプライオリティはきっと下がっていったはずだし、週2だと回数が多くて予復習が難しくなったと思う。結果的に、週1が程よいバランスで続けることができるベストなラインであると思う。また、週1で続かないことは今の自分には必要ないことであったり、本当はやりたいことではないのかもしれないので、一度なぜ続かないのかを見つめ直すべきであるのかもしれないと自分の経験と照らし合わせても思う。

目的が明確化されていることと週1のリズムが、何かを続けていく上で大切なことだと2つのコミュニティから見てきた。今年一年を振り返るとブログや登壇のようなアウトプットを続けてきたことによって、自分自身が救われることが多く、アウトプットを継続することの大切さを実感してきた。このようなメリットを自分自身が実感しているからこそ、今現状に悩んでいる人にもアウトプットを継続的にやっていってほしいし、勧めていきたい。そして、継続することが難しいと感じている人にこそ「write-blog-every-week」に入ってほしいし、自分は運営管理を通してアウトプットしていきたい人をこれからも支援していくことができればと思っている。

write-blog-every-week.netlify.com

challenge-every-month コミュニティとは

この記事は、 challenge-every-month Advent Calendar 2019の2日目の記事です。

challenge-every-monthとは?

「各個人で毎月達成したい目標を設定し、全員で励まし合いながら頑張る」 コミュニティです。3名でスモールスタートしたコミュニティも発足して半年ほど経過し、口コミで少しずつ増えた結果現在15名前後の全員エンジニアが在籍しています。コミュニケーションは主にSlack上でやり取りをしています。

特徴

分報の導入

challenge-every-month では、使いたい人には分報を使ってもらっています。分報の詳しい説明はこちら。

c16e.com

tbpgr.hatenablog.com

分報を許可したのには理由があり、月初での目標設定と月末での振り返り 以外 でのコミュニケーションを増やしたかったからです。Slackのrandomチャンネルを使って各個人の目標進捗をつぶやくことは、別の人の話題が混ざってしまったりもするのであまり良いとは思えませんでした。人が書き込んでいる時に、自分の話題を割り込ませるのって気が引けますよね。このような理由から、 その人の話題に特化したタイムラインを作りたい ため採用しました。すべてのtimesに入ることも強制ではありませんし、もちろん作らなくても大丈夫です。

もちろん始めてからは良い作用がありました。てぃーびーさんがあげているメリットを借りますと次のようなものがあげられます。

  - モチベーションをもらえる
    - あいつは今日もがんばってるな。私もがんばろう。
  - ヒントをもらえる
    - 各自が呟いた「思ったこと」のなかに自分の行動へのヒントがあったりする
    - アドバイスをもらえたりする
  - 閃きが増える
    - 様々な視点の考えを知ることができる
    - 気兼ねなく意見を交換し合える場の存在

これらのメリットは自分自身も、またメンバも感じてもらっているんじゃないかと思います。

コミュニティ内での開発

現在challenge-every-monthでは、2つのアプリケーションがGitHub上で管理されながら開発されています。

github.com

一つは自分が作った目標を掲示しておくサイトです。ただ、使ってみたいという理由でGridsomeを使っています。現在開発が中途半端なところでとまっているので、年末年始に一定の水準まで持っていきたいです。

もう一つは、アキさんが作ってくださったCEM(challenge-every-month)-太郎です。CEM-太郎はSlackアプリとなっていて、Slack上でコマンドを打つことで、各月の目標やその振り返りなどを対話形式で入れることが出来ます。アキさんが非常に丁寧にドキュメントを作ってくださっているので使いやすいです。次のURLは管理が徹底されているissuesです。

github.com

このアプリケーションたちは、どうやって実装をしたらいいかとか、個人アカウントに依存しない形でどうやってデータを管理すればいいかなど活発な議論がなされていて、日々新しい知見が溜まっていきます。

おわりに

最初の通り、challenge-every-monthは 「各個人で毎月達成したい目標を設定し、全員で励まし合いながら頑張る」 コミュニティです。しかし、少人数であるがゆえに皆が積極的に関わることで非常に濃い体験が出来ていることは間違いないのではないかと思います。なにか面白いと感じた方は、自分メンバ宛てに連絡をとってみてください。

交通系データアイデアソン(レッドハッカソンHIROSHIMA 2019 episode.2) に参加した!

東京から広島まで移動し、交通系データアイデアソンに参加をしてきました。自社としてMaaSに力を入れたりナレッジが欲しい段階だったので参加を依頼され、自分としても 「アイデアソン」 に参加をしたことがなく興味があったため行ってきました。

レッドハッカソンHIROSHIMAとは?

広島を中心に活動されているエンジニアリングコミュニティ団体 「HMCN」 が企画されたイベントです。

HMCNは最新のテクノロジーに関する活動やハッカソンなどを主催する、オープンなエンジニアリングコミュニティです。
TMCNの兄弟コミュニティとして、主に広島地区、中国地方を中心に活動を行っています。
デジタルなものづくり・ことづくりに関心のある開発者やデザイナーをネットワークして、共に創る、共創の場を生み出すため様々な活動を行っています。

今回は広島にある江田島(えたじま)を対象として、現在オープンにされている交通系データを活用し新しいサービスを創出するアイデアソンを実施しました。場所は イノベーション・ハブひろしまcamps」 でした

hmcn.connpass.com

イデアソンとは?

イデアソンとは、アイデアや思いの近い人で即席チームを作り、新しい商品・サービスのアイデアを創り出すイベントです。エンジニアにとっては、手を動かさずアイデアだけを考えるハッカソンと言えば通じるかもしれません。エンジニアの視点を持っているとアイデアを出したタイミングで「フロントエンドはどうすればいい」とか「バックエンドとデータの持ち方を考えないといけない」といったことを、アイデアソンの段階では考える必要がないので気が楽かもしれません。

個人的な準備

イベントの参加ページを見る前までは、江田島 の存在すら知らなかったので下見を実施しました。

小用港(こようこう)からレンタサイクルを借り、海上自衛隊幹部学校まで移動、また海辺の新鮮市場へ南下しました。

三高山の砲台まで行きたかったのですが、小用港から片道25km前後あるので諦めてしまいました。この経験を通して地図を眺めているだけではわからない江田島の大きさを肌で実感しました。ちなみに江田島は瀬戸内海で4番目に大きい島だそうです。水も澄んでいました。

イデアソン

本編のアイデアソンは40名ほどでおこなわれました。まず4-6名ほどに分かれ各テーブルで簡単な自己紹介をおこない、すぐに頭の体操となりました。

メモ用紙程度の大きさの紙とペンが用意され、プロジェクターに映された言葉に対して直感的に自分の思ったことを書いていきます。プロジェクターに映されることは次のような言葉です。

  • 自分が好きなこと
  • 自分が好きなもの
  • etc

いくつかの選択肢の中から質問を選択し、自分が思いついた答えを書いていきます。質問を変えながら3,4回繰り返し、答えが書かれた紙を真ん中に集めます。

次に真ん中から集めた紙を各自1枚引き、その言葉と 江田島とデータ活用」 を紐付けたアイデアを練ります。真ん中に集めた紙から引くため、他の参加者が書いた紙を引く可能性がありますが、そこでも直感を大事にし、アイデアとしてまとめます。

最初に各テーブルでの自己紹介はおこないましたが、次に参加者全員で自己紹介と考えたアイデアを発表します。自分の予想通り東京からの参加は自分だけで唯一の県外の参加となりましたので、自己紹介が終わった後も 「東京から来た人」 と参加者の印象に残ったようで良かったです。自分は前日にレンタサイクルを借りて下見をしたこともあって、「サイクルマップ」 を提案しました。

自分が提案した 「サイクルマップ」 は、江田島のサイクルマップをまとめるだけではなく、県外から来る人を想定しており、周辺のフェリーや新幹線とのデータ連携を図り最適な行き帰りを提供し、さらには島内のおすすめスポットをリコメンドするものでした。

40人のアイデアを発表した後は、自分が気に入ったものを2つ選び投票する時間となりました。自転車と交通データを組み合わせるアイデアが重なったこともあり、自分のアイデアは落選となってしまいました。その後、得票数が多かったものを6,7ほどピックアップし、そのアイデアたちに乗っかりたい人でチームを結成しました。ここからはチーム作業です。

イデアに乗っかった人たちで、アイデアをより発散また収束させ最終的なプレゼンへと持っていきました。自分のチームは広げる人とまとめる人ことが得意な人がおり、非常にテキパキとすすめることが出来ました。 最終的な案は 「ちょい乗りひよっ子サイクリング」 と題して、江田島へカジュアルサイクリングを楽しみに来ている人に対して、途中で自転車を乗り捨ててもいいようなサービスとしました。

バスとタクシーのリアルタイムデータを活用し、自転車を乗り捨てた際にスムーズに乗り継ぎができることや、自転車をバスの中に乗せることも想定したサービスとしました。

結果

結果的には自分たちのチームは入賞することができませんでしたが、チームとしてのまとまりもよかったですし、自身を持って提案できたサービスとなりました! アイデアソンと言うことでしたので、現在提供されている交通系データを用いて考えるものではなかったのが自分の想定とは違った部分でしたが、日々の業務や生活で凝り固まった頭をほぐし柔軟な発想で考えることができ非常に面白い体験でした。また、周りのチームも普通では考えられないような発想が飛び出してきていた面白かったです。

おわりに

2月に今回のアイデアソンを実現するためのハッカソンがおこなわれます。今回のアイデアから本当に実現するようなものが出てきたら、またどのように実現するのか非常に楽しみです。また自分も行けるように日々の業務を頑張っていこうと思います。懇親会を含め、広島の方々ありがとうございました。

じぶん Release Notes 0.29.7

11月1日〜30日のあいだの出来事がリリースされました。

技術・開発関連

技術面での取り組みは以下の通りです。

  • Plicanを触って開発をした
  • Azure Logic Appsを使って、しきい値が超えたときにTeamsへ通知する機能を作成した

イベント

参加したイベントは以下の通りです。

読んだ

買ったもの

  • AirPods Pro
    • 買わなきゃ損なぐらい最高のガジェット

ブログ

リリースノートを除き、次のエントリを書きました。

PV数

11月は3,217でした

f:id:yoshitaku_jp:20191201212813p:plain

11月の結果

  • 必ず達成したいこと
    • テスト駆動開発読み切る
      • 未達
      • すべて通しで読まなければいけない内容なので、まとまった時間が取れず難しかった
    • 初めてのSpark読み切る
      • 達成
      • 今現在必要なページだけ読んだ
  • やったことない・チャレンジ系
    • 大島に行ってロードバイクで一周
      • 未達
      • 出張が多く土日に移動も発生したため、日にちの確保ができなかった

12月の目標

  • 必ず達成したいこと
  • やったことない・チャレンジ系
    • 大島に行ってロードバイクで一周
      • 今年は全然乗れていないので最後に…

Spark+AI Summit in Europe に行ってきた! -3日目-

Spark+AI Summit in Europe に行ってきた! -2日目- の続きの記事です。

yoshitaku-jp.hatenablog.com

yoshitaku-jp.hatenablog.com

プレゼン資料・動画が公開されていたので、自分が見聞きしたセッションをメモとして残しておく。

The Internals of Stateful Stream Processing in Spark Structured Streaming

databricks.com

www.slideshare.net

ACID ORC, Iceberg, and Delta Lake—An Overview of Table Formats for Large Scale Storage and Analytics

databricks.com

www.slideshare.net

Democratizing Machine Learning: Perspective from a scikit-learn Creator

databricks.com

From HelloWorld to Configurable and Reusable Apache Spark Applications in Scala – A Developer’s Journey

databricks.com

www.slideshare.net

Real-Time Fraud Detection at Scale—Integrating Real-Time Deep-Link Graph Analytics with Spark AI

databricks.com

www.slideshare.net

# MLflow and Azure Machine Learning—The Power Couple for ML Lifecycle Management

databricks.com

www.slideshare.net

Spark+AI Summit in Europe に行ってきた! -2日目-

Spark+AI Summit in Europe に行ってきた! -1日目- の続きの記事です。

yoshitaku-jp.hatenablog.com

yoshitaku-jp.hatenablog.com

プレゼン資料・動画が公開されていたので、自分が見聞きしたセッションをメモとして残しておく。

学習した内容は随時更新していければ

Koalas: Making an Easy Transition from Pandas to Apache Spark

SparkをPandasのように扱えるKoalasというフレームワークの話

やはり流行っているフレームワークのように使えるのは、別の物を覚えるよりかは学習コストも減るしありがたい

Databricksに勤める日本人のUeshinさんが発表されていた

databricks.com

www.slideshare.net

Transforming AI with Graphs: Real World Examples using Spark and Neo4j

databricks.com

www.slideshare.net

Making Homes Efficient and Comfortable Using AI and IoT Data

databricks.com

www.slideshare.net

Extending Spark SQL 2.4 with New Data Sources (Live Coding Session)—continues

databricks.com

Getting Started Contributing to Apache Spark – From PR, CR, JIRA, and Beyond

databricks.com

www.slideshare.net

# Best Practices for Building and Deploying Data Pipelines in Apache Spark

databricks.com

www.slideshare.net

Pelican で画像ファイルを扱う方法

実装方法

まずはcontent/imagesを作成し配下に表示したい画像を配置する。imagesディレクトリと名付けるとPelicanではデフォルトで「静的ファイルが置かれているフォルダ」 と見なされる。この状態でpelican htmlコマンドを実行すると、outputディレクトリ配下に画像が出力される。

f:id:yoshitaku_jp:20191117231539p:plain

配置した画像ファイルを使う

リンク編

配置した画像ファイルを使うにはリンクを使う。試しにfirstpost.mdファイルの末尾へ、次のように記述してみる。

**画像ファイルを配置したみた**

[imagesフォルダのいぬ画像]({filename}images/animal_stand_inu.png)

実際の画面では次のようになる。

f:id:yoshitaku_jp:20191117231608p:plain

クリックをすると次のように画像が表示され、URLも指定されたディレクトリを指している。

f:id:yoshitaku_jp:20191117231715p:plain

サムネイル表示編

一番最初に「!」をつけると、そのまま表示される

**画像ファイルを配置したみた**

![imagesフォルダのいぬ画像]({filename}images/animal_stand_inu.png)

ページの中に表示されていることを確認してもらうため、画像が途中で切れているがそのままキャプチャをとった。 f:id:yoshitaku_jp:20191122150801p:plain

Python製の静的サイトジェネレーター Pelican を導入してみた

Pelicanとは?

PelicanはPython製の静的サイトジェネレーターです。他の言語では、GoのHugoやReact.jsのGatsby.jsが有名です。自分自身は、Vue.js製のGridsomeを使う記事を書きました。

yoshitaku-jp.hatenablog.com

yoshitaku-jp.hatenablog.com

自己学習として様々なものに触れてきました。最近は仕事でPythonで作業することが増えてきており、プライベートでも触れるPythonに関するもの探しているところでPelicanを教えてもらいました。Python製の静的サイトジェネレーターでは2019/11/10現在一番GitHubスターが多いです。静的サイトジェネレーターの比較ページはこちら。

www.staticgen.com

Pelican関連のページ

ブログ

https://blog.getpelican.com

GitHub

https://github.com/getpelican/pelican

ドキュメント

https://docs.getpelican.com/en/stable/

インストール方法

Pythonの仮想環境を作ってから実行します。Markdownで作成するので、pelicanをインストールする際に最初からmarkdownを使うように指示をしておきます。

python -m venv pelican
cd pelican
source bin/activate
pip install pelican [Markdown]

記事を書く

ブログの記事を書くときはcontentフォルダの配下にMarkdownファイルを保存します。 ひとまず記事が見れる状態になればいいのでファイルの中身は次のようにしましょう。

Title: タイトル
Date: 2019-11-10 00:00

テストページです。

Markdown内のメタデータに関しては、ここを見ると色々載っています。

docs.getpelican.com

記事を生成し、ブラウザで確認する

前章で記事をcontentフォルダに書きました。 書いた記事をサイトに公開する形に生成しなければなりません。 pelicanコマンドをcontentフォルダに対して実行します。

pelican content/

pelicalコマンドを実行するとoutputフォルダに記事が生成されます。

次にブラウザで生成した記事を見てみます。 pelicanコマンドをオプションを付けて実行します。

pelican --listen

実行直後のターミナルでは、特に表示されませんが大丈夫です。

ブラウザでhttp://localhost:8000を叩いてみましょう。次の画面が出れば完成です。

f:id:yoshitaku_jp:20191110194923p:plain