スクリプト類とメニューボタン

トップ ソフト 雑記 日記 リンク

8月 24, 2015

YAPC::Asia Tokyo 2015に参加してきました #yapcasia

10年目、今年でとりあえず最後と聞いて、前から参加してみたかったYAPC::Asia Tokyo 2015に参加してきました。
CGIに手を出し始めたときはperlを使っていましたが、最近はPHPばかり書いているし、「perl以外でも全然大丈夫」「perlじゃない発表がある」と言われても、タイトルにperlが入っていると、なんとなくperlの背景とかちゃんと知らないから参加しにくいなと感じていました。
最後と聞いていたけど、たぶん名前変わるんだろうなと予想しながら東京へ向かいました。
そこで参加したトラックについて、感じたことなどを書いていこうかと思います。
見出しのリンクは動画やスライドや、スピーカーのブログ該当記事へ張っています。

前夜祭

この日は一日トラックEに居ました。
いきなりビールとおやつが並んでいる状態で、聞いていたとおりの会だ。

PHP帝国の逆襲!(を願うPHPerが話す最近のPHPについてのクイックツアー PHP7対応版)(リンク先自動再生)

一発目から鶉さんの軽快セッション。いきなりお酒も入って、ハイテンションで始まりました。
PHPerとしては、PHPのお手軽さとゆるふわ感が、始める敷居の低さとして働き、広く普及するに至ったと思っていて、ある意味これは利点なのではないかと考えています。
ただ、作り込むほど、経験を積むほど、ゆるふわなせいではまるポイントや、ゆるふわを許したくない場面というのが出てきて、それはいかんともしがたい場面でした。
PHP5でもいろいろと対策ができるようになったのですが、PHP7になってもその動きは続いていて、かなり安全で手が掛からないコードをかけるようになるのではないかと思いました。
速度も気にはなるところですが、基本的にはDBのレイヤーが一番重いようなシステムが多いので、速いことは嬉しいけどそれほど重要視しているポイントではありません。
そういう点では、最近ちょっと調べ始めているHHVM/Hackも気になる辺りです。
Hackはまだ簡単にビルドできないのが辛いねー。

はてなブックマークのトピックページの裏側

skozawaさんの、先日のElasticsearch勉強会で聞いた内容でした。
勉強会のときには聞けなかったのですが、辞書のメンテナンスをしていないとか、ノード数が6台というのが新しいポイントでした。
拙作ふぁぼるっくでは、naistの辞書とはてなキーワードのCSV、手動辞書管理でmecabの辞書をメンテナンスしています。ニュースサイトの記事のように、砕けた日本語でないなら、辞書を気にする必要がないというのは、羨ましい点だなぁと思いました。

技術ブログを書くことについて語るときに僕の語ること

ゆううきさんの技術ブログをはてブのホットエントリーに入れるための施策について。
ここのブログは日記と名付けているとおり、基本的には思ったことや感じたことがメインなので、みんなに読んでもらえると嬉しいというよりかは、こんなことしたよ、誰か同じような失敗をしたときに役に立てばいいなという思いで記述しています。
なので、注目される技術よりは、検索エンジンに取り込まれればいいや程度の認識で書いています。
訪問者が多くて広告収入だけで生きていけるようになればいいですね。そうしたらずっと好きなコードだけ書いて行けるんだろうけど、好きなコードだけだと、なかなかブログに書く苦労ネタが生まれないような気もしたりして、やっぱり苦労してコード書きたいのかなぁ。
コードを書くということは、何か克服したい困難があるわけだけど、困難を楽に解決していけたらいいな。

一日目

メリークリスマス!(リンク先自動再生)

perlを生み出したLarry Wall氏の基調講演。ホビットと指輪物語の内容を知らないので、半分ぐらいしか理解できませんでしたが、バスにひかれないように願っております。
同時通訳がなかなか大変そうでした。技術用語って、下手に翻訳するよりもそのままの方が通じる物があって、その辺りのバランスが絶妙だなと感じました。

Effective ES6

