はてなキーワード: シグネチャとは
プログラミングとは、勉強も運動もスマブラも下手なクソ隠キャ中学生が「俺もパソコン1台で凄い技術者になって…!」とワクワクしながら始めるものの思ったより普通に難しいし学校の試験で出たような知識要求されるしで3日で放り投げ、10数年後にnoteで「お前らは絶望的にプログラミングに向いてないからやめろ」なんて記事を書くだけのザコに成り下がる、夢と希望に溢れた技術である。
近年ではパソコンのスペックの上昇にともないできることも増え、どこのご家庭にもあるRTX2080で簡単にディープラーニングもできるようになった。Unityで3Dゲームをバリバリ動かしてもブルースクリーンは出ない。やっぱ世界を広げるのは小賢しい知恵よりもスペックの暴力だぜ。
開発環境や言語も選択肢豊富で、エディタもかつては有料クラスでも手に入らなかったような贅沢な機能が満載のものが出回っている。Eclipseとか今考えるとよくあんなので開発できてたな。
いまや小学生からおばあちゃんまでアプリ作りに熱中し、高校生はIoTとかやり始め、大学生は商業レベルか?ってレベルのものをネットで発表し、私はウェブアプリのスマホでのレイアウト崩れひとつすら直せず静かにエディタを閉じてnoteで過激タイトル記事を書いている。
掛け算に順序があると思っているような知能の下級雑用係(自分のことを教育専門職だと思い込んでいる)ですら「小学生にプログラミングを教えるぞ!」と意気込んでいる。やめろ。お前らには無理だ。無理だからマジでやめろ。考え直せ。無理だって。掛け算に順序つけないと相手に教えられないレベルのやつがプログラミング教えるのマジで無理だって。算数とは次元が違うって。「ピーチ姫いつも簡単に誘拐できるし今度はベヨネッタも誘拐してみるか」ぐらいの無謀さだって。やめとけ。マジでやめろ。
まあそんなこんなで入り口はめちゃくちゃ広く、入門するのはマリオカートより簡単である。話逸れるけどSwitchのマリオカート、運転アシスト機能ついて初心者でもコース完走できるようになったから心折れちゃった人ももう一度チャレンジしてみてね。
それとは特に関係ないんだけど、大学行ってた時ティーチングアシスタント(TA)っていう授業のお手伝いさせられたのよね。ちゃんとお金出るやつ。
学部の3年か4年から始まって、院の1年か2年までやってて、途中で休学挟んだから、ええと、あー、うん、数年間TAやってたんよ。数学とプログラミングのコマ。CとOctaveとかいうやつ。Cのほうは情報学科で、Octaveは違う学科。JavaとかC++のコマはTA入れさせてもらえなかった。
プログラミングの実習は週2コマ(連続)あって、情報学科なら必修科目。なのでサポートは相当手厚く、先生とTAが絶え間なく机間巡視し、わからないことがあればセンパイがなんでも答えてくれるというわけだ。授業外でもサポートはしており、わからなければ先生や研究室にいる学生に好きなだけ聞きにいっても良いということになっていた。必修だから落とされたら困るしな。
2コマだから3時間 * 15回で、45時間。そして私の時は2年まででC/C++/Javaと必修だった(今はなんの言語かは知らない)ので、その3倍、135時間は最低やることになる。プログラミング実習以外にもプログラミング触る授業多いから実際はもっと多い。宿題やる時間もあるので実際はもっともっと長くプログラミングに触れることになる。卒論書く時期に入ると、テーマによっては書く人はさらに書くので、もっともっともっともっと長い。
これだけ時間をかければほとんどの人がプログラミングできるように……ならない。むしろできない人の方が多い。なんで。why。教えて。
会社になるとさすがにプログラミングできるできないは死活問題である。
「今日から入ったxxでーす。業界未経験ですがよろしくおねがしまーす。さっそくなんですけどPythonのここわかんないんですけどどうすれば……あっそうすればいいんですね。次はここなんですけど……なるほど!ありがとうございます。じゃあまた明日ー」
いやー社会人にもなると熱意が違うね。学生なんかわかんなくてもほとんど聞きに来ないのにな。こりゃガンガン伸びますわ。私も社会人1年生でPythonなんて3秒ぐらいしか触ったことないから適当答えてるけど。
「ちょっとお時間よろしいですか?」「いやちょっと今忙しいから後になっちゃいますわ。すんません……」
そんなこんなで1週間ぐらい放置してしまった。やべー絶対嫌われる。どこまで進んだかな……?えっまだそこ?進んでなくない?
もしかしてこれ全部教えないとダメなやつか。そりゃ大学4年間プログラミングやったやつでもプログラミングできないんだから、そうか。よく考えると当たり前だよな。
プログラミングをやめろ
大学4年間と大学院2年間プログラミングやったやつでもできないし、会社で毎日8時間を数週間プログラミングについやしてもできないやつはできないし、そもそも人類というのはプログラミングできない可能性がある。
少年少女たちに「プログラミングはいいぞ!自由にものが作れて達成感がある!頭が良くなった気分にもなれるし!」と吹聴してまわんのもいいけど、6年間情報科学について勉強したようなやつの大半がプログラミングできないんですよ。それもごくごく初歩的な部分。
野球とかサッカーなら、まあ友達との試合には参加できなくてもごく稀にバットにボールを当てたり、ボールを1回あらぬ方向に蹴ったり、ぶっちゃけ周りとのレベル差で楽しくなくてすぐやめちゃうだろうけど、なんとか基礎の一部ぐらいはできるじゃないですか。
ピアノとかダンスでも、猫踏んじゃったをごくごくゆっくり弾くぐらいはできるかもしんないし、学芸会の振り付けを10秒ぐらいは踊れたりできるかもしれない。その後やっぱ周りのレベル見て諦めちゃうかもしんないけどさ。
プログラミング、6年やってミットを頭にかぶってるバッターとか、鍵盤蓋の上から殴って音鳴らそうとするやつとか、まずそういうレベルのやつが大量発生するんですよ。だいたい7割ぐらいの率。どうすんだよこいつら。私の教育の問題か?マジで?本当に?
プロが練って考えて凝縮した本や授業、センパイたちによる指導。それらを結集して得られるはずのものが7割ぐらいどっかに消し飛んでる。無駄だろこれ。
今からプログラミングやろうとしてるやつ、お前は確実に向いてないからさっさと諦めて刺身にタンポポ乗せる仕事に戻ってくれ。参加しても鍵盤蓋叩き割るやつと同じ病室に入るだけだ。
プログラミングをやめろ。
ぼくはこう思うんですよ
そもそもなんで大の大人がそんな両手にバット持ってセカンドに立ったりゴールの方をボールのところまで動かす奇行に走るんだろうな。わかんねえや。
綺麗な分析はできないけど、いわゆる「できない」やつが共通して言ってたフレーズがある。
「ぼくはxxxだと思ってるんですけど、動かないんですよ」
うん、そうだね。そう思うんだ。でも動いてないじゃん。じゃあ違うんじゃない?モニターに「にらみつける」やってもバグは取れないし防御力下がるだけだぞ。
まず根本的に考えと事実が違ってるって結果出てるじゃん。じゃあもう考え変えちゃえば早くない?
名言の引用は好きではないけど、「プログラムは思った通りには動かない。書いた通りに動く」って言葉がある。実に名言だと思う。次点で好きなのが「ある問題を解決しようと正規表現を使うと問題が2つに増える」かな。
お前が何を思っているかはプログラミングにおいて一切影響しないんだよ。お前が何を書いて、コンピュータがどう処理したか、それが全て。
深く考えないことについてぎゃーぎゃーいうやつもいるけどプログラムなんてまず最初は動けばいいんだから何も考えずに次試せばいいだろ。んで3回ぐらいは自分で思い浮かんだの試して、全部ダメだったら調べるとか先生に聞いてみるとかさ。逆に1発で通ったら自分の思考見直して理解深めるとかさ。
ドキュメントとかあんまり理解できない初心者のうちは、とにかくお試しと修正のサイクル回すの重要で、「これがこうだから動くはず」というカードを3種類ぐらい作って全部片っ端から試すのが早いと思うよ。モニターをにらみつけるな。
お前がどう思ってるかよりも、まずはお前の書いたプログラムがどう動いているか(どう動いていないか)を確認するのが先だ。動かなかったら考えが違う、はい次のプラン、はいその次のプラン、はい次。
この「ぼくはこう思ってる」が出てくるの、なんの教育の成果なんだろうね。お前の気持ちなんてどうでもいいって現国でも数学で散々教えられただろ。
Error: variable 'a' is undefined, line 24
↑のエラーは架空のエラー文(英語下手でも許して)だけど、エラー、出るよね。プログラム組んでたら。んでやっぱいるのよ。エラーを「にらみつける」やつ。解決しねえって言ってんだろ。
「エラー出たんですけど、どうすればいいんですか」
「エラーにはプログラムがなぜコンパイル通らないかの原因がそのまま書かれている。例えば今出ているError: variable 'a' is undefined, line 24は、24行目の変数aが未定義ということを示している。事前に変数aを定義していないか、打ち間違えてsになっているとかではないのかな?」
だいたいが「腑に落ちねぇー」みたいな顔する。まあ、一気に喋りすぎたしな。疑問点1個1個潰していくか。
「何か疑問点ありそう?変数ってなにー、とか、定義ってなにー、とか」「ないです。わかりました!」
わかったのか。よかった。またモニターをにらみつける開始。なんでだよ!!!!「お前顔にチョコついてるぞ」って言われたらチョコ拭き取るだろ。変数aが未定義ですねって言われたら変数a定義すりゃいいだろ。
でもプログラミングド下手なやつ(全人類の7割ぐらい)は、エラーをにらみつけてる。ずっとにらみつけてる。防御力下限まで下がったかな。にらみつけてて何が変わるんだよ。
「英語読めなくて……」
いや「a is undefined」なんて「He is Superman」ぐらいの英語だろなんで読めないんだよ。お前この大学どうやって入ったんだよ。たしかどの入試方式でも英語あっただろ。単語わからんかったらググれ。
「aが未定義って書いてあるんですけど、ここのfor文の私の考えが間違ってるのでしょうか」
いや24行目のaって書いてるだろ。まずなんでそこ無視するんだよ。お前がfor文で使ってんの教科書通りのiだろ。24行目ってわかるか?for文あるの40行目あたりだよな?aとiが違う文字ってわかるか?
「さっきのエラー直したら新しいエラーが出たんですけど、どうすればいいですか」
千尋!贅沢な名だねえ
変数に名前をつけろ。関数に名前をつけろ。クラスに名前をつけろ。全てに名前をつけろ。
C言語の古い教科書だと「a」とか「b」とか「i」とかで書いてるけど、そんなの人間が読めるわけねえだろ。冷静に考えろ。「input」「output」「index」とかにしとけ。
2重for文の変数名i, jにしたら絶対途中で打ち間違えるだろ。お前は打ち間違える。そういうやつだ。2重ループなんてどうせ行列計算の課題だろ。rowとcolumnにしとけ。これで打ち間違っても気づくし、それぞれに意味が付いてくる。
ちなみに同じ長い名前にも優劣がある。「result」よりも「sum」のほうが強い。「result」はなんの結果かわからない(全ては結果であるので)が「sum」は合計値であることがわかるからだ。「password」と「plainPassword」なら「plainPassword」が勝つ。暗号化されていないパスワードであることがわかるので、情報量が多いからだ。
ただし例外はいくつかある。「tmp」は一時変数であることが(プログラマにとって)明らかだ。「dir」はディレクトリであることがわかる。「src」「dist」あたりもよく使われる。このあたりは短くていいんじゃねーかな。
でも、この前温度センサ扱うプロジェクトで「tmp」って変数名使って温度(temperature)と脳内で混線してバグって発狂してた同僚いたけど。そういうときは名前長くするか別の名前使おうな。
関数の名前なんて「calcAverageFromArray」ぐらい長くしていいから。「myFunc」とかしなくていいから。「fetchJsonDataFromUniversityInternalServer」とかでいいから。マジで。いやこれ本当に。
そもそも今時ディスプレイでかいし、識別子なんて先頭数文字打ったらエディタが補完してくれるし、短くするメリットがない。
それでも名前が長いと感じる?関数がでかすぎるんじゃないか。細かく処理を分けるとかしてみろ。「combineArrayAndFindMax」関数は「combineArray」と「findMax」に分割したらいいと思うぞ。名前が長いと思っても名前を削るな、機能を分割しろ。自然と名前が短くなる。
それかシンプルでかっこいい名前を見つける。「convertEvilHtmlToPeacefulText」は「sanitize」に置き換えることができる。イカす名前だ。
プログラミングできない奴はマジでこれらのことをやらない。ずっとaとかbとかzとか使ってる。お前それ自分で読めんのか。読めねえだろ。myfuncってなんだよ何するんだよ。お前自分で理解できてんのかそれ。
それでも頑なにaとかbとか使う。なんでだよ。
動作原理わからず書き散らすな。動作原理っつってもそんな深いところじゃなくて言語表面上レベルの動作な。
リテラルは値を作成して、代入は値に名前をつけている、とかその程度のレイヤー。メモリがどうこうとかはいらんと思う。あっでもポインタのときはいるか……。めんどくせえな。
まあ動作原理っていうか自分が何やってんのか理解してくれって程度の話になるんだが。
例えばfor文で処理50回まわすとき、「50回分の処理を行なっている」ではなく「ループ開始時に変数を初期化。条件判定して成立していれば文の中を実行する。条件変数の値を変化させてまた条件判定からやり直す」ぐらいの粒度で捉えててほしいかな、という気持ち。
これはfor文で詰まる人がやたら多かったからだ。彼らはfor文をアトミックな操作だと思っていた。つまりfor文はひとまとまりの命令であり、長いfor文とprintfの間に粒度の違いはないと思っていたらしい。
つまり、「for文の中でエラーが起こる」という事象がほぼ理解できない。forはアトミックであり、内部など見えないのだから。じゃあお前が今書いたfor文の中身はなんなんだってやんわり聞くと「さあ…?」みたいな反応が返ってくる。はあ。
関数についてもなかなか誤解が多かった。関数「sum_array(a, b)」と関数「average_three_numbers(a, b, c)」は全く別の原理で動いているのだと。ここでの「全く別の原理」というのはシグネチャが違うとか実装が異なるとかそういう意味ではなく、コーラを飲んでゲップが出る原理と糸電話で声が伝わる原理ぐらいの全くの別、という意味である。
彼らは関数ひとつひとつについて「新しく原理を学習」していたのだ。マジかよ……。どうやったらそんな発想に行き着くんだろう。そりゃ時間かかるわな。
そのため、関数が値を返す(または返さない)ということも理解できておらず、「関数の戻り値と関数の戻り値を足す」とか「関数の引数に関数の戻り値を直接渡す」とかやりだすと大パニックになる。メソッドチェーンとかやった日には大学潰れると思う。ただ、これはC言語が悪い部分もあると思う。配列とかいじりだすと、初心者が書けるレベルの関数だとあんまり値返さないしな。
たのむ、他のはできなくてもこれはできてほしい。自分が何をやりたいのかは理解してほしい。流石にお前のやりたいことなんて他人にはわからんぞ。
「配列の中の数値の合計値を求めたいんです」とか「名前と身長と体重をひとつにまとめた構造体が作りたいんです」とか。簡単なのでいいから。
「いま何やろうとしてどこで詰まってる?」って聞いても「……?」みたいな反応されたら困るんだよ。
例えば「キーボードから数値を10回入力し、それぞれの値を配列に格納して、最後に配列の値を逆順に表示せよ」みたいな問題が出てきたときに、「キーボードから値を入力する」「10回繰り返す」「配列に値を格納する」「配列の値を逆順に表示する」に分解できると思うんだけど、自分が何やりたいのかわからない奴はまずこれができない。
彼らには「キーボードカラスウチヲジュッカイニュウリョクシソレゾレヲハイレツニニュウリョクシテサイゴニハイレツノアタイヲギャクジュンニヒョウジセヨ」に見えている。
かろうじて「キーボード」「ハイレツ」あたりの単語は拾えるらしく、標準入力から値とったり配列を作ったりはしてるんだけど、そこから先に進まない。モニターにらみつけてる。またにらみつけるかよ。
あれだ、算数の文章題できなくてとにかく文章に出てくる数値足したり引いたりするやつ。あれのプログラミング版。文章が読めない。
こういう人にはメモ用紙取り出して、まず文章が何について言ってるのか、どういう工程に分けることができるのか、今後も同じことが起こったときにどうやって分けるのか。みたいなのを教えるんだけど、大抵あんまりしっくりこないらしく、成功したことは皆無。なんとかうまく教えたいんだが。
もうこのあたりになってくるとプログラミング関係なくね……?ってなるんだけど、意外とそういうプログラミング関係ないところで詰まる人めちゃくちゃ多いよ。
今すぐプログラミングをやめろ
いいえ、関数の引数が多すぎる(「Too Many Arguments」)問題の解決策としてConfigクラス(またはパラメーターオブジェクト)を使用すること自体は、一般的にアンチパターンとは見なされていません。
関数の引数が多すぎる状態は「コードの臭い(Code Smell)」の一つとされており、Configクラスなどの単一のオブジェクトに引数をまとめることは、その問題を軽減するための一般的な解決策です。
| メリット | 説明 |
| 可読性の向上 | 長い引数リストはコードを読みにくくしますが、関連する引数を一つのオブジェクトにまとめることで、関数シグネチャ(定義)が簡潔になり、何を受け取っているのかが明確になります。 |
| 引数の順序間違いの防止 | 位置引数が多いと、呼び出し側で引数の順番を間違えるリスクが高まります。オブジェクトとして渡せば、プロパティ名でアクセスするため、この種のエラーを防げます。 |
| 変更容易性の向上 | 新しい引数が必要になった場合、関数のシグネチャを直接変更する代わりに、Configクラスに新しいプロパティを追加するだけで済みます。これにより、関数の呼び出し元すべてを変更する必要がなくなり、マージの競合も減らせます。 |
| 引数のグループ化・関連付け | 論理的に関連する引数(例:`name`, `lastname`, `city`, `country` → `Address` オブジェクト)をまとめることで、その意図やコンテキストが明確になります。 |
このような引数をまとめるためのオブジェクトは、Data Transfer Object (DTO) やParameter Objectとも呼ばれます。
Configクラス自体が問題なのではなく、そのクラスの使用方法や、そもそも引数が多いという事実がより深い設計上の問題を示している場合があります。
引数が多い関数は、しばしば単一責任の原則(Single Responsibility Principle / SRP)に違反している大きなクラス(Large Class)や長いメソッド(Long Method)の兆候であることがあります。
Configクラスを作っても、根本的な問題は解決しない: 引数をクラスにまとめただけで、関数やクラスが多くの異なる責任を持ちすぎているという根本的な問題は解決しません。
対処法: この場合、Configクラスを作成する前に、関数が実行している処理をより小さな責任を持つ複数の関数やクラスに分割することを検討すべきです。
Configクラス自体が、もはや数十のフィールドを持つ巨大な「すべてを持つクラス」になってしまっている場合、それは設計上の問題です。
対処法: その巨大なConfigクラスのフィールドを、論理的なサブグループ(例: `DatabaseConfig`, `NetworkConfig`, `LoggingConfig`など)に分割することを検討します。
引数が数個(例: 2~3個)しかない関数に対して、引数をまとめるためだけにConfigクラスを作成すると、不必要なオーバーヘッドと複雑さが増すだけで、メリットが薄い場合があります。
対処法:Configクラスの使用は、引数の数が多すぎて(一般的に5個以上が目安とされることが多い)管理が難しくなった場合に限定するのが賢明です。
結論として、関数の引数が多すぎる問題をConfigクラスで解決するのは、有効な設計パターンです。
ただし、その解決策を適用する前に、「なぜこの関数はこんなに多くの情報が必要なのか?」と自問し、それがより大きな設計上の問題(SRP違反など)の単なる症状ではないかを確認することが、クリーンなコードを書く上で最も重要です。
睡眠欲求はミトコンドリアの機能と好気性代謝に深く関連していることが示唆されています [1-3]。
* 研究者たちは、**休息状態と睡眠不足状態のハエの脳から単一細胞のトランスクリプトームを解析**しました [1, 4]。
* その結果、睡眠を誘導・維持する役割を持つ**背側扇状体投射ニューロン(dFBNs)**において、睡眠不足後に発現が上昇する転写産物のほとんどが、**ミトコンドリア呼吸とATP合成に関わるタンパク質をコードしている**ことが明らかになりました [1, 5]。
* 対照的に、シナプス集合やシナプス小胞放出に関わる遺伝子産物は選択的にダウンレギュレーションされていました [5]。
* このトランスクリプトームの「睡眠喪失シグネチャー」はdFBNsに特有のものであり、他の脳細胞集団では検出されませんでした [5]。
* 睡眠不足は、dFBNsのミトコンドリアの**断片化、サイズ・伸長・分岐の減少**を引き起こしました [1, 6]。
* また、ミトコンドリアの分裂を促進するDrp1が細胞質からミトコンドリア表面に移動し、**ミトファジー(機能不全のミトコンドリアの除去)と小胞体との接触部位が増加**しました [1, 6-8]。これらの形態変化は、回復睡眠後に可逆的であることが示されています [1, 7]。
* **目覚めている間、dFBNsではATP濃度が高くなる**ことが示されました [2]。これは、神経活動が抑制されATP消費が減少するためと考えられます [1, 2]。
* 高いATP濃度は、ミトコンドリアの電子伝達鎖における**電子過剰**を引き起こし、**活性酸素種(ROS)の生成を増加**させます [1, 2, 9]。このROS生成がミトコンドリアの断片化の引き金になると考えられています [10]。
* CoQプールからの**余分な電子の排出経路を設ける(AOXの発現)ことで、基本的な睡眠欲求が軽減**されました [1, 10, 11]。また、ミトコンドリアのATP需要を増加させる(脱共役タンパク質Ucp4AまたはUcp4Cを過剰発現させる)ことで、**睡眠が減少**しました [11]。逆に、電子ではなく光子でATP合成を促進すると、dFBNsにおけるNADH由来の電子が冗長となり、**睡眠が促進**されました [1, 11]。
* dFBNsのミトコンドリアを**断片化させる**(Drp1の過剰発現やOpa1のRNAiによる減少)と、**睡眠時間が減少し、睡眠剥奪後のホメオスタティックな回復も抑制**されました [1, 12-14]。同時に、dFBNsのATP濃度は低下し、神経興奮性も低下しました [1, 14, 15]。
* ミトコンドリアの**融合を促進する**(Drp1のノックダウンやOpa1とMarfの過剰発現)と、**基礎睡眠および回復睡眠が増加**し、覚醒閾値が上昇しました [1, 12-14]。これによりdFBNsの神経興奮性が高まり、睡眠を誘発するバースト発火が増加しました [1, 14]。
* ミトコンドリアの融合には、カルジオリピンから生成される**ホスファチジン酸**が重要であり、そのレベルを調節するタンパク質(zucchiniやMitoguardin)への干渉も睡眠喪失を再現しました [16]。
* 睡眠は、好気性代謝の出現と共に、特にエネルギーを大量に消費する神経系において発生した古代の代謝的必要性を満たすために進化した可能性が示唆されています [3]。
* 睡眠量と質量特異的酸素消費量との間に経験的なべき乗則が存在し、これは哺乳類においても睡眠が代謝的役割を果たすことを示唆しています [3]。
* **ヒトのミトコンドリア病の一般的な症状として、「圧倒的な疲労感」が挙げられる**ことも、この仮説と一致しています [3, 17]。
* 哺乳類における飢餓関連ニューロン(AgRPニューロン)とdFBNsの間のミトコンドリアダイナミクスの類似性は、**睡眠欲求と空腹感の両方がミトコンドリア起源を持つ**可能性を示唆しています [18]。
この研究は、睡眠が単なる行動や神経学的現象ではなく、**細胞レベルでのエネルギー代謝、特にミトコンドリアの機能に深く根ざした生理学的プロセス**であることを示しています [1, 3]。 <h3>o- **</h3>
この研究は、**睡眠が好気性代謝の避けられない結果である**という画期的な仮説を提唱し、睡眠圧の根源がミトコンドリアの機能にある可能性を探求しています [1, 2]。これまで物理的な解釈が不足していた睡眠圧のメカニズムを解明するため、研究者らはショウジョウバエ(*Drosophila*)をモデルに、脳内の分子変化を詳細に分析しました [3]。
研究の中心となったのは、睡眠の誘導と維持に重要な役割を果たす特定のニューロン集団、**背側扇状体投射ニューロン(dFBNs)**です [1, 3]。休眠状態と睡眠不足状態のハエのdFBNsから単一細胞のトランスクリプトームを解析した結果、驚くべきことに、**睡眠不足後にアップレギュレートされる転写産物が、ほぼ独占的にミトコンドリアの呼吸とATP合成に関わるタンパク質をコードしている**ことが判明しました [1, 4]。これには、電子伝達複合体I〜IV、ATP合成酵素(複合体V)、ATP-ADPキャリア(sesB)、およびトリカルボン酸回路の酵素(クエン酸シンターゼkdn、コハク酸デヒドロゲナーゼBサブユニット、リンゴ酸デヒドロゲナーゼMen-b)の構成要素が含まれます [4]。対照的に、シナプス集合、シナプス小胞放出、およびシナプス恒常性可塑性に関わる遺伝子産物は選択的にダウンレギュレートされていました [4]。このミトコンドリア関連遺伝子のアップレギュレーションというトランスクリプトームのシグネチャは、他の脳細胞タイプ(例: アンテナ葉投射ニューロンやケーニヨン細胞)では検出されず、dFBNsに特有の現象でした [4]。
これらの遺伝子発現の変化は、ミトコンドリアの形態と機能に顕著な影響を与えました。睡眠不足は、dFBNsのミトコンドリアのサイズ、伸長、および分岐を減少させるという**ミトコンドリアの断片化**を引き起こしました [5]。さらに、ミトコンドリア外膜の主要な分裂ダイナミンである**ダイナミン関連タンパク質1(Drp1)**が細胞質からミトコンドリア表面へ再配置され、オルガネラの分裂を示唆するミトコンドリア数の増加も確認されました [5]。加えて、睡眠不足は**ミトコンドリアと小胞体(ER)間の接触数の増加**および損傷したミトコンドリアを選択的に分解するプロセスである**マイトファジーの促進**を伴いました [1, 6]。これらの形態学的変化は、その後の回復睡眠によって可逆的であり、電子伝達鎖における電子溢流(electron overflow)の設置によって緩和されました [1, 5]。
本研究は、**睡眠と好気性代謝が根本的に結びついている**という仮説に、客観的な支持を提供しています [7]。dFBNsは、その睡眠誘発性スパイク放電をミトコンドリアの呼吸に連動させるメカニズムを通じて睡眠を調節することが示されています [7]。このメカニズムの中心には、電圧依存性カリウムチャネルShakerのβサブユニットである**Hyperkinetic**があります。Hyperkineticは、ミトコンドリア呼吸鎖に入る電子の運命を反映するNADPHまたはNADP+の酸化状態を反映するアルド-ケト還元酵素であり、dFBNsの電気活動を調節します [7-9]。
ATP合成の需要が高い場合、大部分の電子はシトクロムcオキシダーゼ(複合体IV)によって触媒される酵素反応でO2に到達します [7]。しかし、少数の電子は、上流の移動性キャリアであるコエンザイムQ(CoQ)プールから時期尚早に漏洩し、スーパーオキシドなどの**活性酸素種(ROS)**を生成します [7, 10]。この非酵素的な単一電子還元の確率は、CoQプールが過剰に満たされる条件下で急激に増加します [7]。これは、電子供給の増加(高NADH/NAD+比)または需要の減少(大きなプロトン動起力(∆p)と高ATP/ADP比)の結果として発生します [7]。
dFBNsのミトコンドリアは、覚醒中にカロリー摂取量が高いにもかかわらず、ニューロンの電気活動が抑制されるためATP貯蔵量が満たされた状態となり、この**電子漏洩**のモードに陥りやすいことが分かりました [7]。実際、遺伝子コード化されたATPセンサー(iATPSnFRおよびATeam)を用いた測定では、一晩の睡眠不足後、dFBNs(ただし投射ニューロンではない)のATP濃度が安静時よりも約1.2倍高くなることが示されました [7, 11]。覚醒を促す熱刺激によってdFBNsが抑制されるとATP濃度は急激に上昇し、dFBNs自体を刺激して睡眠を模倣するとATP濃度はベースライン以下に低下しました [7, 11]。
これらの結果は、**ミトコンドリア電子伝達鎖に入る電子数とATP生成に必要な電子数との不一致が、睡眠の根本原因である**という強力な証拠を提供するものです [12]。
ミトコンドリアの分裂と融合のバランスの変化が、睡眠圧の増減を引き起こすNADH供給とATP需要の不一致を修正するフィードバックメカニズムの一部であるならば、dFBNsにおけるこれらの恒常的応答を実験的に誘発することは、睡眠の**設定点**を変化させるはずであるという予測が立てられました [13]。
この予測を検証するため、研究者らはミトコンドリアのダイナミクスにおいて中心的な役割を果たす3つのGTPase(分裂ダイナミンDrp1、内膜タンパク質Opa1、外膜タンパク質Marf)を実験的に制御しました [13]。
また、ミトコンドリアの融合反応において重要な役割を果たす**ホスファチジン酸**の関与も明らかになりました [17]。睡眠不足の脳では、この脂質が枯渇することが知られています [17]。ミトコンドリアホスホリパーゼD(mitoPLD)であるzucchini、または触媒的に活性なmitoPLDを安定させたり、他の細胞膜からミトコンドリアにリン脂質を輸送したりする外膜タンパク質Mitoguardin(Miga)の発現に干渉すると、これらのニューロンのタンパク質ベースの融合機構が標的とされた場合に見られた睡眠損失が再現されました [17]。これは、**融合反応におけるホスファチジン酸の重要性**と、**睡眠調節におけるミトコンドリア融合の重要性**を裏付けています [17]。
本研究は、**睡眠が好気性代謝の避けられない結果である**という説に、強力な経験的証拠を提供するものです [1, 2]。好気性代謝は、地球の大気中の酸素濃度が2回大きく増加した後、真核生物が電子伝達から得られる自由エネルギー収量を最大化することを可能にした画期的な進化であり、これにより、電力を大量に消費する神経系が出現し、それに伴って睡眠の必要性が生じたと考えられています [2]。睡眠はその後、シナプス恒常性や記憶の固定などの追加機能も獲得した可能性がありますが [2]、哺乳類においても1日の睡眠量と質量特異的O2消費量を関連付ける経験的な**べき乗則**が存在し、これは睡眠が古代の代謝目的を果たすことを示唆しています [2, 18, 19]。
もし睡眠が本当に代謝的な必要性を満たすために進化したのであれば、睡眠とエネルギーバランスを制御するニューロンが類似のメカニズムによって調節されることは驚くべきことではありません [20]。哺乳類の視床下部において、食欲増進性ニューロンと食欲不振性ニューロンのミトコンドリアは、分裂と融合の位相が逆のサイクルを経ており、これらのサイクルはマウスのエネルギーバランスの変化と結びついています [20, 21]。これは、ショウジョウバエのdFBNsにおけるミトコンドリアの分裂と融合のサイクルがハエの睡眠バランスの変化と結びついているのと同様です [20]。AgRPニューロンの電気的出力は、体重増加と脂肪蓄積を促進するためにミトコンドリア融合後に増加しますが、これはdFBNsの Permalink | 記事への反応(0) | 19:25
なんかシグネチャパビリオンで予約取れねーかってガチャガチャやってたらこれが取れてしまったので、河瀨直美大嫌いなのに行ってきたけどやっぱりダメだった。
なんだあれ……
最初に「気持ち悪い」って思ったのがアナウンスでいわれた「お帰りなさい」。メイドカフェすら行ったことねえのに、帰属意識ゼロのところで言われるとこのセリフこんなに気持ち悪いんだって思った。
パビリオンなどが廃校になった学校3校の木材で作られてるっていうのもなんだかなぁって。新たに長い寿命のある建物に使われるならともかく、寿命半年の万博パビリオンに使われるだけなら「消費」とどう違うんだ?少なくともその辺は解説しないとダメじゃね?むしろ廃校が万博のために3つ消えましたってそういう話じゃね?
中身はLEDだけど蛍光灯を摸しましたって照明も、まず蛍光灯照明装置に見えない。蛍光灯が裸で設置されて光ってる。チカチカもまったくしない。うーん、LED。
メインの展示は、遠隔地にいる誰か(2名のうちどちらからしい)と、パビリオン入場者の中から選ばれた1名の対話を、遠隔地の誰かがしゃべってるのを大写しでスクリーンにってやつ。
遠隔地参加者って、日本の役者全く知らないので誰か全くわからなかったけど、なんかの役者かそれに類する人っぽい。その人と、参加者の一人があるテーマについて会話するのを延々聞かされる。参加者の方は勿論素人なのでドモったりまともな返答にならない時もある。そういうの含めてのインスタレーションなのかもしれんが、いやぁ無いわ。素人の人責める気はこれっぽっちもないけどさ。
この展示の直前の映像でも色々気持ち悪い事聞かれて「あっ気持ち悪い」「また気持ち悪い」って思ったのを覚えてる。一番気持ち悪かったのが「今日は何人にありがとうっていいましたか?」みたいな問い。鳥肌たっちゃったね。ゼロだよ勿論ゼロ!
頼むからセンスのない奴はプログラマにならないでくれ。迷惑だから。
これが最もプログラマになってはいけないタイプ(犯罪行為などの言うまでもないことを除けば)。
たとえば
等。
不要なものを作ることで、プログラムは複雑になり、メンテナンスの手間は増え、バグは発生しやすくなる。
一定レベル以上のプログラマが最も自然だと同意するような実装(「実装しない」という選択肢もふくめて)をパッと思い付けない奴は、センスが足りていない。
将棋で言えば、駒がぶつかったら先ず取る手を考えるといった基本的な手筋が思い浮かばないようなもので、現実的に使い物にならない。
これは、「Code Complete」「The Pragmatic Programmer」等の著名なプログラミングの本に共通する結論である。
これが「The Pragmatic Programmer」にあるDRYの原則である。
要するに、すべての情報が単一のソースから決定されるべきということだ。情報が二重化すると、それらの間で不整合が生じバグの原因になる。また、二重化した情報は、修正の手間が二倍になる。
たとえば、ユーザーのプロフィールを管理するレコードやクラスに「生年月日」と「年齢」を同時に保持する必要はない。年齢は生年月日から計算できるからだ。
世の中には、「xxxFlag」みたいな不要な変数を作ったり、共通のロジックを抽出せずにコピペコードを濫造するダメプログラマーが多すぎる。
もちろん、合理的な理由があって、この原則が適用されない場合もある。
たとえば、多くの言語組み込みの配列や文字列は、その要素と長さを二重に管理している。配列の長さは要素を数え上げることで求まるが、それには要素数に比例した計算時間がかかるためだ。
ただし、こういう場合でも、公開されたメソッドによる操作では、必ず内部の変数は同期されるように作ることが可能である。それをしないのは、怠慢でしかない。
一文字変数とか連番とかは論外だが、「ary」とか「setData()」みたいな何の情報も伝えないような変数名・関数名を付けるやつ。
正直、コードの読みやすさなんて6〜7割くらいは変数名の付け方で決まると思っている。
名著「The Art of Readable Code」も、半分以上が変数名の付け方に関連する内容だ。
なぜ変数名が曖昧になるのかと言えば、怠慢を除けば理由は2つある。
1つは、コードを書いた奴自身が、そのコードの機能を明確に言語化できないということ。
もう1つは、1つの関数で多くのことをやりすぎたりしていて、その変数の役割が曖昧になっているということ。
たとえば、関数の内部で宣言した変数は、多くの言語では関数の外からは参照できない。
スコープは狭い方が良い。これはほとんど全ての状況に適用できるプログラミングの大原則だ。
スコープが広いということは、ソースコードの多くの場所からその情報を参照・変更できることを意味する。
たとえば、クラスのメンバ変数は各々のインスタンス内でしか参照できないが、静的な変数はすべてのインスタンスが共通に持つ。このため、静的な変数を変更すると、すべてのインスタンスに影響を及ぼし、影響範囲の把握やテストが困難になる。
スコープを広げるか狭めるか、2つの選択肢があったとして、広げる方に心が傾く奴は、プログラマをやめた方がいい。
結果的にメンテナンス困難なコードを生むというのも勿論だが、単に書くだけでも、スコープが広い方が書きづらいのだ。つまり、必要もないのにわざわざ変数のスコープを広げようとする奴は頭のおかしい奴しかいないということになる。
複雑なメトリクスなどを持ち出すまでもなく、たとえば1メソッドの行数が何百行もあるとか、1クラスのメンバ変数が何十個もあるとか言うの。
これは論外である。プログラマとしての能力云々以前に、明らかな怠慢であり、社会人としての常識が疑われる。
定期的にメンテナンスされ続けているOSSのソースコードなどを見ると、関数(メソッド)の行数は平均して5〜10行。20行を超えるものは稀である。
長いものであっても、外部で定義した関数を順番に呼び出しているだけであったり、リクエストをハンドリングして各々の処理に振り分けているだけのようなものがほとんどである。
それを超えているコードは、合理的な理由があってそうなっていることよりは、単に悪い設計であることの方が多い。
これらは実はプログラミング云々というより、内容の理解力や国語力の問題なのである。
ある情報を得るために必要十分な情報は何かが分かってないから、余計な変数を作ったり、無駄に変数のスコープを広げたりする。
そして、自分が作るものを正確に理解していないから、適切な名前がつけられないし、適切なモジュール分割ができない。
それがすべての原因。
こういう人がまず身につけるべきは、プログラミングのテクニックではなく、日本語を正しく読む力。
低学歴が「プログラミングなら自分でもできるかも」なんて思っちゃいけないってこと。もちろん、下請けのSIerとかで使い捨てのコード書きとして働くことはできるが、上に書いたような最低限の力がないなら、それ以上を望んではいけない。
ちなみに、上に書いていることと反対のことを思っている人も世の中にはいる。
特に、昔からプログラミングをしてきた自称ベテランに多い。その人は、能力があるというよりも、単に現代の開発に際して必要な知識がないだけなので、真に受けないように。
また、大学でコンピュータサイエンスの基礎を学びたての学生なども、知識をひけらかしたくて上と反対のことを言う傾向がある。その程度のことは、良識のあるプログラマはみんな分かっているのだが。
グラビアのスキャン画像を蒐集する趣味を楽しんでいた時期がある。
グラビアと言っても日本の週刊誌やアイドル雑誌のグラビアではなく、主に海外のソフトコア雑誌やセレブ誌のグラビアである。
飽きてやめてしまうまでの数年間、日本人の同好の士とは出会えなかったので、たぶん日本人でそれをしていた人はごく少数だったんじゃないかと思う。
自分はただのエンジョイ勢だったのでそれほど深い知識があるわけじゃないけど、日本語の文献も見つからないようだし、思い出としてちょっと書き留めておこうと思う。
だいたい20年くらい前の昔話。
よくわからないが、Online Scan Collection とか scanz(warezのノリ?)と呼ばれていたと思う。
スキャナーと呼ばれる職人が配布する画像ファイル(主にグラビア)をコレクターが集めたり、コレクター同士でトレードしたりする遊び。スキャナーはコレクターを兼ねていたりもするし、コレクターがスキャナーとなって配布を始めたりもする。
配布される画像はスキャンと呼ばれる。紙媒体で売られている雑誌のグラビアを高解像度のフラットベッドスキャナで読み取り、もとが印刷物であったことなどわからないくらい美麗にレタッチされたJPEG画像である。600dpiクラスのスキャナと高機能のレタッチソフト(ほぼPhotoShop一択)がたぶん必須。
題材は大半がセクシーな女性のグラビアで、ヌードでもPLAYBOYやPENTHOUSEに載る程度のおだやかなもの。水着、下着姿のものも多い。が、たまに美しい風景のシリーズがあったりもする。
画像の片隅にはそれを作ったスキャナーのシグネチャ(かっこいいアイコンなど)がウォーターマークとして付される。
あ、上で「日本人はごく少数」と書いたが、おそらく日本人だろうというスキャナーはいた。中でも印象に残っているのは Kuni Scan という2万枚ほどのシリーズで、題材が日本のグラビアだったし名前からして日本人だろう。Kuni Scan で画像検索すると今でも彼の作品の一部を見ることができる。
今でもそうだが印刷物をスキャンして配布するのは明白にコピーライト違反であるし、ことに題材が肖像権にがっつり抵触していることもあって、一次配布はきわめて目立たないかたちで行われていた。
スキャナーたちが「新しいのできたよー」と最初の配布を行うのはおそらくIRCチャンネルだったと思う。自分は外人たちと英語でリアルタイムのチャットをする自信がまったくなかったのでIRCにはほとんど近寄らなかった。なので一次配布の現場のことはよく知らない。
当時はimgurのような匿名画像アップロードサイトなどもなかったのでこのような個人間のやりとりで配布が行われていたのだろうと思う。
この時、スキャナーは画像とともにスキャンリストも一緒に配布するのであるが、それについては次で述べる。
スキャンは数十枚~100枚程度のテーマを持ったシリーズとしてリリースされる。テーマはモデルであったり、雑誌であったり様々。
最新リリースには必ずそのシリーズに含まれるファイルの一覧を記したCSVが添えられる。
リストに記されているのは [ ファイル名, ファイルサイズ, CRC32 ] の3項目(CRC32はファイルの指紋のようなもので、データの同一性を確認するのに用いられる通信技術)。
この3項目が一致していないとオリジナルデータと認められず、集めたことにならない。
たとえばWebで目当てのファイル名の画像を見つけたとしても、それが何者かの手によってリサイズされていたり再圧縮されていたりするとCSVと数値が一致せず、コレクションに加えることができない。
シリーズには継続中のシリーズとすでに完結したシリーズがあり、CSVファイルに[finished]といった名前がついているのが完結したシリーズである。これに載っているスキャンを全部集めたらコンプリート。
CSVはこんな感じで今でも配っているのを見つけた。
http://www.scancollections.com/CSV/list_csv.php
(私がかつてひとつだけスキャナーとして配布したシリーズも含まれていた。なんだかうれしい)
一次配布時にIRCを通じてスキャナーから直接手に入れることのできなかったスキャンは別の手段で探すことになる。
Webにアップされているものを探したり、同好の士とトレードしたり、alt.binaries(ニュースグループ)でも交換が行われていたように思う。
私は主にWebサイト経由で集めていたのだけれど、当時個人ホームページの割り当てボリュームは数MB程度がふつうだったので、スキャンをアップしてくれるサイトも古いものはどんどん消されてしまった。しかも1枚1枚がやたらでかい。今でこそ一辺が1000ピクセル以上あるような大きな画像でも表示は一瞬だけれど、DSLすらなかった時代の混み合うテレホーダイのISDN回線では300KB程度のJPEGでも上からじわじわ表示されてくるのを待つ感じだった。
海外の同好の士からトレードを持ちかけられることもあった。トレカの要領。ロシアや台湾のコレクターと、お互い非母国語の英語でたどたどしく「おまえこれ持ってるか」「おれのこれやる」とトレードのやり取りをするのである。基本は1:1で持ってないもの同士を交換というタテマエだけど、自分は持っているものは気前よく差し上げていた。ドイツのコレクターとはたまたま音楽の趣味が合ったのでしばらく文通してたな。
そうやって新しく手に入ったスキャンがあると、コレクションマネージャーみたいなソフトを使ってCSVと照合する。CSVと一致しないデータを取り除いてくれたり、リネームやフォルダ分けを自動でやってくれたりするスキャンコレクションに特化した管理ソフトがあったのである。
自宅のネット回線をFTTH常時接続に変えたとたんにコレクションがつまらなくなった。
どんなサイトも画像もピュンピュン一瞬で表示されるし、コレクションがウン千枚詰まったZIPファイルですらたちまちダウンロードされて、「苦労して一生懸命集める」という手応えがなくなって、「やりがい」がなくなってしまったのである。
DSL、常時接続の普及にともなってネット上には高解像度データがあふれるようになり、スキャンでしか見ることのできなかった美麗画像の希少性がどんどん下がっていったこともあると思う。
「それ俺もやってた!」って人いますか?
LiveDoor認証がでたらしいので、とりあえず寝際にちゃちゃっと書こうとしたのだけどなんかうまくいかない。
「ログインURLの有効期限が切れています」とかでちゃうんだ。
なにか間違ってるかな?
<?php // LiveDoor認証に必要なリンクの生成 // 定数がクラス内に切ってあるので環境にあわせ変更してください include_once('authlivedoor.class.php'); // Livedoor認証用クラス $obj_auth = new AuthLiveDoor(LIVEDOOR_APIKEY, LIVEDOOR_SECRET); $livedoorloginurl = $obj_auth->getLoginUrl(); ?> <div style="border:solid 1px #666666;"> <a href="<?= $livedoorloginurl ?>">ライブドア認証を利用してログインする<br /> <img src="http://auth.livedoor.com/img/cmn/head_livedoor.gif" border="0"> <img src="http://auth.livedoor.com/img/cmn/head_logo.gif" border="0"> </a><br />
<?php // this code is writen by utf-8 & lf //http://auth.livedoor.com/login/?app_key=<app_key>&perms=<perms>&t=<time>&v=1.0&userdata=<userdata>&sig=<sig> // LiveDoor外部認証APIを利用する // キーは各開発者ごとに取得が必要です。 http://auth.livedoor.com/ ここより取得できます。 // コールバックURLには authlivedoor.php を指定してください // --- 下記宣言を環境に合わせて変更してください。 --- define("LIVEDOOR_APIKEY" ,""); // アプリケーションキー define("LIVEDOOR_SECRET" ,""); // LiveDoor認証秘密キー // --- ここまで --- class AuthLiveDoor { const LIVEDOOR_AUTH_PORT = 80; // ポート const LIVEDOOR_AUTH_TIMEOUT = 10; // タイムアウト const LIVEDOOR_AUTH_VERSION = '1.0'; // 認証APIのプロトコルバージョン const LIVEDOOR_AUTH_PERMS = 'id'; // 認証APIのアクセス権 const LIVEDOOR_AUTH_FORMAT = 'xml'; // 認証APIの取得フォーマット const LIVEDOOR_AUTHURL = "auth.livedoor.com"; // LiveDoor認証URL private $login_state = false; private $login_id = ""; private $err_msg = ""; private $apikey = ""; private $secret = ""; public function __construct($apikey, $secret) { $this->apikey = $apikey; $this->secret = $secret; } // // $cert = $_GET['token']; public function getAuth($token) { if ($token == "" ) { return; } $api_time = date('U'); // エポック秒で $param_ary = array($this->apikey ,AuthLiveDoor::LIVEDOOR_AUTH_FORMAT ,$token ,api_time ,AuthLiveDoor::LIVEDOOR_AUTH_VERSION ); sort($param_ary); $api_sig = hash_hmac('sha1',implode('',$param_ary),$this->secret); $param = "app_key=".$this->apikey ."&format=".AuthLiveDoor::LIVEDOOR_AUTH_FORMAT ."&token=".$token ."&t=".$api_time ."&v=".AuthLiveDoor::LIVEDOOR_AUTH_VERSION ."&sig=".$api_sig; $fp = fsockopen(AuthLiveDoor::LIVEDOOR_AUTHURL , AuthLiveDoor::LIVEDOOR_AUTH_PORT , $errno , $errstr , AuthLiveDoor::LIVEDOOR_AUTH_TIMEOUT); if (!$fp) { $this->err_msg = "$errstr ($errno)<br />\n"; } else { $out = "POST /rpc/auth?$param HTTP/1.1\r\n"; $out .= "Host: auth.livedoor.com\r\n"; $out .= "Connection: Close\r\n\r\n"; fwrite($fp, $out); $ret = ""; while (!feof($fp)) { $ret .= fgets($fp, 2048); } fclose($fp); } // LiveDoorの認証XMLのパターン $pattern = '/(\s*<livedoor_id>)(.*)(<\/livedoor_id>)/'; preg_match_all($pattern,$ret,$getAry); $livedooruserid = $getAry[2][0]; // ユーザーIDを取得できた場合 if ($livedooruserid != "") { // ログイン成功 $this->login_state = true; $this->login_id = $livedooruserid; return ture; } } public function getLoginState(){ return $this->login_state; } public function getLoginId(){ return $this->login_id; } public function getLoginUrl() { # http://auth.livedoor.com/guide/ # http://auth.livedoor.com/login/?app_key=<app_key>&perms=<perms>&t=<time>&v=1.0&userdata=<userdata>&sig=<sig> # app_key 必須 登録時に発行されたアプリケーションキー # perms 必須 要求するアクセス権、現状userhashとidの2種類がある # t 必須 URLが生成された時間をエポック秒で表したもの # v 必須 プロトコルバージョン、現在は1.0で固定 # userdata 任意 コールバックURLに引き継ぎたい値を255バイトまで自由に設定できる # sig 必須 このURLの正当性を確認するためのシグネチャ // ログインURLの有効期限が切れています // ヾ(。o、゜)ノ ここらへんがわからん!! // $api_time = time()+32400; // エポック秒で $api_time = date('U')+32400; // エポック秒で // $api_time = date('U'); // エポック秒??もしかして、それはポエティック病ではありませんか? $param_ary = array($this->apikey ,AuthLiveDoor::LIVEDOOR_AUTH_PERMS ,api_time ,AuthLiveDoor::LIVEDOOR_AUTH_VERSION // ,data ); sort($param_ary); $api_sig = hash_hmac('sha1',implode('',$param_ary),$this->secret); $loginurl = "http://auth.livedoor.com/login/" ."?app_key=".$this->apikey ."&perms=".AuthLiveDoor::LIVEDOOR_AUTH_PERMS ."&t=".$api_time ."&v=".AuthLiveDoor::LIVEDOOR_AUTH_VERSION // ."&userdata=" ."&sig=".$api_sig; return $loginurl; } }
もう疲れたので寝る。ライブドアなんてーーーー!!!
訂正。
秘密キーとか、そのままのっけちゃった (ーωー|||)
そしてなかなか訂正できなくてあせった。。