D-7 <altijd in beweging>

Day to day life of a Perl/Go/C/C++/whatever hacker. May include anything from tech, food, and family.

カテゴリ:Go

「あ〜、インタプリタ言語飽きた。コンパイルしてぇ」と思っていたところ見つけたGo。あれから4年ほど経ちます。

gophercolor


当初 「mattn さんという超絶変態ハッカーが使ってるなぁ」くらいの印象でした。そして触り始めてからも「なんだこれ、オブジェクトじゃないの…?」「interface {}って… え、あとから自動的に紐尽くの…?」「なにこれ、ポインタレシーバーとby valueレシーバーで意味違うの…?」などなど色々と自ら真っ先に罠にかかり、穴にはまりまくって「この言語大丈夫か」と皆さんもそう思っていたかもしれませんし、僕もそう思っていたことがありました。

その後、自分が罠にはまるごとにあちこちで発表したりもし、pecoという思いがけないヒットを書いてしまったり、とにかく大量のGoコードを書き続けていくうちに…

Go言語は僕にとって既に無くてはならない存在になってしまいました。だって、コード書きやすいし、速いし、良いことづくめなんだもの。

そんなところで「本書くんだけど参加しない?」というお声がかかったのでめいっぱい手を上げて1章書かせてもらいました。それがこのほど予約開始になりました。(書影がまだないのが残念…)


Perlを10何年書いてからのGoで、なるほど、これは… という点は何個かあったのでどれをネタにしようか迷ったのですが、今回僕は"reflect"という黒魔術を採り上げさせてもらいました。

reflect芸人


やはりPerlと来たら黒魔術でしょう。Goでは基本必要のないツールですが、必要になったらこれ以外方法がない、というreflect。いくつかのライブラリを書く際にはまりまくったその結果を共有させてもらったので、是非皆さんには僕のテツを踏まないでいただきたいと思います。

P.S. 今回以下のようなものも描かせてもらいました。どこで使われるかな?



 
    このエントリーをはてなブックマークに追加 mixiチェック

大分迷ってしまったのでメモ。
 
type Foo interface { ... }
type Bar struct {...} // implements Foo
type Quux struct {
    A int
    B string
    C Foo
}

これをjson.Unmarshalでデコードしようと思うとするとQuux.Cをデコードするところで「どうやってGo Valueにするのかわからん!」ってGoに文句言われた。ちなみにgo 1.5
続きを読む
    このエントリーをはてなブックマークに追加 mixiチェック

ちょうど本業のほうでDBへのアクセスが遅い?んだかなんだかでREST APIがタイムアウトしている事象に出会っていたのでよっしゃとgo-sql-proxyを使おうと思ったのだけど、まずこのままだと実行時間とかが計測できない… ということに気づいて色々考えた結果PRを送る事にした。送ったら光速でマージされた。

今度から NewTraceProxyでプロキシを作れば Open/Exec/Queryに関しては所要時間が出力されるようになります。mysqlなら以下のような感じ:

driverName := "mysql"
if traceEnabled {
    driverName = "mysql-trace"
    sql.Register(driverName, proxy.NewTraceProxy(&mysql.MySQLDriver{}, logger))
}
db, err := sql.Open(driverName, dsn)
...

出力はこんな感じ:

tracer_test.go:27: Open (54.116µs)
tracer_test.go:27: Exec: CREATE TABLE t1 (id INTEGER PRIMARY KEY); args = [] (44.535µs)
tracer_test.go:41: Query: SELECT id FROM t1 WHERE id = ?; args = [1] (1.828µs)

わーい、これでボトルネック探すの捗るぞー!… と思っていたら、元々のNewTraceProxyのシグネチャが

func NewTraceProxy(d driver.Driver, o Outputter) *Proxy

で、これだと自前のloggerを受け付けてくれない!
type MyLogger struct { *log.Logger }
とかでも駄目だ!ということでインターフェースを定義してOutputメソッドを実装してればなんでもいいようにしておいたPRを送って取り込んでもらった。これで使えるようになった。YATTA!(けど、デプロイはこれからなのでまだなにか後で追加するかも…)

どちらのPRも光速でマージしてもらって大分たすかった。ありがとうございます。
    このエントリーをはてなブックマークに追加 mixiチェック