新しく策定されたECMAScript 6を書くに当たっての注意点。
PHPもそうなのですが既存コードのメンテばかりしていると、なかなか新しく策定された言語仕様を試す場面ってないのですよね。JavaScriptだって、しばらくはjQueryと付き合っていかないといけないだろうし、そうなると新しいJavaScriptを書く機会も訪れなさそうです。そこで新言語仕様を旧言語仕様に変換してくれるBABEL、便利そうですね。

今フロントエンドで何が起こっているのか

先のES6と合わせて、最新のフロントエンド技術について。
もっとフロントエンドも書かないと、この辺りの感覚が鈍りますね。
サーバサイドをやっていると、最終的にHTMLやJSONを生成すればいい感じになってしまって、取り残されている感があるので、聞いてみました。
ニュースサイトなどで並んでいる言葉で、だいたい何をするものかは分かるけど、なぜそれが出たのかという点で解説してもらったので分かりやすかったです。
同じような技術でも、なんとなく微妙な開発方針の違いで分裂しているのかと思っていたりしたのですが、違ったんですね。

Conway's Law of Distributed Work

リモート勤務をするに当たって便利なツールやサービス、そしてそれを使う心構えなど。
仕事で要求されるレベルによって、またその会社の標準ツールなどによっても、ツールやサービスは変わってきますね。紹介された中でもこれは使っていて知っているというものから、聞いたことが無く内容を見ても今の業務では使わないだろうなというものはありました。
せっかくリモート勤務で通勤時間を削減したのだから、さらにツールを駆使して業務時間を削減できるといいですね。
質疑応答を聞いていると、効率改善によって生み出された時間をさらに仕事時間に充てようとする日本人は、やっぱり働き過ぎなのかなぁと感じました。

esa.io - 趣味から育てたWebサービスで生きていく

前半は聞けていなかったのですが、サービスの育て方的な話。趣味から育てたサービスで生きたいですよね。せめて収入支出でトントンになって欲しい。

Lightning Talks Day 1

現在関わっている会社のサービスでもある、feedwindを作っているace氏のLTもありました。
LTって全体的に話者のトーク力もさながら、いかに面白い境遇に巻き込まれるかという、そういう技量もあるのではないかと感じました(笑)
一番面白い境遇にあったのが、LTのスポンサーをしていたネコトーストラボだと思います。サイトもよく分かりません。

二日目

この日は聞いてみたいセッションがずっとトラックDでした。

Google Cloud Platformの謎テクノロジーを掘り下げる

最近はGoogleもMap&Reduceは使っていないなど、まあ漏れ伝わってくることのおさらい的な感じでした。誰のどんなデータも、同じように超分散保存することで速度を稼ぐという方法は、やっぱり乗っかってみる価値があるのかなぁと考えました。

我々はどのように冗長化を失敗したのか

去年から続く「式年遷宮インフラストラクチャ」の続編。訓練とそれを本番に組み込むというのは、考えとしては有りなんだろうけど、冗長構成にして一個ぐらい死んでも大丈夫、みたいな構成を考えた方が無難なのかなと思いました。

MySQLで2億件のシリアルデータと格闘したチューニングの話

よくある貧弱なハード要件でハードなデータ処理を要求されるパターン。
新規データ投入でインデックスを後から作る話が有名なだけに、それをなぜ試さなかったのかちょっと疑問に思った。質問すれば良かったけど、なんか単純に思いつかなかっただけなのでは、と感じた。
とりあえず、客に対してソフトだけではどうにもならない問題もあることをちゃんと説明できるようにしておかないとなと感じました。

データ分析基盤を支える技術

TwitterのTLでの印象ではスプラトゥーンに熱を上げる人ですが、TDの中の人であるrepeatedlyさんのセッション。
TDの宣伝だけにとどまらず、Hadoopやそこから始まる分散技術に関する紹介。分散技術って、自分で大量のノードを用意できる財力も無いし、なんとなく別世界のお話という感じなのですが、そういうところを上手く組み合わせて行けたらいいのかなと感じました。

【特別企画】YAPCあるある(仮)

