$_GETと$_POSTで気づいた

業務中に気がついたんだけど

PHPファイルに対して「POST命令でクエリ文字列付きURL」を叩くと、$_POST['hoge']と$_GET['fuga']が同時に使えるらしい。

具体的に

bodyにhoge : hogehogeを含んだ

https://hogehoge.com/index.php?id=fuga&passwd=fugafuga

をPOSTでリクエストすると、POST bodyパラメータとクエリ文字列の２つが与えられているので、index.phpでは$_POST['hoge']と$_GET['id']、$_GET['passwd']が使えるということ。

今まで、POSTなら$_POSTだけ、GETなら$_GETだけと思っていたんだが、どうやら違っていたらしい。

なんで命令で使うリクエスト変数を分けなかったんだろうね？

参考

• $_GET, $_POSTなどを受け取る際の処理
• PHP: $_REQUEST - Manual

Androidアプリ開発を1ヶ月やってみたんだけどさ。

業務でAndroidアプリを作ってから1ヶ月が経ちました。

来年、新卒社員が入ってくることを見越して「こういうのあったなー。ちょっと面白かったなー。いまだに疑問だなー。」的なのをメモっときます。

Androidアプリ開発にあたり、僕のスキルは次のような感じ。

• Java ... 大学で半年やって、忘れた。新卒研修で1週間復習+独習した。ジェネリクスとかリフレクションとかわからないところもある。
• Androidアプリ ... 大学で2週間やって、忘れた。kotlin？なにそれ？

(以下、Androidアプリ開発のことを、特に注意しなければアプリ開発と呼びます。)

匿名クラス

こういうの。

setOnClickListenerのnewね。「え、クラスの中にクラスが書けるの！！！？？？」まず最初に思ったのがこれ。

普通にJavaやってたら使わないと思いますけど。コーディング規約にもダメって書いてあるし。

アプリ開発のリスナーは大体この形をとってますよね。なんでだろう。

考えてみた限りだと、たぶん、外部からアクセスが可能かどうか、かな。よくわからない。

クラスフィールド名

こういうの。

なんでmってつけるんだろう。違和感があるというか。Pythonしてるときもnumpy as npとかあったからな...。

とまあ、２つ驚きがあったんでメモでした。

なんか、もっと他に書くことありそうだけど。

学んだことで何かを作ることができないのが腹立たしくなってきたので、適当にAndroidアプリ作ります

— あきお (@akio_r) 2018年8月19日

最近考えているので、何かカメラアプリがつくりたいな。
ボタンアプリからかな〜？

このブログは個人の見解です。

そっと、これを貼っときます。
貼れと言われたので。

「掲載内容は私自身の見解であり、必ずしも所属する企業や組織の立場、戦略、意見を代表するものではありません。」


万が一、僕の掲載内容で誰かの利益を害したならご一報ください。善処しますので。

よい日本語の文書を書くためにはどうしようか

4月から7月にかけて、文書についての次の３冊を読んだ。

1. 「理科系の作文技術」
2. 「文章読本」
3. 「明文術：伝わる日本語の書き方」

1と3は仕事に関する文書作成法で、2は文学的な文書作成法について書かれていた。

仕事では文学的なことはしないし、1と3だけで十分かなと思ったが、そういうことを言っていていいのか？と思うようになった。

背景

研修中では、議事録、ドキュメントをひたすら書いた。プログラミングよりも重きを置かれていたと思う。というのもそういうSIerな会社だからだけど。

この議事録やドキュメントを書く仕事は、想像以上に技術が必要だということを思い知らされた。無駄なく、漏れなく、伝わる文書を書くことは難しい。

これは文章読本にも書いてあるが、思考から文字に起こされると情報落ちが発生して、結局100%考えていることを伝えられないのだ。だから、何回も他人に見せるし、何回も推敲する。

何が言いたいのかというと

こうやって伝わる文章ができるのだけど、伝わる文章は読まれる文章じゃないんだよなーと思う。

結局、ドキュメントを書いても読んでくれる人ってどのくらいいるんだろう。正確に伝わる文章を書いても読まれないんじゃしょうがないよな。

読まれる文章にするには、文学的な要素が入っていた方がいいんだろうなーと思う。

(これはケースバイケースなのはわかっているけど、全く勉強しないのもやばいと思う)

ただ、実務で文学的な要素が入った文書を書くことがないので、どうやったらいいかわからないんだけど。

谷崎潤一郎「文章読本」を読了

4月6日から読み始めて、5月ごろ(丁度1ヶ月)で読了しました。

文章読本の初版が1975年なので40年前の古典です。表紙も今風ではなく、文体も古めですが努力したら読めます。

動機

社内研修の敬語やビジネスマナーで困った時に先輩に勧められたのがきっかけです。

結論

な　ぜ　こ　れ　を　オ　ス　ス　メ　し　た。　

全然、敬語とビジネスマナーに関係なかった！！

でも、得るものはあったので、書き残しておきます。

どういう本なのか

「理科系の作文技術」は以前読みましたが、「文章読本」は毛色が異なります。「いかにわかりやすく簡潔に書くか」よりも、引用すると「日本人が日本語の文章を書く心得」を目的としています。「伝える文章」から「読まれる文章」といった感じでしょうか。

例えば

「どこで読点(、)を打つべきか」

「文中の漢字にルビを振るべきなのか」

