2018年
平成30年 昭和93年
350日経過 残り15日
16
休業日
12月 日曜日
Dec 師走 Sun 友引
December Sunday
今月営業日
009 / 019 日
今月休業日
006 / 012 日
今年営業日
000 / 241 日
お知らせNo.339. SSLはじめました。 2017/12/18
お知らせNo.305. ユーザー様整理いたします 2017/09/28
お知らせNo.223. Firefoxのパスワード記憶について 2017/03/23
お知らせNo.218. プラグイン機能の説明を作成しました。 2017/03/22
お知らせNo.211. LINEを公開しました。 2017/03/17




USER:
PASS:
新規登録
  • BBSみしお より
  • BBSみしお より
  • BBSみしお より
3人の会員

1
Unique
Visitors
Powered By Google Analytics
インフォトップ公告表示プラグインの実演です。

たぶんもうきっと

担当@みしお 開始日:2017年12月20日

プログラムのことについてはあんまりくわしくもないし発言することもほとんどないと思うし、ホームぺ時の要素からも減っていくとおもいます。
現役で頑張ってる人のほうが情報も多いと思うし有用だと思うし、文系でちょこっと学校の情報処理の時間を昼寝してないことくらい程度なものならときどきつぶやくかなと。
そういう感じです。

フックのはなし

担当@みしお 開始日:2017年11月20日

ワードプレスにはフックと称される作法がありフィルターやアクションを規定動作に含めるものを示しています。
フックとは、プログラマをしている人にとってはおなじみであり、プログラマになりはじめた人にとっては憧れの機能であったりもします。

ワードプレスのフックとは異なるのですが、プログラミングやソフトウエアにおけるフック動作をまず紹介してみたいと思います。
フックとはいわゆる割り込み動作のことで、キーボードフックというものなどは有名かと思います。
キーボード操作からOSがそれを受け取りフォーカスのあるアプリケーションにそれを流すのですが、まずキーボード入力を取得した時点からアプリケーションに伝達する間にわりこみをしてそれを取得したり取得した後無効にしたりします。
これはアプリケーションに入力された情報を取得するでも構わないのですが、そのためには対象のアプリケーションごとに動作のたびに返事をくれと問い合わせをかける必要があったり変換された後のデータを受け取る形になったりただ煩雑になるだけの動作を簡略化するものになっています。
ですがキーボード入力を阻害したり入れ替えたりすることができるため責任も重大になります。なのでそう簡単なものではないものでもあります。
ほかに漢字変換プログラムのところで取得するとか、アプリケーションが常駐して監視するなどの方法もありますが、目的は同じく「現在フォーカスのあるアプリケーションとインターフェイスの間の作業にわりこむ」ことです。
とりいそぎ今なにを考えてもおなじ説明文を繰り返すだけになりそうなのでここまでにしますが、ようするに上流で動作を仕切る仕組みがあるということです。

この上流とか下流とか高級とか低級といった表現は相対的であったり感覚的であったりするのでいまいち説明に向いてないのですが「動作を始めてから終わるまでの間」を時系列にして早いものから順位最後のほうまであって、その最初のほうに割り込む部類だということです。
まだ人の手を介さない段階のコンピュータの動作について既定値以外の要望を加えることの類になります。

ほかにもブラウザーがネットから取得するデータをフックするだとか、特定のアプリケーションの動作を外部から操作したりするなどのフックもあります。

ようするにAPIなわけですが、このAPIという概念とフックが似ているためウェブアプリでもフックと呼ばれる処理の分類がなされ、ワードプレスにおいてはその構造の近い部分がフックと呼ばれています。

UIのない部分や他のアプリケーション、PHPでいうローカルルーチンやストラクチャの部分に干渉するようなものがフックと呼ばれるようですがこれはさすがに上記のプログラムを理解した上でないと名前の由来がわかりにくそうです。