godepというツールをpecomigemogrepに便利に使わせてもらってたんだけど、このたびカスタムなgoスクリプト(goだとスクリプトじゃないと言われそうだけど、スクリプトとしか言い様が無い)を書いてgodepを卒業しました。

 なんでこうしたかというとgodepの-copy=falseというオプションが使えなくなり、基本的に依存関係のライブラリもこちらのレポジトリに入れないといけない形になったから。いや、入れても良いけどさ… う〜ん。毎日ビルドして出荷してるわけじゃないし、それなのにレポジトリをcloneした時に依存関係も全部落とすのはなああああ、ということで、もう全部自前で書きました。

別にシェルスクリプトでもよかったんだけど、goのプロジェクトだし…ってことで全部goで書いて、wercker.ymlからこんな感じで呼び出すようにした

それだけ。あとで「なんであんなことしてるの?」って聞かれた時用に書いておく。
    このエントリーをはてなブックマークに追加 mixiチェック

先週 @k0kubunさんがpecoで複数キーの入力シーケンスに対してアクションを起こす(例:C-x, C-cで終了する、みたいなの)PRをしてくれたのでそれをマージした。pecoには楽しいお兄さんが色々コントリビュートしてくれているので、そのPRを見た瞬間にこんなコメントが

おお、いいですね、ということで実装してみようとしたところ… うっ… 設定ファイルから読み込んで動的に作る無名関数からレキシカルな変数へのスイッチングしてて、これをプログラム内部から他に作る方法がねぇ!w 設定ファイルからはできるのに!w むきー!

ということでその後、基本的な設計構造を変えないでその辺りを奇麗にできる方法は ないかと一日くらい費やした。が、やはりうまくいかない。薄々気づいていたけどこれFSMとかの出番だよな… 一から実装面倒くせぇなーと、つぶやいたらすぐ返信が:


うほ!goでahocorasickの実装があるwwww ありがとうございます!全部ぱくります!

コードを眺めているとトップレベルではstringに対しての実装で、 中身はruneに対してノードを返すみたいな事になってるので、これまぁ用はstring = []rune として考えられるので、キーシーケンス= []キー で代用できるね、って分かったのでガツガツ変更。といっても検索キーとか、ちょっと再起的に使うためにinterfaceを足した程度で、基本は何も変えていない。

そんなこんなで最初にpecoを書き始めてから一番大きいPRをマージして、キー入力周りがそれまでのコードと一変した。コードを提示してもらったおかげで任意の長さのキーシーケンスを特定のコマンドを高速かつ分かりやすい形で検索+ディスパッチできるようになった。

これも含めて先ほどpeco v0.2.0としてリリースした。このリリースはかなりの数の変更が入っているので、pecoヘビーユーザーには嬉しい機能が結構あると思う。是非お試し有れ!

本日の教訓:この一つ前の記事もパクリの話だったけど、こういう汎用的な方法論についての助言はどんどん受け入れるべきだし、コードもがんがん再利用してやればいいと思う。

プログラムを書く作業は孤独だけど、わからない事は「分からない!どこから始めるか教えて!」って聞けば誰でもヒントをくれるので人に頼る事を恐れないほうが良い(ただし、そこから先は自己責任でちゃんと勉強しましょうね)。そういえばgo-xslate書いた時もgfxに「これ、どこのサイト読むとxslateで使ってるVMのモデルの概要わかるの?」って聞いたな。

年を取れば取るほど経験値はたまっていくけど、それと同時に自分の知らない事が世界にはまだまだあるのがわかる。もちろんそれらを全部吸収できればベストなんだけど、脳にも限界があるので他人に聞く事によって自分の知らない事を素早く正しく補完できるのであればそれを活用できるようにつながりを作ったり、素直に質問できるようにしていくのが老いてゆくエンジニアの進む正しい道な気がする。おすすめです。
    このエントリーをはてなブックマークに追加 mixiチェック

pecoでは何個か前のリリースからバイナリビルドをリリースの成果物として登録するようにしている。これのおかげでpecoはそもそもの存在理由である「2014年だしこういうツールはバイナリ一個置いておくだけで動いてほしい!」というをより簡単に実現できている。


で、その実装方法。基本motemenさんのスクリプトにmattnさんがツッコミを入れたりしてるのを見ながら「よし!パクろう!」と思ってパクったんだけど、一つだけpecoでは意図的に変えたところがあって、それはboxの選定のところ。