「正確に物事を表現するには、どう書くべきか」

「そもそも、言葉がうまく伝わらないのはなぜなのか」

といった問いに対する答えが書かかれています。

とはいっても、全てにおいて正解ということもなく、谷崎の指針といった感じです。

あまり多くは語れないので、記憶に強く残ったところを挙げておきます。

• 「思ったことを言葉で正確に伝えるのは不可能。言葉の型にいれるため絶対に齟齬が発生する。そもそも日本人は国民性として昔から寡黙で自信を謙遜することを美徳とする。一方、西洋人は自己を主張することが美徳とされている。この点において、日本人は西洋人と同等ではなく、考え方も異なると頭に置いておく。科学においては西洋からの文化なので、正確さや主張をするのがよい。小説においては日本人に向けて書くのなら、日本人が美徳とする書き方が良い。」
• 「文法は西洋の科学であり、日本はそれを取り入れたけど、そもそも区分が当てはまるものではない。日本語は文法に曖昧性がありすぎて、そこが良い。文法にとらわれすぎるよりも、流れを感じた方がいい。」
• 「送り仮名については、たとえ文法に反しても、読み間違いを防ぐ書き方をした方が良い。読者に親切にしては際限がないため、ある程度の常識やセンスのない人は置いていったほうがいい。読者に親切すぎるのはかえってよくない。」

僕には、まだその心はわからないなぁ。

TDD+モブプログラミング会に参加してきた

5/13(日)のtddyyx(てぃーでぃーでぃーわいわいかい)に参加してきました。

10分くらい遅刻しましたが、心理的安全性が保たれた素晴らしい会でした。ごめんなさい。

何をしたのか

tddyyxでは、テスト駆動開発とモブプログラミングで問題を解決します。

• テスト駆動開発は、間違いを恐れず言うと、テストを書いてからプログラミングする開発方法です。
• テストに通らないコード(Red) -> 通るけどリファクタリングする必要があるコード(Green) -> 通るし綺麗なコード(Blue)の順に実装していく。
• モブプログラミングは、間違いを恐れず言うと、一つの問題についてチーム全員で解決していくプログラミング方法です。
• 作業分担は効率が良くなるように見えるけど、後に作業集約することを考慮すると良くないかもしれない。
• モブプログラミングは作業分担しないため進みが遅いように見えるけど、全員が共通したコンテキストで動くので最終的には効率が良いかもしれない。
• モブプログラミングはドライバー(コードを書く人)とナビゲーター(周りで調べたり知恵を出したりする人)に別れて作業する。ただし、コーディング時はモニターは同じものを見る。
• 問題の一部でも解決したら「やったー！」と言う(重要)。
• 問題というのは、FizzBuzzやLeapYear(うるう年)のようなプログラミングするとよく出てくるお題のことです。

今回は前半を３チームに分かれて別々の問題を解きました。後半は自由にチームを組んで好きな問題を解きました。

前半戦

@y0taさん、@hirarinさん、@ie_tetrahymenaさんと一緒に100Doorsを解きました。使用したのはCyber-dojoです。言語は参加者みんな初めてのR。

• 仕様からのタスク分け -> テスト書く -> 実装する -> 動く -> 「ﾔｯﾀｰ!!」 -> 以下テストから繰り返す。

以下学び

• タスク分けに設計の話と混ざるとハマりそうなので避ける。
• Rの文法が風変わりで楽しい。配列が作れない、三項演算子ができない等等。
• ネストが3つ以上あると気分が悪い。できるだけ2つまでにする方法を考える。
• 関数の挙動に注意。副作用の話。
• 定期的におこる「ﾔｯﾀｰ!!」はモチベの回復になる。楽しい。
• コーディングに自信がなくても学び合うことでカバー可能。(メンバーの人柄によるかも)
• 自信がない、わからない、と正直に声をあげることが重要だと思う。
• お菓子大切。喜久福美味しかったです。

後半戦

ごめんなさい、一緒にコーディングしたのに名前を忘れました...。後半はLeapYearをやりました。前半戦と同様にCyber-dojoを使用しました。時間が少なかったので言語はみんな大好きPython。

以下学び

• 文化の違いをどう解決するか。チームによって問題へのアプローチ(僕たちの場合はタスク分けから先)が違っていたので、最初にどうやってきたのかをお互いに聞くべきだった。
• 地味にPython忘れている。悔しい。
• 「ﾔｯﾀｰ!!」は重要。

おわり

以上、楽しいコーディングイベントでした。

モブプログラミングはモブ+プログラミングなのでプログラミングではない別の作業でも活用ができる。モブの考え方は原始的だけど、作業が複雑になっていたり知識や経験がない状態からスタートアップする方法として頭においておくのが良さそうです。

あと、けん玉が少し上達してよかったです。

モブけん玉の様子

風邪っぽい

社会人初の風邪という実績を解除してしまいました。

原因として考えられるのは、

• 電車でうつされた
• 窓を開けていたので部屋が乾燥した
• 緊張からある程度解放された

かな。

うがい、手洗いを毎日していなかったのはダメだったかと。

というわけで、ご飯たくさん食べて、薬飲んで、お風呂はいって寝ます。

予防策としては、

• うがい、手洗い
• 人混みではマスクをつける
• 栄養をとる
• 体力をつける

くらいかな。