ちょっと話はとびますが、フックのメリットは先の「出先全部に網を張ってつかまえるより出元でつかまえたほうが確実便利簡単軽量」であるというところです。
源泉徴収的な感じです。もちろん起算点によるのでUI単位で言うとなのですが、アプリケーション単位でももちろんあります。規模に差はあれユーザー以上に割り込む段階は多々あります。
メリットはなんといっても元データに触れることができるタイミング、インフラとして準備しているところや別の完成した機能からデータをおすそ分けしてもらえると、その結果処理などしなくてもよいし取得許可も作成しなくて済みます。
ウェブでいうとOauthを使った認証があるとして、それを使ったユーザー一覧を取得するのと、ログインし終わったブラウザから表示される一覧データを持ってくるのとではプログラムの作成量がかわります。
アカウント、パスワードを保持して認証、リクエスト送信、受信、解析、整形して表示という動作が、取得、表示、だけで済むわけです。
厳密には割り込み動作のフックプログラムがいるわけですがそれを抜きにして、また動作的にも軽量化が図れます。
ユーザー名とパスワードの変数は時限的に破棄されているか、リクエストのセッションは内部で起こしているか、などの安全性やガベージコレクトなどといっためんどうな動作をしている他のものに干渉してデータをどうにかしてもらえます。
デメリットとしては作成した式は前の式やデータ、アプリケーションや動作がなければ動作しないものなのでニーズの低いところであれば「ずっと動作待ち」だけしているフックもあるかもしれません。
ワードプレスにおいてはその便乗処理が便利であるため、不要になったデータの後処理をせずとも完了してくれているわけでその時発生したデータはグローバル変数に代入でもしない限り後始末されます。
$PASSなどの変数にパスワードが保持されたままのプログラムとかいやですよね。同じように抽出された表データのもとがそのままとか最終段階でも読み出されるのはこまります。
なのでいちいち全部読み出し定義、読み込んだ後、後始末をつくらなくても前後はワードプレスに任せて読み込んだ後動作だけに追加で機能をふやすことができる構造がワードプレスのフックです。

UIのないところに作業を含ませることをフックという、ということになりますがそこがフックではなく「何であっても2者間があり、コンピュータや人にかかわらずその両者にかかわらないプログラムが仲介データをわけてもらう」のがフックであることからワードプレスも「動作的にこれはフックと呼べるのではないか」というところからフックという名称になっていると思います。

まあ簡単にいうとインターフェイスにほぼ直結した「API」のUIなしだといえばそういうものかと思います。
なので元のデータ、データ形式や出元と渡す先の仕様、これらがかみ合わなければフィルターとしては機能しません。
それとは関係なくデータの参照もべつになく、ただ動作をさせたい「ただいま読み込み中」とか「現在70%」といった表示のために任意の段階に返事がほしい単独動作がほしいときにはアクションフックがつかえます。
その時点においてフィルターではなく、結果を内部に返さず動作だけ、外部に出して終わるタイプをアクションと呼びこれも中間にはさむことができます。

たとえばパソコンで「こぴぺ」という動作がありますが、コピーした元にコピーデータがあるわけでもなく、貼り付け先が「コピーもとに複製データを要求している」わけでもありません。
キーボード動作の一番近くに「クリップボード」というアプリケーションが動作しており、キー操作によって現在フォーカスのあるデータを、そのアプリケーションから自分のアプリケーション内部に複製しているのです。
貼り付けは、自分のアプリケーション内に複製したデータを、対象のアプリケーション内部に書き込み動作を行っています。
関係性からいうとAPIである、ともいえるのを逆説的に「ワードプレスの内部処理するAPIのことをフックとしよう」ということです。

おおまかにUI以前の話なので「画面がでてくる前に処理したい作業、画面がでた時点でおわっていてほしい作業」を担う部分に人の手を加えるのがフックなので、ワードプレス的にいえばヘッダーが生成される前にする作業にあるのがフックです。

規定の動作順序を変えたり、規定の動作に変更を加えたりするところに役立つと思います。

表示されたあとで割り込みをかけるのにはJavascriptでしょう。正確には割り込みではないですがUIの動作の人の手にさらに動作追加して便利を求める「割り込み」に似た動作ができたりAjaxでCGIの「サーバーに問い合わせるためには画面の更新が必要」のデメリットを小さくしたりさまざまに補助をして対話動作の簡略化を図ることができます。

そんなに使うことは多くないと思いますが、ここ一番というところで必要にもなってくると思うので必要な動作についてだけ徹底的に研究して使いまわしていくのもいいと思います。

おうたこにおそわる

担当@みしお 開始日:2017年10月30日

おうたこにおそわる、そんな日本語ご存じないですか?
背負った幼い子に教わることもある、そういう格言だったと思うのですが、IME が変換を受け付けません。
うたこさんがおしえてくださるとか変換しないのです。
もうそんな日本語が存在しなのか、ラノベの名言が格言になる世代になってしまったのでしょうか。
アニメで読み解く政治とか会社の常識とか、存在してないもので例える自体おかしいとおもわれない世界ってだいぶゆるふわだと思うのですがそもそも女子高生が○○○ってみたからもうそんな世界は顕現していたんですね。