motemenさんのgolang-goxc box自体に基本何も問題がないのだけど、pecoで色々やっているうちにgo1.3がリリースされたのにこのボックスを使っているといつまでもgo1.2.1だった(今はもう違うかもしれない)。まぁ当たり前ですよね。そこは他人の褌で相撲を取ろうとしている俺が文句言うところではない。

ただやっぱりバイナリのサイズが小さくなったり、多少パフォーマンス改善も見られている1.3系を使いたいと思いが募ったのと「これから先もきっとこういう事があるだろうし、そういうことがあるごとに文句を言わないといけないのか?」という思いがあり、pecoにはpeco専用のビルドボックスを作る事にした。それがこちら。もちろんgo1.3とgoxcを入れているところ以外はたいした事してない。

たいしたことはしてないんだけど、よくよく考えればライブラリとかではなくpecoのようにエンドユーザーに直接届くプログラムに関してはあまり自分が制御できていない環境に依存するのもどうかなーと思ったのでもうボックスから作る事にしてしまった。これなら自分がやりたいタイミングでgo1.4が出たらgo1.4にすることもできるし、goxcの特定のバージョンが欲しい、とかにも対応できる。

あとはmotemenさんの元記事と一緒。タグ打ってgit pushすれば勝手にファイルがあがってくる。おっさんは何もする必要がありません。大変すばらしい。また時間のある時にはhomebrewのレシピも自動的に作成しようとは思ってるけどそこまで至っていない。ともあれ、自動化はすばらしい。





ちなみに、drone.ioも一応登録はしてあって、こっちでもリリースとかできるかやってみたんだけど失敗して、ただただコンパイルして成果物を残しているだけ(基本前のやつは上書き)。あんまり必要じゃないけど、別の環境でコンパイルするとたまにバグが見つかったりもするので悪くはないと思ってる。まぁそのうち消すかも。
    このエントリーをはてなブックマークに追加 mixiチェック

tl;dr;
続きを読む
    このエントリーをはてなブックマークに追加 mixiチェック

これは笑ってしまった。The Open Source Report Cardという、githubのデータを持ってきて色々統計情報を見せてくれるサイトがあるんだけど、ここで今日とうとう「Exceptional Regexer」とか、そういうPerl Monger系の名称から「High Caliber Gopher」みたいな名称になって、さらによくみると「one of the 5% most active Go users」(6/18現在)だったのでツイートしたら、
GoプロジェクトにとてもゆかりのあるDave Cheneyさんからこんなツイートが…

よくみると彼は上位9%という位置だったw まぁGithubに対するコミット数とかだからそれ以外のところはカウントされないのでしょうがないw 彼がgithubにもっとコミットするようになったら一瞬で抜かされるだろうなー こういうのを"15 minutes of fame"とかいいますねw
    このエントリーをはてなブックマークに追加 mixiチェック

pecoそのものについてはここで読むよりREADMEを見た方が早いです

今月の初めくらいにpercolという便利なものがあるという話を聞き、「ほう、使おうかな」と思ったら普段あまり使い慣れていないpython製ツールでまるでcpanmを使うのがいやなPerlに慣れていない人のような反応で「まぁ必須アイテムじゃないし…」と思って諦めかけたところ


とか言われ「そこまでいいツールなのかなー」と思ったけど、使ったことないし、まずはツールがどういうものなのかをわかるためにGoで実装する事にした(はい、本当にこういう順番です)。
続きを読む
    このエントリーをはてなブックマークに追加 mixiチェック

(以下はgo 1.2.x時点での話です。将来的に仕様がかわるかどうかはわかりません)

これを読んでいて、こういうの気にしてない人多いんだろうなーと思って、書いてみます。元のポストはdeferの挙動について語っているように見受けられるけれども、これは要は複数スレッドで実行されるコードについて、プログラム終了時に同期とか取りたくない、という話だと思ったので、このポストのdeferを正しく動かすには…というところからどういう形でgoroutine同士で同期を取る方法があるのか、一例を書き出していきます。

TL;DR;

goでいくらgoroutineが気軽にかけるからと言って、複数スレッドで処理が行われているので同期はキチンとやらないとダメですよ。

続きを読む
    このエントリーをはてなブックマークに追加 mixiチェック