YAPC過去の実行委員長を迎えての振り返りトーク。結局宮川さんが口に当てているあの紫のやつはなんなんでしょう。YAPCとは関係なさそうで、あれが何なのか、いまだに分からない。

HTTP2 時代の Web

HTTP2の方がいろいろと便利なのはわかるし、Googleとかもhttpsがある方を優遇しちゃうよとか言われると、なんか趣味で作ったサービスでも金かけて証明書を取らざるをえないのかなと思ったり。
無理に使う必要はない、1.1も残り続けると言われても、悩みます。

Lightning Talks Day 2

二日目のLTは、勢いのあるものが多かったです。
あたりはかなりぐっときました。とくに会場ネットワークを担当されたCONBUのネットワーク敷設・撤去実演は圧巻。あの為に、LT開始時点で6階のネットワークが使えなくなったんだなと納得。 急なお仕事対応も会場からできて、本当に助かりました。

クロージング

YAPCは終わるけど、勝手に名前使っていいよ、Beaconでなんか公開するよということで、予想に近い流れ。新しい開発者カンファレンスに期待しつつ、さらに盛り上がっていくといいですね。

7月 25, 2015

Hack勉強会に参加してきました

勉強会の参加記録が滞っていたので本日二つ目の記事。
あおおにくん(@aooni_kun)さんとくれすとさんと、合わせて三人という、こぢんまりした感じで。
最初は大阪ドームそばのイオンのフードコートで開催予定だったのですが、ドームでライブがある日だったらしく、会場の開場?まで席が空きそうにない事態に。急遽上本町へ移動して、カフェでの開催となりました。
そういえば、阪神なんば線の新しい区間に乗ったの初めてでした。

あおおにくんさんも、くれすとさんも、ある程度Hackを嗜んでおられるようで、わたしは名前は聞いたことあるけど・・・程度の予習なしで行ったため、マンツーマンならぬツーメンズツーマンみたいな(聞いたことない)感じで、いろいろとHackの魅力を教えてもらいました。
最近わたしが書くコードは、ほとんどPHPとJavaScriptばかりで、あとは趣味でC++を少し(better cに少し毛が生えた程度)と、以前に仕事で.Net 2.0の頃までのVBとC#を書いていたという知識だったのですが、「PHPとC++とC#を足した」感じの言語だなと思いました。

PHPとJavaScriptを書いていて思うのは、やっぱり型は大事だなと。
PHP7でもその辺りは強化されますが、Hackはインタープリタではなくコンパイルして実行されるので、そのあたりの動きが厳密になっており、言語仕様の曖昧さによるハマリを極力無くそうとしている姿勢が感じられました。
PHPの「とりあえず書きゃ動くだろ」というのも入門としては便利だと思うのですが、HTMLの中にちょっと書いていた時代とは変わってしまったので・・・、PHPは広く使われすぎたんだ・・・。

いろいろ聞いたHackの魅力の中で、個人的好感度トップは、「システム内でファイルが混在可能」「コンストラクタの定義が楽」というあたりでしょうか。
Hackはファイル毎にPHPとHackが混ぜられるので、PHPのモジュールからHackを呼んだりその逆ができたりします。たまに言語自体を乗り換えてシステム全体をリライトした事例を聞いたりしますが、いやぁ大変だろうなぁと思います。混在可能な利点は、このようなときにモジュール単位で書き換えていけるということです。

Hackのチュートリアルがあるので、これはぜひ試してもらいたいです。
新しい言語と聞くと身構えてしまいますが、これのおかげで「Hack怖くないよ」と感じられるかと思います。
解いている途中で、なんかC++を書いている気分になって、PHPのlist関数が出てきたのにPHPだと頭が理解できませんでした。それぐらいに新鮮な感じで書けると思います。
(連想配列大好きっ子で、listをあまり使わないせいもある)