ともあれいろんなところでちょいかみしていた分野が活気づいてわたしのわからないことばっかりになってると、ひがみのひとつも言いたくなります。そういう気分がわかります。
最近の若い者は、なんて言葉もそうでしょう。自分とよい別れをする後輩をみるのはつらいものですが、それは前からいるものとしてせめて害にならないよう見送りたいものです。

しかしいまどきの方はいろんな発想があって驚きます。
そして解決方法を出してくる人たちもすごいです。
せめて足を引っ張らないように新しい事柄にもチャレンジしたいところですが、やっぱり基礎となる思い礎が邪魔になることはあります。

逆に、その過去の重い礎を利用して若い人たちに踏んでいってもらうのが私たちのこされたものの役割かなあと思ったりもします。
そこで口から出てくるのが、システムエンジニアは徹夜だのデスマーチだのしかないのですが、もっと役立つ情報はあると思うんですよね。
有名なプロジェクトを人脈でなんとかしたとか、運よく通った案件とかじゃなく、こまかいコードでこの条件をみたせる式があるとかそういうのが。

私はもうそういうしょーもない豆知識プログラムくらいしかできない気がしてくる感じなので、若い人にがんばれっていいたいです。
ほんと、ループのきれめとか条件分岐とか文字の変換方法とか、こまかい技でいいかんじのコードなんかも、あるんですよ。
いつかはそんな質問がくるんじゃないかとためているのですが、そんな質問はこないですけどね。

いつか、思い出話がコードで話せるような日が来る時のために。

かっこいいコードを書く人

担当@みしお 開始日:2017年10月23日 更新日:2017年10月26日

この定義がかっこいい、この判別式が効率的、この演算は芸術的、みたいなコードをみつけて感動したことがある人もいると思います。
また逆になんでこんな汚いコードで、定義が間違ってる、あいまいな判別式だな、というのもあると思います。

しかしどちらも見た人であった人、そのタイミングでの出来事であとあと見方が変わることもあると思います。

実際のところ動けばなんでもよいわけで、動かしたタイミングでうまくいっていればマイグレーションという名目でバグ修正する手もあると思います。

結局はそのコードをあとから見る人の主観なので、これがすごいと紹介したところで浅い反応しか返ってこなかったり、逆に修正を指摘されることあると思います。
またその逆も、とすると相対にあるものなのでなんともいいようがないと思うのですが、主観で今現在の感想を書くことで、自分自身の興味や価値観を表現することはできると思います。

もしのちのち変化した価値観を話すことがあれば、この時点の私の感想と比較することもできると思いますし、一貫していないことでもいいと思います。
子供のころにパイロットになりたかったといっていたのにプログラマなると、嘘つきなのか詐欺師なのか虚言壁なのかといわれると、それは成長と変化というべきで、予想と希望と約束はそれぞれ別物だろうと思います。
ことに他者のかかわることであれば批判を受ける対象になりがちかと思いますが、自分の他者に対するスタンスというのは距離的に量的に、どういったものであるかを確認する基準になる気がします。

そんなにがっつりプログラミングをしているわけではないのですが、何をしているのかといわれればプログラミングと答える以外はネットサーフィンとファイル名の付け替えくらいなのでプログラミングをしているわけですが、さいきんいいなと思うのはワードプレスの関数をつかっている人をみるところです。
ワードプレスはもともとライブラリとしていけてるなと、ホームページを作るのにDBを準備するだけでサイトができちゃうなと、そういうところから好んでいたのですが、コードや構成のバランスがとても好みです。

そのフラグ、つくるわーとかつかうよねーとか、そういう関数がわりとあります。それを覚えていれば使うのですがついつい忘れてPHPで書いてしまったりします。というかPHPのコードで改造することが多いです。
CMSとしてきれいにまとまる関数で判別式とかつくってる人をみると、よく学んでるなあと、きれいにまとまってるなあと、思ったりします。

もちろんライブラリとして関数をつかっていればなんでもいいなと思うわけではありません。大量のデータを判別式で振り分けるなどに関数でループをかけていたりするといまいちでは、と思うことも見かけたりすることもあります。
その基準は微妙なところもありますが、ときおり動作よりもみていてたのしくなるコードに出会うこともあります。

とくに最近、function.php内でフックをつかったワードプレス関数をみると、うまいなあと思うことがあります。
自分でPHPで全部書くと、比較してかっこよさがきわだちます。

関数と変数の織り交ざりが際立つのがfunction.phpです。
ここのカスタマイズを紹介している記事は見ごたえがあります。どういう形であれ、なにかの可能性を感じます。
自作のテーマでないとなかなかいじることはないかと思いますが、子テーマというかたちのおかげで変更を試みられる方もおおいのではないでしょうか。