なんかごく一部に補足されているので、念のため軽く説明しておきます。


これ、ベストな方法だとは思っていないんだけど、最初にこれを書いた当時の考え方は以下の通り:

  1. これは自分の部署で初めて 本番に設置するgoアプリである
  2. 一次対応をする人は自分とは限らない
  3. 細かいコード内容の修正はともかく、明らかなバグっぽいものの修正(例:SQL文の変更)などを自分以外の人間が施した後にサーバーを簡単に再コンパイル+再起動するする方法がないと椅子が降ってくる事が容易に予想される
というところから、どうするのがベストか考えたのがきっかけ。以下、やった事の詳細。

続きを読む
    このエントリーをはてなブックマークに追加 mixiチェック

tl;dr: 別にPerl捨ててないです。Perl大好き。俺はLLはPerlでいい。でも別ドメインの事もやってもいいよね!

Rebuild.fmに限らず、公の場でYAPC/Perl以外の話をする事があるとは正直思っていなかったが、このたびRebuild.fm ep 42に置いて1時間Goについてしゃべりまくってきた。1時間ぶっつけ本番でしゃべりたい事はだいたいしゃべってきたのだけど、その後のフィードバック等もふまえてまとめておきたいと思ったのでこのエントリでまとめてみます

続きを読む
    このエントリーをはてなブックマークに追加 mixiチェック

このところ情熱を燃やしていた go-xslate プロジェクトですが、大分使えるようになってきたしかなりの処理速度も出るようになったしgo-nutsで宣伝もしたし、小さいプロジェクトで使い始めたし・・・ってことで 手軽に遊べる用に Go PlaygroundをぱくってGo-Xslate Playgroundってのを書いた。

外部テンプレートを使うWRAPPERやINCLUDEは使えないけど、それ以外の機能は一通り使えるはず。是非遊んでみて、問題がありそうだったら "Share"ボタンを押してpermalinkを作成の上、permalinkをissueにはりつけて教えてください。よろしくお願いいたします。

ちなみに書いたそばから mattnさんにぱくられたけど、自分もぱくってるし、ぱくられたのは良い物を書いたからなのでつまり全体的に大変よい。なおGo-Xslate Playground自体のソースはこちらにあります。なにか問題等ありましたら教えてくださいませ。
    このエントリーをはてなブックマークに追加 mixiチェック

golangでNgram処理をするためにgo-ngramを書きました。ngramによる類似文字列検索に関してはコードを読みながら逆算してこういうことか、という書き方をしたのでちょっと実装に自信はないのですが、まぁだいたい動くな、というところまでは確認しました。問題がありそうでしたら是非ご連絡ください。

使い方は以下の通り。まずただngramでトークナイズするならngram.NewTokenize()を使います。以下はいわゆるTrigramを使った例:

import (
"fmt"
"github.com/lestrrat/go-ngram"
)
func main() {
tok := ngram.NewTokenize(3, "ハローハローハロー") for _, token := range tok.Tokens() {
fmt.Printf("token = %s\n", token)
}

ちゃんと日本語も対応してます。

ユニークなトークンだけがほしい場合はTokenSet()を使ってください。
import (
"fmt"
"github.com/lestrrat/go-ngram"
)

func main () {
tok := ngram.NewTokenize(3, "ハローハローハロー")
set := tok.TokenSet() // see http://github.com/dackarep/golang-set
for x := range set.Iter() {
fmt.Printf("token = %s\n", x)
}
}

一応簡単なインメモリインデックスも作りました

import (
"fmt"
"github.com/lestrrat/go-ngram"
)

func main() {
index := ngram.NewIndex(3)
index.AddString(`....`) // 検索対象の文字列を登録しておく
....
matches := index.FindSimilarStrings(`ハロー`) // AddString()された物の中から`ハロー`に似ている文字列を持ってくる
for _, str := range matches {
fmt.Printf("matched %s\n", str)
}
}

これで登録されている文字列の中から似た単語を抽出できます。 デフォルト設定だと一個でもngramがマッチするとあたってしまいますが、SetMinScore()で閾値を設定することによって検索結果を絞り込めます。

さらに、一番良いマッチだけを持ってくる場合にはFindBestMatch()を使ってください。

あと自分で検索結果をフィルターする場合はIterateSimilar()を見てください。

ツッコミ、コメントお待ちしております。
    このエントリーをはてなブックマークに追加 mixiチェック

GrowthForecast のgolang用クライアントライブラリgo-growthforecast-clientを書きました。以上!
    このエントリーをはてなブックマークに追加 mixiチェック

goで書いたwebappでもApache形式のログを出したい!ということでgo-apache-logformatを書きました。

最初はこのツールを使って毎回ServeHTTP()関数の中でログを出力する関数を呼び出すようにしようと思ったんだけど簡単なラッパーを用意したので多分かなり簡単にApacheログを出力できるようになるはず

まず最初にやらないといけないのがApacheLog構造体を作るところ。出力先のio.Writerと出力フォーマットを指定して作成するんだけど、いわゆるcombined logフォーマットだったらもうすでに作ってあるので、それをClone()しちゃえば簡単:

import (
"github.com/lestrrat/go-apache-logformat"
)

....
logger := apachelog.CombinedLog.Clone()
logger.SetOutput(...) // io.Writer. os.FileとかでもOK. デフォルトはos.Stderr

で、あとはそれをhttp.HandlerFuncで使用されるようにすればいい。もしServeHTTP()関数を実装した構造体があればそれをラップするだけでもOK:

http.ListenAndServe(":8080", apachelog.WrapLoggingWriter(handler.ServeHTTP, logger)

もし色々自分でやりたいなら、ServeHTTP関数の中で自分で以下のようにフックしてもいい:

func ServeHTTP(w http.ResponseWriter, r *http.Request) {
...
lw := apachelog.NewLoggingWriter(w, r, logger)
defer lw.EmitLog() ...
}

ここでひとつ気をつけないといけないのが、上記のServeHTTPの中ではw ではなく lw (LoggingWriter)のほうを使う事。そうしないと諸々必要な値が取れない。

最後にもしこれをログファイルにはき出しつつローテーションも行いたいならgo-file-rotatelogsを最初のloggerにかませばそれでおしまい:

import (
"github.com/lestrrat/go-file-rotatelogs"
"github.com/lestrrat/go-apache-logformat"
) ...
logfile := rotatelogs.NewRotateLogs("/path/to/accesslog.%Y%m%d")
logfile.LinkName = "/path/to/accesslog" logger := apachelog.CombinedLog.Clone()
logger.SetOutput(logfile)

というわけで是非お試しください。ツッコミ、PR、お待ちしております
    このエントリーをはてなブックマークに追加 mixiチェック

Yet another Yak-shaving... 

というわけで、Perl5のFile::RotateLogsgoにさくっとポートしました。使い方はREADMEのままです!

これでちょちょっと書けばgoアプリでも勝手にログファイルがローテートされるようになります!
    このエントリーをはてなブックマークに追加 mixiチェック

本日のYak Shavinggo-test-mysqldを書いた。

import (
    "database/sql"
    "log"
    "mysqltest"
)

mysqld, err := mysqltest.NewMysqld(nil)
if err != nil {
   log.Fatalf("Failed to start mysqld: %s", err)
}
defer mysqld.Stop()

db, err := sql.Open("mysql", mysqld.Datasource("test", "", "", 0))
// Now use db, which is connected to a mysql db


go-stf-serverのテストを書き始めるにあたってmysqldをどうしても立ち上げないといけないんだけど、これがまた自動的にやるのは面倒くさくて面倒くさくて・・・

というわけでTest::mysqldからまるまるまるっとぱくってgolangにポートしました。これでmysqldを立ち上げるのも簡単だね!

それほど障壁は高くないと思いますので、是非気軽にお使いください。問題があった場合はissueをお気軽にどうぞ! 
    このエントリーをはてなブックマークに追加 mixiチェック

Perl版のSTFは自分が参加し始める前から、ひとつのスクリプトから複数の種類のワーカープロセスを立ち上げるように作られていたのでそれを踏襲し続けている。ひとつにはワーカーの種類が複数あるのでそれらをひとつひとつ立ち上げるのは結構面倒くさいのと、Perl版のバージョン2.00からはメインプロセスがシステム全体のワーカー数を関しつつ自分がどのワーカーを何個ずつ立ち上げるべきなのかを自律的に計算するようにしたのでこれはこれでよい。

さて、それでgo版だが、goでは言語設計的にfork()は使えないようになっている。なので通常はgoroutineをガツガツ立ち上げる事になるわけだが、この間やったgo版dispatcherのベンチマークなどから見ても、goroutineベースだとシステムリソースをよりガツガツ最後の1%まで使ってやろう感が見えるので、本能的に「これをSTFワーカーでやると問題が起こった時にやばい」と感じた。

正直ここは勘なので これが正解かどうかわかってない。間違ってるかもしれないけど全部goroutineでやるより、fork + exec とgoroutineの組み合わせで実装するほうがよいような気がしたので、それでやってみた。

スーパーデーモンにあたるものが"drone"と呼ばれる。こいつは必要なワーカー種類の分のコマンドをexec.Command経由で立ち上げる。しかしこの子プロセスがなんらかの理由で停止したら、即座に新しいプロセスを立ち上げ直す必要がある。ところがgolangにはノンブロッキングwaitpid()に相当するようなものはない。いや、厳密にはあるんだけど、syscall.Wait4()というポータブルではないところにあるのであった。

まぁそもそもfork+waitというのがUNIXなイディオムだからそりゃそうだ。ということでポータブルにするにはどうするか。ここはなんとなく無駄にも思えるのだけど、goroutineで豪勢にブロックするとよい:

func SpawnWorker(exitChan chan string, executable string) {
fullpath, err := exec.LookPath(executable)
...
cmd := exec.Command(fullpath, ...)
err := cmd.Start()
...
go func() {
cmd.Wait()
exitChan <- executable
}()
}
exitChanは別のところでselect{}経由でノンブロッキングで監視しておいて、もらった実行ファイル名で再度子プロセスをスタートさせる関数にフックしておく

func MainLoop() {
for {
select {
case executable := <-exitChan:
SpawnWorker(exitChan, executable)
...
}
}
}

これで永久機関のできあがりだ!あとはSTDOUT/STDERRをコピーしつつシグナルを受け取ったら良い感じにループを抜けたり、後にゾンビを残さないためにプロセスを止めたりすれば停止もキレイになる。

で、この子プロセスの中では特定のワーカー種別について必要な分だけのgoroutineをばかばか作って、必要な処理をする。方式はだいたいdroneと一緒でこちらではQ4Mにアタッチするgoroutineと、さらにそこからchannel経由でジョブをもらって実際の処理を行う複数のgoroutineを作成する。これがようやくいわゆるワーカーの部分。ここもそうする意味があるのかちゃんとわかってないけど、勘でそうするべきだと思ってmax-reqs-per-workerを設定して、定期的にgoroutineが終了するようにしてる


このマルチプロセス+マルチスレッド方式のほうがいいな、と思った理由はこれだと例えば特定のワーカーのgoroutineが詰まったりした時にそのプロセスだけ殺して再起動できるから。goroutineってthread idに対応するものが外部に出てないからkillしたくても簡単にできねぇんだよね!

で、ここまでできたので、次は残りのワーカー機能の作成と、自律的にワーカー数の調整を行う部分。自律調整の部分は上記のdrone部分でtime.Tickを使って定期的に行う予定。
 

と、ここまで書いたけど、この実装って本当に正しいのかわからんので相変わらずツッコミをお待ちしております。
    このエントリーをはてなブックマークに追加 mixiチェック

色々調べてたらgo でHTTPサーバーをgraceful restartする方法の記事にあたって、そのなかでシグナルを受け取るとリクエストを受け取ったらそれまでに受け付けたリクエストを処理してから停止するmannersというツールを見つけた。さらにゼロダウンタイムでサーバーを再起動するgoagainというツールも見つけたんだけど、これはサーバー内のコードをそれなりに変更しないといけないっぽくてうんざりしてしまった。

「っていうか普通にServer::Starterをかませるようにできればよくね?」と思ったので、go-server-starter-listenerを書いてみた!使い方はREADMEにあるとおり。このようなコードを書いておいてからstart_server --port XXX -- ./your-go-program って感じで動作させればServer::Starterが保持してるポートにバインドする・・・はず!(まだあんまりテストしてない)

あとはmannersとあわせれば良い感じでgraceful, zero-downtime restartができるはずー

ツッコミ歓迎です。 
    このエントリーをはてなブックマークに追加 mixiチェック

このページのトップヘ