以前、HackのベースとなるHHVMが、まだHipHopPHPと呼ばれていた頃、PHPの速度に悩まされて自分でビルドしようとしたことがあるのですが、どうにもビルドできなくていろいろなモジュールを入れ替える羽目になり、入れ替えすぎてCentOSが動かなくなるという罠に陥りました。
名前も変わってかなり高速に進化しているようなので、ちょっと環境を作って乗り換えできるか試してみようかなと思います。
HHVMだと、使えるモジュールがまだ限られているというようなことを以前聞いたので、自前でビルドしたモジュールなんかが使えるのかどうかチャレンジしてみたい。

elasticsearch勉強会へ参加 & elasticsearchについて雑感

7月13日に大阪のYahoo事務所でelasticsearchの勉強会へ参加してきました。
ブログを書いていなくて、これを書いているのは7月25日ともう2週間も経ちますが、つらつらと。

内容はelasticの中の人である @johtani さんの「Elasticsearchの紹介
@takuya_a さんの「Elasticsearch での類似文書検索と More Like This API 詳解
@5kozawa さんの「Elasticsearchを用いたはてなブックマークのトピック生成
でした。

elasticsearchというと、よく聞くのがWebサーバのログをelasticsearchに放り込んで、kibanaで綺麗なグラフを描くというやつですが、今回の勉強会は本来?の使い方でもある検索に焦点を絞ったものでした。

わたしもelasticsearchは、趣味と仕事で少しだけ使っていますが、趣味の方はアクセス解析、仕事の方は全文検索で利用しています。
仕事でいろいろ試してみた限りでは、かなり検索の性能も良さそうでした。

現在、ふぁぼるっくで使っているPostgreSQLでもいろいろと不満点が溜まってきているので、いずれは別のデータベースに乗り換えたいなぁと思っています。
勉強会では、かなり検索に特化した使い方を紹介して貰えたので、たぶん何とかなるだろうなとは思うのですが、いろいろな制約からPostgreSQLの使い方がアクロバティックになっているので、その辺りが解決できるかどうかを調べていかないといけないなぁと。

現状の問題点と調べること
1.RDSでよく参照される最近のデータを保存、古いあまり参照されない古いデータを自宅サーバで保存。日次バッチでデータ移動している。
 elasticsearchでも、複数ノードで手動リバランスができるらしいので、 「このデータ境界以前をこのサーバに保存しろ」ということができるかどうか。

2.全文検索はsphinxsearchを利用して、RDSからデータをコピーしている。全てのデータをインデックス化できないので、最近のデータだけ。
 上の項目と関連して、特定のサーバだけで全文検索を生成できるかどうか。

3.数十億レコード(2TB)のデータを自宅サーバ一台で満足のいくパフォーマンスが出せるか。
 ノード分割が前提となっていると、自宅サーバやEC2の台数で破産してしまう。

すべてはふぁぼるっくで収益が上がれば解決なのですが、そこまで行ってないのが難点ですね。

7月 16, 2015

通信の最適化について

ここ数日、携帯電話キャリアによる「通信の最適化」の話が広がっています。
わたしの考えとしては、 「キャリアの言い分はわかるが、やり方が不味いので反対」です。

この問題についての議論を追っていくと、大抵泥沼になっています。
いくつかの問題に分けることで整理ができると思います。
それぞれが、別々の問題を指して議論をするので、平行線になってしまうのです。


1.発端となった非可逆圧縮について。
利用者「データが元に戻せないなんて困る」
回線提供者「綺麗な富士山の写真が、とりあえず山の写真だと分かれば何も問題はない」

2.勝手に非可逆圧縮を適用したことについて。
利用者「聞いていない」
回線提供者「店で説明して同意したはず」

3.データの意味を理解して非可逆圧縮を行ったことについて。
利用者「通信の秘密を侵している」
回線提供者「店で説明したから問題ない」


2番と3番については、結局のところ店舗でのサービスが悪いというところにつきるのかと思います。
多くの「聞いていない」という声が上がった時点で、回線提供者は一端通信の最適化を中断し、店舗に対して再度教育を行い、説明を徹底させるべきです。
また聞いていない利用者が多いのなら、再度個別に連絡を取って了解を取り付けるべきかと思います。
「そんなコストは・・・」という声が聞こえてきそうですが、店舗の教育を怠ったツケでしょう。
店舗でキャリアが決めた説明事項をきちんと説明できているか、客のふりをして潜入調査とかしないものなのかな?と思いますが、性善説で動いた方がコストは掛からないですし、疑いたくない気持ちは分かります。しかし通信の最適化に限らず聞こえてくる店舗の契約トラブルを考えると、もうそんなことを言っていられないのではないかと思いました。
誠実な商売をして欲しいものです。