ワードプレスの趣は、function.phpへの手の入れ具合をみて楽しむという方法もあるのではないかと思いました。

if文のかたち

担当@みしお 開始日:2017年10月20日

if文は便利なのでいっぱい条件分岐に利用します。
でも便利だからといってどんどん使うとこまったことになるので用法容量、は守らなくてもいいのですがあるていど自分でコレダという方法があると、めんどうなことになる率が下がります。

まずIf分はTrueで書きましょう。
Trueを拾う場合、参照値を用意しなくてもいいという特権が利用できます。
しかし数字の1でも動作してしまうので、使い方はブーリアンであることを厳格にたもつべきです。
そうでなければTrueを書くか条件フラグを他の物と勘違いしないものに書き換えて確実に利用するのがよいでしょう。
足し算させますが宣言はしておらず、数字がはいっていれば条件が満ちるとした場合足し算の結果が1でも通過しますしExistsは数値でないもの(浮動小数点演算してしまった結果)などでも動く可能性があります。
精査して「通過」と明確なフラグを、そうとう急ぎである場合は明示してあげるのが間違いを減らすポイント1です。

ポイント2は、できるだけ最小単位で条件を確認させます。
Aである場合とBである場合かつCでない場合を、といった構文をひとつにするとスマートですが、見た目はスマートですがちょっとまってください。
人として、そういう注文をうけたときはきれいにさばけますか?スタバのメニューをさらりと唱えてどういうトッピングか理解できますか。
まずすべて一つずつ条件を確認して、見たれたかどうかを使うべきです。
バイナリであってもかさなるたびに二乗されていって、正しい条件かわからなくなるものです。
そして遅くなります。複数の場合はswitchを、switch(true)という使い方で条件構文を複数持つことも可能ですし、トップダウンなので条件の構造を上位から継承してもよいでしょう。
ifの多重については気を付けましょう。

ここでちょっと小話、条件確認はtrueで、そしてフラグ判断は加算で要項がふえればふえたぶんだけ併設しましょう。
会計をされている方は「マイナス要項をマイナス個数分”加算”しなくてはいけない」といえばご理解いただけるかと思いますが、トータルで判断する、という場合で複数に分岐があるとき、増減を単一の値で示す方法はありません。
桁数をすみわけに固定長をつかうとかあると思いますが実質2系統にしているわけでおなじことです。
2次元的なものを1変数にするとやっぱり1次元結果しかないので最終的に同数の反対結果がかさなってしまいます。
なのでどちらの方向について計算するにしても、加算でのみ表せる式は加算で構造をつくるとあとからわかりやすいです。

閑話休題、if分ですが、さんざんちゃんと確実な演算結果で判断しましょうと言った矢先、横着な使い方もできます。
横着を考慮したうえで、あくまで厳密に書くようになっていただけると幸いです。

たとえば関数など実行結果がある、成功したなどの結果を式ごとifに入れることができます。
一時変数を極力つかわないスリムなプログラムがつくれますが、さかのぼるときものすごく面倒になります。

わかりやすいプログラム、匠の技でくみ上げた宮大工プログラムなどあるかと思いますが、まずはもっさりごつくはなりますが全行に判断状態を書きこめるくらいにIFを使ってみてはいかがでしょうか。

SNSのAPIをつかうとき

担当@みしお 開始日:2017年10月20日

SNSのAPIをつかってログインをしたりする仕組みはいくつかあると思います。
基本的にAPIの多くはふつうのホームページをみるようにアドレスを指定して、そこから人が見るようではなく機械が読むようのデータが返ってくるしくみです。
特殊で覚えにくい長いアドレスを投げて、XMLやJSONで帰ってきます。
そのやり取りに個々の状態をおりまぜるためトークンというのを使ってどのような権限があるか、ユーザーについてあるか、といったものを付加して動作します。
他のサーバーのデータをもってくるものですから、様式はそれぞれです。バージョンもそれぞれです。

だいたい同じ動作についての注意点は、アプリケーションという単位名で機械が表示するホームページデータ公開窓口としてURLが設置してあり、そこへの尋ね方が毎回命令が変わると面倒なので様式化しているものがあります。
広く皆でつかうものがインターネットなので、そういうものは規格を用意されることが多いのです。

これを、プラグインなどで代替してくれるのはとても助かるのですが、他サイトのログイン動作を代替するわけで責任重大です。
そんなに重大でもないし法的には責任などないのですが、セッションをはる、維持する、といった動作は貴重な動作といういみあいなのです。

そのため転送回数やセッション確認、キー確認タイミングや状態など制限があるものがあります。
ログイン情報やトークン情報を改竄されてはこまるセッションなどもあるからです。

最近ではSNSはみなSSLがついて、みな基本的にはSSL通信をしようという感じなのでそれはとても大事なことですが、サーバー内部で基本的には安全を担保しておきたいところです。
なので、ログインするAPIを利用するものではサーバーエラーがでることがしばしばあります。

ただの特設URLを開くだけなのにサーバー内部でエラーだと、プロトコルに不具合があるのでは、データセットに異常があるのではと思ってしまうかもしれません。
しかしセッションの貼り方や返信先アドレスが違っていたりすると、確立すべきでない経路として内部エラーというかたちで発露することがあります。

ループバックのアドレスやアカウント情報、セッションの維持、転送についての不具合、GETなどのプロトコルで参照が返ってきて取り込み転送する際にデータが欠損する、セッション開始タイミングなどの問題もあるかと思います。

SNSや他WebサービスのAPIをプラグインなどのパッケージで利用する場合、設定項目を調整したのち動くのであれば状態の維持を、うごかなくなったのであればスクリプトプログラムの変更から微細なサーバー状態変更、環境設定やパスの違いを確認するべきかと思います。
よそさまの承認を使ってもってくるのに、わずかなファイルの位置違いやアドレス違いはゆるされないものです。ログイン先の転送ページが悪意のあるところへ書き換えられたものであればとても危険です。

とはいいますが実際のところけっこうな許容があるのでセッション開始はそんなに気にしなくてもいいと思います。
サーバーエラーがでたときは、わりと具体的な変更やみてわかる動作の違いのある部分だと思いますので、動かなくなったタイミングで、動いていたときまでのあいだの作業をひとつずつおりかえしてみましょう。

著作者の責任について

担当@みしお 開始日:2017年10月20日 更新日:2017年10月20日

ワードプレスとかオープンソースなものには責任がなくてみんなが自由にというのがあります。
フリーなので自由に加工したりしてもよいものです。
それによって被害がでたりとか損をしたりすることがあっても、自己責任でとかいてあればそのとおりです。

ただ、責任やライセンスというのはそれを守る構造や定義をする団体がその規範を示し理解すべき情報群を量子化したものであって、責任ということについてまったくないとしても「その規格の中において責任を話すときは、その規格内でのこと」であります。
契約も権利もとくにないところで「それは私の責任を感じるわ」ということはあると思いますし、あってもいいと思います。
たとえば相談をうける掲示板で匿名で無料の相談をうけ、自分がベストだと思う答えを返してそれが大失敗だったとき、「責任を感じる」ことはあると思います。

たとえば、同じタイトルのものを加工して変造してつかって問題が発生したとき、もとの名前を出す必要があるのかないのかと言われれば「○○○を変造したものが暴走して」など、もとの情報にいたるについて起因をたどるという形容的に「責任追及」をするときに「変造した人」がその問題を起因したことになるということは理解がほしいところです。
ライセンシとして同梱していないから、というのは簡単ですが「エラー回避をしていないのでご注意ください」といっていわずで問題があったとき「自分がしっかりしておくべきだった」と反省する責任性があってもいいと思います。
また他の人のコードを利用したり、他の人の命名したファイルを利用してその名を冠したまま違う動作をさせる、その加工品を再利用される可能性のあるところに置くということについて「そうする場合は名前を変えてください」と期する必要性、という責任はあると思います。

法制上ないとしても、人のコードには発表するのにそれなりに使ってもらいたい、使うと便利、悪いことにはつかわれたくない、という思いは基本あって、それをだれかが意図しない方向で継承したとき、源流について「責任を感じる」人はいるものだと思います。
作者の方や、似たもので同じに動かないものが存在してしまう可能性について、「ライセンス的に」という著作情報だけごっそりカットして、オリジナルですわと、配布しないにしても、言われなければ気が付かないにしても、そういう使い方を、してはもらいたくないなあと、そういう思いです。
自分のつくったプログラムが同じ顔で自分の意図しない動作をどこかでしてる話を聞くと、心をいためる、責任を感じることを言いたかったのですが、ノーベルはダイナマイトで死ぬ人を悼まないでしょうしアインシュタインはヒロシマナガサキを悼んだりしないでしょう。
責任はないのですから、責任を感じたり責任を負わせてしまうかもしれないとの思慮は不要ですね。
改造する際には、本人に一言、まったく必要ないですが、あったらいいなと個人的に、自由と、自由における結果と成果に人が関与していることいついて、少しばかり考慮いただけたらよいなと思っただけでした。