そして1番。
2番と3番で客が承諾した場合に、晴れて1番を実施してよいかと思います。
「富士山の写真が山みたいな形の画像になります」
個人的には嫌ですね。
でも、それでも良いという人もいるでしょう。そういう方は利用すればいいのです。
OperaのOperaTurboとか、Chromeのデータセーバーが同じ機能ですね。
ブラウジングが快適になることで、軽減されるストレスもあるかと思います。

「劣化するのが嫌」という意見に対して「音声も劣化しているのだから良いではないか」という意見をTwitterで見かけましたが、それは比較が違うかと思いました。
「夕焼けに照らされる富士山の綺麗な写真」が「どこかの山がオレンジ色に光っている」状態になるのは、JPEGという画像ファイルの意味を理解して劣化させるわけです。音声通信で特定の周波数をカットするのとは違って、意味を理解して劣化させるのですから、「単身赴任先から子供に電話をしたら桃太郎の話をせがまれて、何度も読んだことのあるお父さんは、暗記したお話を電話口で感情を込めて語った桃太郎の話」が「おばあさんが川で桃を拾ったら子供が出てきて、大きくなって鬼ヶ島へ行って鬼を退治しました」という要約しか子供には聞こえてこないわけです。
意味を理解して非可逆圧縮するというのは、こういうことです。

それを受け入れられる人は使えば良いかと思います。

繰り返しますが、きちんと顧客が了承した場合のみ、実施が可能です。


キャリアの帯域が足りなくなっていることは理解できます。一部の利用者によって、多くのリソースが割かれていることも理解できます。
しかし、それなら定額制などやめて、従量制にすれば良いのです。



そんなわたしは、定額制があったとしてもキャリアのパケット通信価格が高すぎて、MVNOでしかインターネットは使っていません。心情的に非可逆圧縮が嫌なので、キャリアが通信の最適化を続けるなら今後も使うことはないと思います。
MVNOでも実施しだしたら・・・、どこか1社ぐらいは非可逆圧縮を実施しない会社が残るでしょう。
「音声がクリア」 を売り文句にする通信会社があるぐらいですから、「画像が綺麗」を売り文句にする通信会社も出てくるでしょう。

例として挙げた「音声通信の内容を要約して送信」は、ある分野では希望があるかもしれませんね。
いつも同じ話か、話が脱線しまくって本題に進まない人との通話とか(笑)

6月 23, 2015

亀がポイントに挟まったまとめ

何かとよく聞く「亀がポイントに挟まって」。亀がよく出没する駅があるようです。

2015年6月23日更新。
NAVERまとめに置いていたのですが、新聞社によっては、著作権対策からかリンクすらも張れなくなり、リンクアイテムごと消されるようなので、ソースとしての機能も果たせなくなってしまいました。
仕方ないので、自分のブログへ移してリンクを張っておきます。

まずは基礎から

Lightmatter tortoise.jpg
CC BY 1.0, Link

カメ - Wikipedia

甲羅を背負った4本足の爬虫類。童話「浦島太郎」「ウサギとカメ」に出てくることでお馴染み。

Doppelkreuzungsweichen im Rbf München Nord.JPG
PeMoMucによる作品,
CC 表示-継承 4.0, Link

分岐器 - Wikipedia

ポイント(分岐器)はレールをスライドさせ(かなり省略)、列車の行き先を切り替える装置です。
スライドする部分にものが挟まるとレールの切り替えが行えず、列車の運行に支障を来します。


カメによる列車遅延 防止技術を開発 JR西日本・須磨海浜水族園 | 乗りものニュース

最近では対策も増えており、ニュースとなる事象の発生件数も減ってきているようです。