ぶっちゃけ裁判で勝てるか勝てないか、金がとれるかだけいっとけばいいわけですよね。
感情とか、ネットやエンジニアには、不釣合いなものだと自分を律せねばと日々反省するばかりです。

Webサーバーのめもりえらーについて

担当@みしお 開始日:2017年10月20日 更新日:2017年10月20日

ウェブサーバーでファイルのやりとりをしたりとかするとときどきメモリエラーがでてきたりすることがあります。
簡単にちぇっくしたいところは次の通りです。

どうしてたりなくなるの?
いまつかってるめもりは?
どれくらいいるの?

どうしてたりなくなるの?
ファイルとかデータを一時的にメモリがうけとったりしたとき大きさがすぎるとエラーになります。
メモリにのらなくなるからです。

いまつかってるめもりは?
PHPのコマンドなんかで確認できます。

//memory_limit メモリみる サーバー内部の演算容量
//post_max_size 転送総量 POSTプロトコルであたまうちにする量 これでひっかかると移行のレセプト動作がNullります
//upload_max_filesize 到着したファイルが受け入れ可能な上限 これ以上だと演算せずに返しますがPOST通過していればここまではきます(tmpには入りません)

//いまのメモリ量をみる
ini_get('memory_limit');
//以降の当該プロセスにおけるメモリ量を変える
//(注 このプロセス動作内だけです
$newLimit = 64;
ini_set('memory_limit', $newLimit.'M');
//ほか 設定の雰囲気はこんなかんじ
$max_filesize = ini_get('post_max_size')*1024;
ini_set("memory_limit" ,round($max_filesize/1024)."M");
ini_set("post_max_size" ,round($max_filesize/1024)."M");
ini_set("upload_max_filesize" ,round($max_filesize/1024)."M");

どれくらいいるの?
ふつうにWebサーバーをうごかしていると20メガくらいでなんとかなります。
人気がでていっぱい閲覧されてもテキストのチャージにそんなにつかわれません。
画像を描画させたり、ファイルや一塊のデータをあつかうと、そのデータがそろうまでメモリを占領するのでたりなくなったりします。
PHPのプログラムで大きさを確認したりその分だけ準備したりもできるので常にがばーっとあけておかなくても、転送ファイルごとにサイズを調整して確保してあげることもできます。

きになるサイズは
転送の最大受付量
ファイルの最大受付量
展開のの最大受付量
とありまして、これらを設定した上限を超えた分がくるとエラーになるほか、データ展開の上限をこえるとエラーがでます。

プログラムは複合的に動くのでどの部分で引っかかるのかは精査が必要です。

まあだいたいあげとけば大丈夫です。

かるく、設定したものが反映されているかをみて、他のプログラムで抑制されていないことが確認されたら設定どおりだと思います。
なにか設定したものと数値がちがっていれば、必要なものが動作しているか確認する必要があります。

ファイルの書き込み損じとかそういうのが多いかと思いますがGDI+を使っていると画像の大きさオーバーででたりもします。
うけとったファイルごとに容量確保するというのも対応策です。

もともとファイルの大きさは受け取る上限の設定だけでとくにPOST、FILESIZEはメモリエラーと関係ありませんが、一旦内部でうけたファイルを操作する、読み込むなどの場合にメモリに乗せることがあります。
このタイミングでうけとったファイルがオーバーしていたら、メモリエラーが内部で出ます。
受け取りサイズを抑制することで防げたりもします。
また物理的なエラーででたり、読み込みすぎて停止してしまうこともあります。

こまかい話をすると転送されたデータはサーバーのWebプログラム動作ユーザーのtmpフォルダに受け付けられます。
くっきーとかセッションもここにハッシュがファイル名になった実データとして保存されます。
ストリーミングデータ転送だとメモリにキャッシュすることなく書き込んだりすると、メモリはたります。
それを書き込むとか読み込むとか加工するとか変数にまるごと代入してみたりとかになって、メモリに転送すると大きさオーバーのときはエラーがでます。
この動作に至る前にでかいデータの移動やチェックがあるので、その段階ではじくとよかったり、容量を確保したりするとよいです。

プログラムを作成していてこれに直面した場合はだいたいなにが原因か気づくものだと思いますが、ほかの人のヘルプではわかりにくいこともあります。
なにがどおなったときの検証が十分伝達されるかどうかによるなどの場合からです。

そもそも内部で動く部分なので、そうなった経緯と目的がわかればよいのですが、そのヒントの出どころが謎なことがあります。

設定したはずが、反映されていない = 反映されれば治るのか
設定はされているが改善しない = 動作の設定や条件に問題はないか
ほかの条件では動くのだが起こるはずがない予定のものでエラーがおこる = ファイル・データに問題はないか

のような確認ができればと思います。

ひとつひとつ確実なテストコードを準備していればいいのですが、都度どうですかと聞くことが、私は多いです。
この一文で解決ですが、ちゃんとテストコードとロードマップを用意しとけって話ですよね。
チェックシートと具体的な症例を書き込んどけって話ですよね。

post_max_size = 256M

って例文かいてたから それ反映してるかみてみようねってだけじゃあ意味不明ですよね。
反映してませんでしたね、って確認にもならなかったですよね。

反省します。ほんとに。
自分がおぼれない準備がある人だけが、飛び込んで助けろってことですよね。
私何回死んでるんだか。

進捗を管理しましょう。

担当@みしお 開始日:2017年10月03日

進捗を管理しましょう。
これは本当に大切です。

しかし進捗というと、進行状況が捗っているかなので「元気?」とか「大丈夫?」に近いものがあります。
大丈夫じゃなくてもやらねばならぬときもありますし、つい「元気」と返事してしまっても元気でないこともあります。
なので進捗、というのはあまり私個人としては好んで使いません。
「状況どうか」というのが一般、にならないかなあと「今日も一日がんばるぞい、って私が最初に言い始めたってことにならないかなー」程度に思っています。

まずなにより状況を把握しなくてはどうしていいのかわかりません。
まさに「どうしていいのかわからない」状態になります。そんなときにはどうしてもいいわけがないので、どうもせずまず観察です。
それを人に伝えることができるようになるまで人の背中を見ている必要があるので、言葉を覚えるように事象の伝達方法を覚えるのです。
これが無意味とか才能でなんとかなるとか人として稚拙な下積みに従事させるのはどうかとか、そういう意見で逆に人の尊厳をなりたつまえに奪っています。人としての尊厳をしるためのタイミングなくしてうまれながらに尊厳をしってるのは、あの生まれたててで天上天下とか言った人だけです。

すごく効率がよくなるから、とおすすめしても「すごくはなくてもいいし地味に努力してれば前にすすむからそれでいいじゃん」という人もいると思います。たしかにそれでもいいと思います。
でも進んでいるのか、取れない手段を破棄して退路を断ち続ける作業でどこかにむかっている、それはもしかしたら先ではないところに、進んではいるけど先ではないほうにかもしれない、ということもあると思います。
問題が発生したとして、さかのぼったり、反省したり、原因を追究するためには、どの時点まではどうだった、なにがあったから状況がかわったなど理解する必要があるはずです。
なんでもかんでも最初にもどって、いままでを毎回ふりかえって、という中からは学びは少なく、片付けの途中でアルバムを読みふけるがごとく無駄にしていまいます。

生まれ変わり、異世界転生ものが近年発生した文化として商品を見かけますが、あれが反省しない骨頂でしょう。もう一回もどったから、とかそれはバックアップや仕様、進捗を管理していればふだん行っているそれです。それがさもあたらしく違う世界でまたはじまる、そしてこんどはうまくいく、みたいな。文系の悪い所だけがつまった気がします。まあおもしろいですけどね。ただおもしろいだけです。
そんな進捗のプロジェクトまかされたらたぶんだれも生きてはいないです。
前にも同じ事書いて、5段階でと書きましたが本当に、理系というものの違いは足跡のこす、もとにもどれる、生ヘンゼルとグレーテルだってところです。
進捗どこかとつけなければ、いつまでたっても成果はゼロです。

本当に本当に、気が済むまで同じ話を新しいエントリに書き込みますが、「主題がなににせよ解決をみたら、トピックとじましょうよ」ってことです。
あなたの実績もゼロのままですし、違う話で関係ないトピックにたむろするのはコンビニ前にたむろする人たちと同じです。

最初はざっくり、ホームページがとかでもいいと思います。
回を重ねて、このコードのいいとこは、とかよい計算方式は、とかに進めていきましょうよ。
進言したほうもバカにされてるようなもの、となってしまいますよ。
いくら案を出しても解決してないじゃないか諸先輩方、みたいなことに。
いやもとの問題から一旦解決して全然関係ない話に巻き込んでだれがバカかと品評会するようなのは共生フォーラムではなくておわらいばんぐみでしょう。たのしければいいじゃない、というならこまって高い金払ったサーバーがうごかないんですとあたふたしてる姿みてるだけのほうが楽しいですよ。一緒に問題を解決してあなたの仕事や実績や収入をあげてくのにお手伝いとかしたくないですよ。たのしくないですよ。
問題を解決するということは、解決手段をあらためて知ることや確認することやまとめることに非常に役立ちます。
それも失ってただ会話をつづけるだけになるのは本当に残念です。