以下一覧

日付場所影響原因ソース
2025/08/04JR紀勢線御坊駅
(和歌山県御坊市)
1本が運休、8本に最大約1時間半の遅れ、約900人に影響カメ種類不明 安否不明読売新聞2025.8.5 カメがレールのポイントに挟まり信号が制御不能に、列車に運休や遅れ
朝日新聞2025.8.5 信号機が切り替わらない…原因はカメ 電車運休や遅れ900人に影響
2025/07/13JR山陰線荘原駅
(島根県出雲市)
2本運休、7本が最大30分遅れ、約500人に影響カメ種類不明 安否不明山陰中央新報2025.7.13 カメ挟まり列車に運休、遅れ JR山陰線
2025/05/05JR成田線久住駅
(千葉県成田市)
上下線3本で最大46分遅れカメ種類不明 死亡読売新聞2025.5.5 JR成田線、カメがポイントに挟まり止まる…近くのゴルフ場から迷い込んだか
2025/04/18JR関西本線永和駅
(愛知県愛西市)
約1時間運転見合わせカメ種類不明 安否不明中日新聞2025.4.18 JR関西本線、名古屋―桑名駅間で一時運転見合わせ ポイントにカメが挟まる
2024/09/13JR奈良線上狛駅
(京都府木津川市)
計6本が運休、計5本が最大約1時間遅れ、約3000人に影響カメ種類不明 死亡毎日新聞2024.9.13 ポイントにカメ挟まる 列車11本が運休・遅延、3000人に影響 JR奈良線
2024/07/06JR紀勢線六軒駅
(三重県松阪市)
上下線で約50分運転を見合わせカメ種類不明体長30cm 死亡産経新聞2024.7.6 原因はカメ…線路のポイントに挟まり、一時運転見合わせ 三重・松阪のJR紀勢線
中日新聞2024.7.6 線路にカメ挟まる、信号変わらず運転見合わせ 紀勢線、津―松阪駅間
2024/06/08JR和歌山線香芝駅
(奈良県香芝市)
一時運転見合わせ、上下計7本が運休、上下5本が最大約1時間50分遅れ、約1800人影響カメ種類不明 安否不明読売新聞2024.6.9 駅構内の信号機が赤のまま、調べてみると線路のポイントにカメ挟まる…2時間近く運転見合わせ
奈良新聞2024.6.9 奈良県香芝市のJR線、カメが原因で信号トラブル 一時運転見合わせ
2021/06/16JR関西線加佐登駅
(三重県鈴鹿市)
一時運転見合わせ、約490人影響カメ種類不明体長15~20cm 死亡共同通信2021.6.16 亀が線路ポイントに挟まる JR関西線に遅れ、三重
2020/09/27JR和歌山線五位堂駅
(奈良県香芝市)
上下4本が運休、3本に最大54分の遅れ、約240人影響カメ種類不明 安否不明共同通信2020.9.27 線路にカメ、JR運転見合わせ 奈良、切り替えポイントに挟まる
2020/08/06JR津山線弓削駅
(岡山県久米南町)
上下7本が最大約30分遅れカメ種類不明体長20cm 安否不明山陽新聞2020.8.6 線路にまたカメが挟まる 津山線で信号トラブル 7本に遅れ
2020/07/20JR瀬戸大橋線備前西市駅
(岡山市南区西市)
上下6本が運休、16本が最大約1時間遅れ、約2500人影響カメ種類不明体長20cm 安否不明山陽新聞2020.7.20 カメ原因 瀬戸大橋線に運休や遅れ 岡山・備前西市駅 分岐器に挟まる
山陽新聞2020.7.20【列車情報】瀬戸大橋線で遅れや運休 信号トラブル ポイント付近にカメ
2020/06/29JR武豊線東浦駅
(愛知県東浦町)
上り電車1本が部分運休、上下計3本が遅れ、約480人影響カメ種類不明 死亡朝日新聞2020.6.29 隙間に入ったカメが止めた 愛知のJR武豊線が一部運休
2020/06/16JR紀勢線高茶屋駅
(三重県津市)
一部運休、50分以上の遅れカメ種類不明 安否不明毎日新聞2020.6.17 線路ポイントに亀はさまり遅延 紀勢線高茶屋駅/三重
2019/06/30JR関西線加佐登駅
(三重県鈴鹿市)
下り2本が最大約45分遅れ、約50人影響体長約20cm、幅約10cmのカメ 死亡朝日新聞2019.6.30 線路にカメ挟まり電車遅延 JR担当者「珍しくはない」
2017/08/11JR関西線永和駅
(愛知県愛西市)
上下各5本が最大42分遅れ
3100人影響
カメ種類不明 安否不明産経新聞2017.8.11 犯人はカメ! JR関西線、ポイントに挟まって列車運休  愛知・永和駅
2015/06/15JR土讃線土佐加茂駅
(高知県佐川町)
5本遅れ
80人影響
カメ種類不明 生存朝日新聞2015.6.17 カメ、列車止める ポイントに挟まれ係員が救出
2014/07/06JR外房線長者町駅
(千葉県いすみ市)
3本遅れ
約500人影響
カメ種類不明体長20cm 死亡千葉日報2014.7.8 「またか…」1年ぶりにカメが挟まる【ちばとぴBuzz】 | ちばとぴ ちばの耳より情報満載 千葉日報ウェブ
千葉日報2014.7.8 ポイントにカメ、運転見合わせ | ちばとぴ ちばの耳より情報満載 千葉日報ウェブ
2013/07/09JR成田線久住駅
(千葉県成田市)
1本以上遅れカメ種類不明体長30cm 死亡千葉日報2013.7.10 線路ポイントにカメ遅れ 挟まれ死ぬ… JR成田線 | ちばとぴ ちばの耳より情報満載 千葉日報ウェブ
2012/10/16名鉄三河線竹村駅構内
(愛知県豊田市)
8本運休
約1500人影響
カメ種類不明 生存時事ドットコム:カメが列車足止め=線路ポイントに挟まる−名鉄
2012/10/14JR紀勢線高茶屋駅構内
(三重県津市)
2本部分運休4本遅れ
500人影響
カメ種類不明30cm 死亡中日新聞:亀が線路に挟まる 津のJR紀勢線:社会(CHUNICHI Web)
2012/08/02JR香椎線酒殿駅
(福岡県粕屋町)
2本運休4本遅れ
500人影響
カメ種類不明15cm 死亡ポイントにカメ、JR香椎線止まる : 最新ニュース特集 : 九州発 : YOMIURI ONLINE(読売新聞)
2012/06/18名鉄三河線竹村駅構内
(愛知県豊田市)
4本運休4本遅れ
1500人影響
カメ種類不明20cm 生存朝日新聞デジタル:カメ、列車4本止める 名鉄三河線、ポイントに挟まる - 社会
2008/07/05JR関西線永和−弥富間
(愛知県弥富市)
2本遅れ
280人影響
カメ種類不明20cm 安否不明2008.7.5 ポイントに亀、特急など遅れ 弥富のJR関西線 【名古屋】
2007/10/12JR長崎線湯江駅
(長崎県諫早市)
2本部分運休3本遅れ
800人影響
カメ種類不明25cm 死亡-
2007/06/27大阪市営地下鉄谷町線八尾南駅
(大阪府八尾市)
20本遅れ
4100人影響
カメ種類不明25cm 死亡-
2007/06/08JR和歌山線五位堂駅構内
(奈良県香芝市)
2本遅れ
600人影響
カメ種類不明 安否不明-
2006/08/30JR奈良線棚倉駅構内
(京都府山城町)
6本運休6本遅れ
3500人影響
カメ種類不明20cm 生存-
2006/07/03JR関西線永和駅構内
(愛知県愛西市)
2本運休6本遅れ
1200人影響
カメ種類不明30cm 死亡2006.7.3 カメに往生 線路上に30センチ大 関西線一時運休 【名古屋】
2006/06/19JR呉線安登駅構内
(広島県呉市)
2本遅れ
60人影響
クサガメ25cm 死亡読売新聞2006.6.21 JR呉線のポイントに亀 ダイヤ乱れる=広島
2004/08/14JR香椎線酒殿駅構内
(福岡県粕屋町)
4本運休
530人影響
カメ種類不明30cm 生存読売新聞2004.8.15 亀が列車止める JR香椎線酒殿駅、信号トラブル=福岡
2003/10/20JR奈良線上狛駅構内
(京都府山城町)
2本運休6本遅れ
1900人影響
カメの種類不明 生存読売新聞2003.10.21 JR奈良線、カメが止める ポイントに挟まり/京都
2003/06/28JR関西本線弥富駅構内
(愛知県弥富市)
2本運休8本遅れ
950人影響
カメ種類不明25cm 死亡2003.6.29 ポイントにカメ、電車8本に遅れ JR関西線弥富駅構内【名古屋】
2002/07/22JR奈良線上狛駅構内
(京都府山城町)
2本運休5本遅れ
2300人影響
カメ種類不明25cm 死亡読売新聞2002.7.23 JRしカメっ面 ポイントに挟まり奈良線遅れる=京都
2002/07/07JR関西線永和駅構内
(愛知県愛西市)
7本遅れ
1100人影響
カメ種類不明24cm 死亡-
2002/05/27JR高徳線オレンジタウン駅構内
(香川県さぬき市)
2本遅れ
550人影響
カメ種類不明20cm 死亡読売新聞2002.5.28 [いずみ]香川のJR高徳線で亀がレールのポイントに挟まり通勤客らの足荒れる
2001/07/24名鉄尾西線日比野駅構内
(愛知県愛西市)
19本運休カメ種類不明 発見時は生存のちに死亡読売新聞2001.7.24 線路が故障? “犯人”は亀 名鉄尾西線、19本が運休【名古屋】
2000/09/08JR和歌山線五位堂信号場
(奈良県香芝市)
10本運休12本遅れ
2300人影響
カメ種類不明25cm 死亡読売新聞2000.9.8 JR和歌山線のポイントに亀 10本運休/奈良・香芝
1999/07/03JR阪和線上野芝駅構内
(大阪府堺市)
6本運休5本遅れ
1750人影響
カメ種類不明 死亡読売新聞1999.7.4 JR阪和線を亀が止める ポイントに挟まり、信号機変わらず/大阪・堺 ほか日経新聞
1999/06/24JR土讃線金蔵寺駅構内
(香川県善通寺市)
4本遅れ
370人影響
カメ種類不明 安否不明読売新聞1999.6.25 善通寺でポイントに亀挟まりJR乱れる 370人に影響=香川
1999/06/05JR武豊線緒川駅構内
(愛知県東浦町)
2本遅れ
700人影響
カメ種類不明20cm 死亡読売新聞1999.6.7 亀、JR武豊線止める 緒川駅のポイントに挟まる/愛知・東浦
1994/07/17JR和歌山線五位堂信号場
(奈良県香芝市)
5本遅れ
350人影響
カメ種類不明20cm 安否不明読売新聞1994.7.18 [おあしす]JR和歌山線五位堂信号場でポイントに亀が挾まり電車遅れる
1991/08/22北近畿タンゴ鉄道宮福線大江駅構内
(京都府加佐郡大江町)
3本運休4本遅れカメ種類不明 安否不明読売新聞1991.8.25 ポイントにカメ隠れんぼ、列車止める

6月 18, 2015

サチコと神ねこ様のリンク

Pouchというサイトで、わこ(@wako3999)さんが連載されている「サチコと神ねこ様」という漫画があるのですが、新しい話から古い話へのリンクは有るのに、古い話から新しい話へのリンクが無いので、第1回から順に読むのが困難2020年ぐらいから次の話へのリンクが付いたようです。
タグ一覧でも新しいもの順ですし、レコメンドで出てくる話もランダムで、番号順に読むのは無理そうです。

なので各話へのリンクを作りました。順に追記します。

最近の更新分(表示されるまで少し時間が掛かります)

最初から










































































































































































































































































広告