ね、なににせよ解決と見切って、解決済みにして、あたらしトピックで、さらに前進していきましょうよ。

私も、部署をまかされる立場になって、これをいかに伝えるかでなやみます。言葉でそのままつたえてもちゃんと聞いてくれているけど、言葉がわかるということと行動様式が変わるのは違うものだと肌身で感じます。熱心に完遂を目指してばかりではなく、そういうことについてもどこかで進捗を管理しないといけないものなのだなあと、思ったりもするのでした。

つたえること

担当@みしお 開始日:2017年09月28日 更新日:2017年09月28日

伝える教える育む、それぞれむつかしいと思います。
人それぞれに手段や過程が違っていて、聞く側もおなじくらいむつかしいので、それ自体はただつぶやくこととどこかに漂着する率が、目的地への近さが二乗で困難だと思います。
相対性理論を思い出しますが光速を基準とできるものとちがって一言で達成してしまう人や繰り返して次の日からできる人もいます。

何が最も良いかというのはでないと思いますが、自分が行動するにあたって方針というのはそれぞれみなさんにあると思います。
座右の銘、という名称を有効活用したいところです。

わたしは計画立案については、まず半分で振り返りと方針の再計画の必要性について検討するようにします。
その前期を2つにわけて、完遂予定までを2つにわけます。前2期と後2期と、確認回、アニメでいうところの番外編などが入るところをつくります。
いつまでもおわらない作業や継続案件も、期間などを決めてとりあえず5にわけます。ゴトビのあれですね。

自分自身の理解と能力向上のためにいろいろな考えを提示したりするのですが、すぐコードとか貼って即効性を求めたりすぐ結果を欲してしまいがちです。
これは情報を出す側もそうですが受け取る側も、相互に素早い問題解決を望んでいるはずだと思うので、良いことだと思うのですが。
良いことだと思うのですが、時と場合によって出力を調整して以降に発生しうる問題も先に解決策を準備する時間を情報伝達に含めて利用するというのも大事ではないかなと、最近思うのです。
そのうちわかる、大人になれば、などと表現されるものに機会の損失や取り掛かりが早いに越したことはないで転覆される事柄ではあると思うのですが、視点を逆にしてみたいようになりました。
いますぐ教える、が機会の有効利用なのか、今が準備だとすれば以降に発生することへの準備になるのでは、いま解決させないことが今後有効に活用できることになるのではと、思うのです。

スポーツの練習も無意味な試合を部分的にこなして、最終的に試合でそれを繰り返すその結果がでる、みたいな感じで。
努力とか苦労とかいうものも、そういう教えがどこかにあったかと思うのですが「効率化・効率化」と叫ばれて消えていた気がします。

たしかに、画像を表示するという方法についてコードを書いてこれでできるでしょというのは簡単で両者ともにすぐ解決です。
しかしすると、文字を調整したい、枠はどうか。位置を、大きさを、となったとき、いちいち全部教えるのでしょうか。
教えるのもよいですが、それは言葉遊び的に言い換えると「代行」しているだけではないでしょうか。
ならばその人がいる意味がない、教えて成功を反復させることでその人の「機会」を損失させているのではないでしょうか。

そういうわけで、問題解決について意見をするとき、これまでと現状について多く無駄に相互の理解がたかまるように努力がしたいないと思うのです。
5にわけた段階の今の、過去2をまずいつでも振り返り確認し、これからどうすべきかを検討して、行っていただくのがいいかなと。
のこり2は私が解決しなくてもいいと思うのです。私は前の2を確認していまを再確認することに重点を置きたいのです。

たしかにこれからの2段階を説明しておわり、だと楽なのですが、双方に苦労と依存が絶えなくなるかもしれないなと思ったりもします。

過去のどうしようもない話をああだこうだと情報共有するのはガールズトークっぽいですが、女子の記憶平滑化能力は冗長化という形で情報処理的には非常に有効なのではないかと思います。
男子の未来や実力や煽りといったトークで即効性や機動力を高めるのもいいと思いますがやはり下地作りがあってこそ力強い活動ができるものだと思います。

もちろん、人それぞれなので、方針はそれぞれにあって、それぞれが適所で役割をこなすのがいちばんだと思います。
私は、すこし遠回りをしてしまうのが好きなのですが、ご迷惑をおかけしてしまうかと思いますが、よろしくお願いできたらと思います。

先頭に戻る