がるの健忘録 このページをアンテナに追加 RSSフィード

2018-07-01

[]情報の扱い方

元ネタは仏教なのですが。

Kesamuttisutta(ケーサムッティ・スッタ)とかKālāma sutta(カーラーマ・スッタ)とかKalama sutta(カラマ・スッタ)とか呼称されているようです。

Aṅguttara Nikāya, Tikanipāta(増支部三集篇)に収録されているもの、だそうです。

http://www.horakuji.com/BuddhaSasana/Ekayana/kesamuttisutta/index.htm


ここにある考え方が、大本としては「仏教の根本的態度を簡潔に説きあかす至宝の経典」なんだそうなのですが。

端的に「エンジニア(以外も含む)が、情報を取り扱う」時の心がけとして、大変によろしい感じだなぁ、と思っていたので。

まぁおいちゃんは「蝉丸Pのつれづれ仏教講座」でこれを知ったのですが(笑

蝉丸Pのつれづれ仏教講座

蝉丸Pのつれづれ仏教講座

なんか、ず〜〜〜っと「書きたい」と思っていたので、ふと、このタイミングで。


これは十の憲章(根本的なとりきめ)というのがあるようで。

曰く

・風説に依らない

伝承に依らない

・伝聞に依らない

聖典集の所伝に依らない

・推論に依らない

公理(定式化された理解)に依らない

類比に依らない

・深慮され達された結論への同意に依らない

・有能そうな者の言葉に依らない

・その沙門が(我等の)師であるという理由に依らない

という項目だそうです。


噛み砕いて。

http://www.horakuji.com/BuddhaSasana/Ekayana/kesamuttisutta/2.htm#AA

読んでみると、まぁなんていうか色々と痛みを伴う文章でございます(笑


どこかでこの辺、しっかりと考察できるとよいんだけどなぁ。

まずは、ご紹介まで。

2018-06-03

[]フレームワークで「使われてる関数&クラス&メソッド」簡単に調査してみた

すんげぇ斜めに調査。

一旦の対象は、cakePHP、Laravel、CodeIgniter、Slimの4種。

ちと前に「その当時の最新版」をインストールした環境が残ってたので、一旦はそれつかって簡単に確認。


「全フレームワークで使われている関数&クラス」と「各フレームワークの使用量上位」。

調査には https://github.com/gallu/little-tools/blob/master/php_used_function_analysis.php 使いました。

やり方はおおむね


php php_used_function_analysis.php laravel_test/vendor/ > laravel

php php_used_function_analysis.php CodeIgniter-3.1.0/system/ > codeigniter

php php_used_function_analysis.php cake_test/vendor/ > cake

php php_used_function_analysis.php slim_test/vendor/ > slim

こんな感じ。

大体、各フレームワークのvendor配下のブツをまるっと調査対象。


細かい分析とかバージョンの変更とか種類の追加とかは後日やるとして、今回は雑感と生データだけ。


「全体で使われてる子たち」を見ての雑感

ReflectionClass、ReflectionObject あるなぁ、と。この辺は「フレームワークならでは」なのかしらん??

class_existsとかちょっと下がってfile_exists、interface_existsとかproperty_existsとか同上。

is系の型チェックも各種取り揃え。

mt_randも興味深く。

version_compareもあるよねぇ的な。

extension_loadedも結構ちゃんとチェックしてるのねぇ。

usleepへぇ。

__destructが「全部のフレームワークにとりあえず存在している」のも興味深く。いやおいちゃん的には好みな方向なのですが。

register_shutdown_functionもあるかぁやっぱり。

clearstatcacheが「全部のフレームワーク」で使ってるのか興味深い。

memory_get_usageとかあるやっぱり気になるんだねぇ。

ctype_digitとかctype_alphaとかctype_alnumとか、おいちゃんは好みだけど、へぇへぇへぇ。

is_uploaded_file & move_uploaded_file も地味に健在w


フレームワークは………まぁ「コード量」が違うから色々とあるなぁ、的な。


全域で使われてる子

class method__construct
classException
functionsprintf
functioncount
functionsubstr
functionis_array
functionpreg_match
functionstrlen
classDateTime
functionstr_replace
functionarray_merge
functionstrpos
functionimplode
classRuntimeException
functionis_null
functionis_string
functionin_array
functionexplode
classstdClass
functionfunction_exists
functionfunc_get_args
functionget_class
functiontrim
functionstrtolower
classReflectionClass
functionclass_exists
functionmethod_exists
functionarray_map
functiondirname
functionpreg_replace
functionarray_keys
functionarray_key_exists
functionmt_rand
functionis_object
functionfile_get_contents
functionstr_repeat
functioncall_user_func
functiontime
functionarray_pop
functionarray_shift
functioncall_user_func_array
classPDO
functioncurrent
functionarray_values
functionfile_exists
functionrewind
functionfopen
classDateTimeZone
functionreset
functiondefined
functionstream_get_contents
functiontrigger_error
functionunlink
functionkey
functionord
functionis_callable
functionrtrim
functionrealpath
functionversion_compare
functionstrtotime
functionarray_replace
functionserialize
functionfclose
functionunserialize
functionis_dir
functionchr
class method__call
functionis_bool
functionsort
functionini_get
functionis_numeric
functionflush
functiongetenv
functionfwrite
functionis_int
functionvar_export
functioncopy
functionpreg_split
functionpreg_quote
functionarray_unique
functionbase64_encode
functionarray_slice
functionis_resource
functionstrtoupper
functionarray_unshift
functionfread
functiondate
functionmicrotime
functionintval
classerror
classBadMethodCallException
functionerror_reporting
functionpreg_replace_callback
functionextension_loaded
functionfile
functionset_error_handler
functiongettype
functionfunc_num_args
functionstrtr
functionob_start
functionjoin
functionend
functionis_file
classReflectionObject
functionucfirst
functionstrrpos
functionltrim
functionmkdir
functionhexdec
classUnexpectedValueException
functionfilter_var
functionarray_flip
functionarray_diff
functioninterface_exists
functionini_set
class method__get
functionbasename
functionpreg_match_all
functionarray_reverse
functionhash
functiondefine
functionmb_strlen
functionusleep
functionbin2hex
functionrename
functionheader
functionis_scalar
functionexec
functionhtmlspecialchars
functionglob
functionmb_substr
functionmd5
functionsubstr_count
functiontouch
functionproperty_exists
functionis_readable
functionis_subclass_of
functionstripos
functionround
functionis_float
functionrmdir
functionpathinfo
functionksort
classDateInterval
functionescapeshellarg
functionfloor
functionfeof
class method__destruct
functionerror_get_last
functionuniqid
functionfunc_get_arg
functionhttp_build_query
functiondate_default_timezone_get
functiondebug_backtrace
functionarray_search
functionconstant
functioneach
functionis_writable
functionchmod
functionarray_intersect_key
functionmb_convert_encoding
functionsubstr_replace
functionflock
functionextract
functionrawurlencode
class method__isset
functionob_get_level
functionfgets
functionget_resource_type
functioniconv
functionbase64_decode
functionshell_exec
functionregister_shutdown_function
class method__set
functionob_end_clean
functionvsprintf
classdirectory
functionset_exception_handler
functionarray_intersect
functionabs
functionceil
functionprint_r
functionparse_url
functionstrncmp
functionftruncate
functionaddcslashes
functionarray_sum
functionarray_walk
functionparse_str
functionmb_strtolower
functiongmdate
functionclearstatcache
functionmb_strpos
functionwordwrap
functionarray_replace_recursive
functionmemory_get_usage
functionget_object_vars
functionstrcasecmp
functionstrstr
functionctype_digit
functionerror_log
functionstream_set_timeout
functionctype_alpha
functionstr_ireplace
functionob_get_contents
functionarray_change_key_case
functionmail
functionctype_alnum
functionstrcspn
functionis_uploaded_file
functionmove_uploaded_file

cakePHP 3.5.5

functionvar_dump67683
functionsprintf1518
class method__construct1142
classException1108
functionsubstr918
functioncount797
functionis_array698
functionstrlen664
classRuntimeException648
functionFile617
functionstrpos604
functionpreg_match595
functionimplode570
classInvalidArgumentException568
functionstr_replace524
functionin_array498
functionstrtolower423
functionexplode392
functionis_string380
functiontrim375
functionstr_repeat372
functionarray_merge360
functiondirname259
functionpreg_replace238
functionarray_map227
functionarray_keys213
functionrealpath201
functionfile_put_contents195
functionend195
functionfile_get_contents188
functionis_dir185
functionfile_exists184
functionrtrim183
functionarray_pop173
functionfunction_exists160
functionarray_filter158
functiondefined156
functionarray_key_exists153
functionget_class153
functionclass_exists146
functiondefine145
classLogicException140
functionrewind140
classError137
functioncurrent137
functiongetenv136
classPDO134
functiontrigger_error133
functionHash129
functionstrtoupper128
functionLink127
functiontime125
functionmax122
functionis_numeric120
functionis_object118
functionLog114
functionkey105
functionarray_values104
functiongetType103
functionextract102
functionmkdir102
functionputenv101

CodeIgniter 3.1.0

functioncount281
functionis_array243
functionfunction_exists207
functiondefined187
functionstr_replace130
functionpreg_match124
class method__construct119
functionstrlen118
functionstrpos117
functionsubstr109
functionin_array103
functionimplode99
functionpreg_replace89
functionstrtolower88
functionfile_exists87
functiontrim81
functionstrtoupper72
functionsprintf52
functionpack47
functionclass_exists47
functionexplode46
functionis_string46
functionarray_keys44
functiondate44
functionis_int41
functionis_object37
functiontime36
functionrtrim36
functionis_bool31
functionmd530
classstdClass29
functionord28
functionsscanf26
functionis_numeric26
functionis_resource26
functionarray_merge26
functionheader23
functionversion_compare23
classdirectory22
functiontrigger_error22
functionpreg_match_all21
functionctype_digit21
functionmb_strlen21
functionstripos21
functionmethod_exists21
functionpreg_quote21
functionhtmlspecialchars20
classerror20
functionis_dir20
functionini_get20

Laravel Framework 5.5.20

class method__construct1816
classException1480
functionsprintf1299
functioncount785
functionsubstr701
classInvalidArgumentException651
functionis_array494
functionpreg_match474
functionstrlen457
classDateTime447
functionstr_replace436
functionAssert422
functionarray_merge421
functionstrpos414
functionimplode412
classRuntimeException409
classGenerator393
functionis_null363
functionis_string361
functionin_array326
functionexplode320
classstdClass318
functionfunction_exists315
functionfunc_get_args305
classClosure304
functionget_class302
functiontrim278
functionstrtolower239
classReflectionClass233
classReflection231
functionclass_exists214
functionmethod_exists212
classgenerator205
classLogicException192
functionarray_map191
functiondirname189
class method__toString183
functionpreg_replace177
functionarray_keys174
functionarray_key_exists160
functionmt_rand153
functionis_object152
functionfile_get_contents151
classError151
functionstr_repeat148
functioncall_user_func147
functiontime141
classERROR136
functionrange135
functionarray_pop132
functionarray_shift130
functioncall_user_func_array128
classPDO125
functioncurrent123
functionjson_encode119
functionarray_values118
functionfile_exists114
functionrewind114
functionFile114
functionfopen113
classDateTimeZone113
functionarray_filter111
functionreset108
functiondefined108
classDOMDocument103

Slim 3.?.?*1

functionsprintf499
class method__construct450
classException332
classstdClass258
functioncount236
classReflection215
classInvalidArgumentException182
classDateTime178
functionis_string163
functionsubstr162
functioncall_user_func_array161
functionfunc_get_args161
functionget_class147
classRuntimeException134
functionAssert126
functionis_array122
classERROR120
functionstrpos118
functionpreg_match118
classReflectionClass111
functionstrlen106
functionimplode94
functionarray_merge92
classDateTimeZone85
functionis_object83
class method__toString82
functionstr_replace79
functiondirname79
functionclass_exists76
functiontrim74
functionrange73
functionjson_encode67
functionin_array67
functionis_bool59
functionexplode57
functionmethod_exists56
functionfile_get_contents51
functioncurrent49
functionarray_keys48
functiontrigger_error47
functionarray_shift44
functionfopen44
classDOMDocument37
functionlog37
classArrayObject37
functiondefined37
functionstrtolower37
classSplObjectStorage36
classReflectionMethod36
functioncall_user_func35
functionversion_compare35
functionfread34
functionarray_map34
functionis_resource33
functionfile_exists33
functionfseek32
functionvar_export32
classgenerator31
functionfunction_exists31
functiondate31
functionkey31
functionis_null30
functionjson_decode30

*1:バージョン確認の仕方が不明でした……

2018-06-01

[]「簡単な修正」?

いや何気なく呟いたのが、予想を遥か彼方に超えてバズったので(笑

https://twitter.com/gallu/status/1001665229087039488

なんかよっぽど皆「色々あるんだなぁ」と思いながら、色々あるんなら「少しかみ砕いて言及してもよいかなぁ」と思いまして、一筆。


まぁ勿論「色々な角度から色々な意見がある」のが基本ではあるのですが。

どちらかというと上述呟きに「うなずいている」方向の意見が多いあたりに、色々と思うところ、あり おり はべり いまそかり 、的な感想を持ったのが初手でございます。

………まぁみんな苦労するんだよねぇきっと。

ただ一方で「上述呟きへの異論」もあって、まぁ「……………ふぅん」ってのもあれば、そうではないもうちょっと考察したいような内容もあったので、その辺を改めて。


端的に、上述のつぶやきは、まぁぶっちゃけると「そこそこ空気感が険悪になった」ケースで出てくることが多いです。

「今、Just now」はンなことない状況と環境で大変にありがたいのですが、過去には、まぁ以下検閲削除*1


とりあえず「雰囲気と空気が明るく輝いているlight(軽量)でlight(光)な」あたりから、ゆっくりと光量を落としていきましょうw

一旦の登場人物は

・お客様 or PM(依頼する人):一旦、PM

エンジニア(作業する人)

の2種類。細かく噛み砕いても面倒なんで、ざっくりと。


………ん、この「光量が多い」状態でPMが「これ簡単だから修正しておいて」は、あんまり言わない気がする。記憶している限りでは、多分「そういった発言はなかった」。

身も蓋もないのですが。


あった、と仮定すると………PMの「エンジニアとしての」力量その他次第、かなぁ。


近しい発言として「これ、軽微な修正だと思うのですが、どうですか?」という質問なら、まぁそれなりにあって。

その辺の目測が「9割がたあっている」程度に中身を理解しているPMからの、ある程度の流れを経てからの「これ簡単だと思うから」なら、信頼できるような気がする。


一方「軽微なのも面倒なのも」いっしょくたに「簡単だよね」言われると……わりと「急速冷凍」で「関係性が冷え込むなぁ」ってのが、今までの雑感。


ちなみに「面倒なもの」の何割かは、例えば「クラス切りの失敗」とかその辺に、つまり「作業者のスキル」に起因する事もあって、その場合「ちゃんとそれを指摘できれば」っていう例外則はあったりする。

ただ、その場合は「どのように切るべきだったか」に加えて「じゃぁどのようにリファクタしていくか」くらいまで提示できないと、色々と難しいかなぁ、とか、履修項目が増えたりはするように思われます。

そもそも「作業者にどれくらいのスペックを要求していて、そのためにおいくら万円ほどの単価で雇ってるのか」にもよるわけですしおすし。

その辺をあんまり考慮せずに「安い単価で低スキルなメンバーを雇ってからのハイスペックな要求」は、それはそれで如何なものかなぁ、的な感想も、あったりなかったり。


さて「冷え込んだ」側は一旦棚の上に置いておくとして。

依頼者が「なんでそーゆー依頼の仕方をするのか?」を、少し考えてみたい。

………おいちゃんはそーゆー依頼の仕方をしないので、予想と推論なのだけど*2


一つ身もふたもないのが「技術力とか知識とか経験とかスキルとかがないから、そもそも難易度が図れない」。

ちゃんと「該当技術の基本を理解したうえで現状の実装まで把握してそのうえで言っている」んなら、フルスイングでこられても、一定の納得感が出てくる可能性が一定確率で存在するのですが*3

「該当技術は理解しているけど現状の実装は把握していない」場合、どっちが悪いのかはともかく「該当技術的には容易なんだけど、現状の実装の都合上はちと難しい」可能性が出てきて*4

「該当技術すら理解していない」場合は「言ってる内容がそもそも難易度が高かったり下手したら不可能に近かったり」なんてケースも以下略。

で、この辺で下手に安請け合いして「思ったより時間がかかった」りすると、大概「簡単にできるっていったのに何でこんなに時間がかかるんだ!!」とかいう文句ばかりが出てくるので、基本、安請け合いしてよいことなど、何一つとしてありませぬ。


これに少し加えて出てくるのが「スケジュールをちゃんと見てない」ケース。

時々話をするのですが「0.1を10個重ねたら1になります」ってお話なのですが、これがタスクになると「1時間のタスクを10個積んでも2時間くらいで片付くと思っている」ってケース、が、一つ。

次が「一人あたり2時間くらいのタスク」を、一人めがけて10人くらいが投げつけるとその人はパンクするのですが、各人が「なんで2時間のタスクで1日つぶれるんだよ」とか言う発言になって、DDoSを体験できるよいチャンスでございます(嬉しくない)。

もうちょっとこれが進むと「一人DDoS」とかが出てきて「さっき依頼したタスクの事とかすっかり忘れて」依頼者が一人なのにDDoSのごときタスク積みとかをやってきたりすると色々と以下略。

この辺を考えるに、redmineその他「一目で見えるスケジュール管理」は大切で、かつ「そのルートを通さない依頼ははねつける」勇気がまた、大切なものでございます。


……ってな問題が、勃発したりしたり。


もう一つ、上述と合わせ技で出てくることがあるのが

・「簡単である」という事にして、工数(コスト(金/時間) )を削減したい

っていう方向性。

これは「軽微な修正だから今のスケジュールは調整せずにそのまま積んでもいいよね」っていう角度とか、「軽微な修正だから追加費用はいらないよね」とか。

チリだって積もれば山になるんだし、そのためには当然ながら「相応のコスト」はかかるものなので。

そっちやらせるんならリスケするし、「軽微だから追加だけど支払わない」とか言い出すんなら下請法とか持ち出すよ?

的な。

この辺がくると「*5防御的開発」になるので*6、双方にとって基本「負けパターン」になりますので、色々と注意が必要。


んで。

上述は、端的に「依頼する側としては踏み倒したい」事象で、一方「作業する側としては"踏み倒されたらたまらん"」事象になります。

まぁ、その辺が認識の乖離なんじゃないかなぁ、と。

あ「作業側だけど踏み倒されてもよい」って思ってる人は「ガチなのをやられたことがない」可能性とかが微妙に想起されるのですが、まぁ「発注者にとって都合のよい技術者」という方向性を否定はしないので、頑張っていただければなぁ、と。………過労とかで死なない程度に*7


その辺を考えると。

……まぁお客様が「簡単な修正だよね」とはあまり言ってこないのと、言ってくる場合は高確率で「状況その他は把握していない上でこちらに敬意を払っていない」のがほぼ確定なので*8

初手の1回目2回目くらいは苦笑いしながら「少し工数かかりますねぇ」とかいうお話で色々匂わせたりするのですが(詳しくは後述)、回数が重なれば対応がしょっぱくなります。


それが「PMが言った」になると、まずは周辺の確認から、ですかねぇ。

修正箇所や方法をどれくらいまで想定しているか、周辺への影響、テストについて、作業割り込みに対するリスケ、その他諸々。

ちゃんとその辺が「整った上での指示」なら、普通にあり。まぁ「修正箇所と方法」について、色々と質疑応答とかはするかもしれないけど。

その辺がちゃんとしてなかったら、割と本気で「簡単ならご自身でご対応ください」って言いますねぇ。簡単だもんできるよね? コード修正して、テストして、プルリク作るくらいできるでしょ??


指示出しって、真面目に考えると「ある程度のコミュニケーションコスト」がかかるもの、なので。

どっかに「リーダーシップがない人ほど、指示が雑で忖度を部下に期待する」もの、らしいので。でもITとかで「忖度とか行間読みとか期待する」時点で、色々と違うんでないかい? 的な。


んで。

上述を前提に、いただいてたレスやら引用ツイートやら見ると、色々と味わい深く。

肯定意見についてはまぁ「みんな色々あったんだろうなぁ………」と、背景を想像するに涙を禁じ得ないような状況しか思い浮かばないので、反対をいただいたご意見をメインに。


「お前なんかに頼まなくても代わりはいくらでもいる」とかいう豪気なツイートがあって……えぇ、まぁ「お代わりできるんなら、いいよなぁ」と、しか(笑

個人的には。まず「本当に代わりがいるんだろうか?」で、第一ハードル。「お金を払えば」って選択肢もあるんだろうけど「お金払った程度ではどうにもならない」スキルレベルとか、色々あるしなぁ………的、な。

で、その辺の高いハードルを乗り越えて、たとえそれが事実であっても。「お前の代わりはいくらでもいる!!」とかいう相手とのお仕事は、色々としんどそうなので、全力で回避したいなぁ、と思うのですが。まぁ「お代わりをする」側としては、色々と便利だったり使いやすかったり使い潰しやすかったりするんだろうなぁ、っと。


「客なくすんじゃね?」「客と喧嘩したいの?」といった引用RTが、ちらほら。

いきなり「短刀でえぐる」ような言い方はさすがにしませんよ?w

とりあえず初手は、優しく柔らかく、丁寧に説明します。「慣れてないお客様」とか、普通にいらっしゃいますし。

ただまぁ合わせて「決めつけず、質問をしよう」って話は、初手から教育入れるかな。そこでご理解いただければよし、ご理解いただかなければ、対応の塩分濃度が上がるだけなので。

PMだと………お説教からstartかなぁ割と本気で。最近は「説教する前に見限る」という、困った方向性になりつつありますが。


ちなみにおいちゃんの最近のガチ対応は

・見積もりを出す:スケジュールと金額

・現状のスケジュールをリスケ

で出して、OKが出たらやるし、OKが出ないんならやらない。という、シンプルにデジタルな判断w

まぁこの辺があるんで「あらかじめバッファを取っておく」んだけどね。見積もり時点で「バッファを値切る」と、この辺で大変な事になりますw


まぁ、お互い、突き詰めたら「ビジネス」なんで。

「ちゃんと、正当と思われる程度のお足をいただける」んでしたら、原則としてはお断りする理由もないですし*9

「お足がでない」んなら、別段「サービスをする」理由もなく、結果として「お断りをさせていただく」のが、基本的な流れになります。


……えぇまぁここでまぁ「次回とか将来とかよい案件回すから今回はサービスしてよ」とかいうお話もちょいちょい出てくるのですが。今まで「そーゆー相手から"本当においしい案件が次回とかに出てきた"試しがない」ので。

「今回ちゃんとお支払いいただいたら」「次回、ちょっとだけその辺サービスしますよ」ってのが、本音ですかねぇ。ってか、まっすぐに言います。

「裏を返さない恥晒し http://d.hatena.ne.jp/gallu/20110224/p1 」とか……書いたの、8年も前なのかwww

勿論「本人、うそをつくつもりはなくて本当に"次回とか"支払いたい」って思ってるんだと思うのですが*10

ただまぁそーゆー懐事情のところが「次回はよい案件」の可能性を持っているか? って考えると「次回もタイトで安い案件」である可能性のほうが、十分に可能性としては想起されるので。

間柄が険悪でなければ「安上りにすます方法」の提案はしますが、お値引きは原則として受け付けておりませぬ、的な感じになります。

まぁつまり「お金がないなら無いなりの工夫に対する提案」はしますけどね*11


あと、肯定的意見なのですが、これについてはちょいと言及したく。

https://twitter.com/gaze_he_z_me/status/1002212369433440256

制作に技術が必要なのはもちろん「依頼の仕方」にも技術が必要ですね。。。発注やディレクションは相手に敬意を持って伝え方に気をつけなければならない

ものすごく大切なポイントだと思うのです。

「丸い卵も切り様で四角 物も言い様で角が立つ」とか、言いますし。

いやもちろん「丸くとも一角あれ」とも言いますが、4角も8角も108角も持つ必要はないので。

勿論これはエンジニア側にも言えて「いきなり角の立つ物言い」というのも、相手が傷ついたりへこたれたりするので。

双方とも「相手に敬意をもって」、相手の立場に立つ……とまでは言わないにしても「相手側の目線を意識する」くらいのところは持っていたいところでございます。


個人的には

・相手の知識分野等に敬意を払う

意味を含めて、まずは

・「質問」しよう

って思うんですが、その辺、どうなんですかねぇ? 的な。

決めつけても、あんまり良いことありませんぜ??


とかとか、つぶやきでは書ききれない諸々を、少し書いてみました。

*1:「引きが強い」とか言わない

*2:「やらかされた経験から」とも言う

*3:作業者があんまりにもあんまりだと、稀に、やります

*4:もちろん「作業者がちゃんと作れば」ってのはあるんだけど「レベルと金額の問題」とか「割と無理してもらってる」とか色々な要因があり得るので、一概にどっちが悪いとはいえないケースが多いような

*5:徐々に、あるいは可及的速やかに

*6:そのうち書きます

*7:昨今のおいちゃんが言うと「シャレにならんレベルでリアル」なんだがww

*8:敬意があれば「軽微/簡単ですか?」といった質問から入ってきます

*9:体調だけは考慮したいものでございます……自戒

*10:思ってなければただの詐欺

*11:「提案料とって無いじゃん」については………悩ましいところなのですが。まぁ一応「その辺も込みで今回の開発を受注した」と思うようにしております……ヨクナイ気もするんですが……

2018-03-21

[]業務にシステムを合わせるのか? システムに業務を合わせるのか?

ふと何気につぶやいた程度の話だったのですが、思ったより膨らみそうなので、膨らませてみる(笑

いやまぁ結論は「程度問題」なんだろうなぁ、とは思いつつ。じゃぁ「どの程度」が「よい程度」なのか? ってのもあるので、このあたりは論考してみても面白いんじゃないかなぁ、と。


いつも以上に、っていうか多分今までになく「とっちらかったまま」書いてるので、文章に不安定なところや毒やその他諸々が含まれますので。

容量用法を適切にまもってお読みくださいませ。


直接的なネタとしては「Webアプリケーションフレームワーク」回り。まぁおいちゃんなんで、PHPの。

ただそこから少し「経営回り」のお話が絡んでくるので、そんな感じで色々なレイヤーをまぜこぜにしつつ。


直接的には、直近使ってるLaravel(5.5)が、そうで。

Ruby on Railsなんかでも聞こえてきて、それ以外のフレームワークだとFuelPHPなんかで感じて。………cakePHPは、がっぷり四つに組む前に魔改造してたから不明(笑

なにかってぇと「フレームワーク特有の縛りと固有のノウハウが結構面倒」。

もちろんこの辺はトレードオフなので、ってのはあるんだけど。


ん……少し暴言を吐くと「0からがっちょり(セキュリティ回り含めて)組める面子でそろえられるんなら、フレームワークを使わない」って選択肢が、脳内によぎる程度。

ちなみにその辺の観点からSlimが最近わりと気になっていて、今度がっぷりやってみる予定……ってのは、余談。

あと「テンプレートエンジン」は、なにか、は、大概使う。「シンプルな機能」だけなら、どのテンプレートエンジンでも「大体同じような機能を提供している」から、学習コスト低いし。

Twigが結構気になってるんだよなぁ、その辺としては。

もちろん「素のPHPをテンプレートエンジンに使う」でもよいんだけど、いくつかの観点から、テンプレートエンジンは使いたい事が多いかなぁ。「中にPHPコードが書けないようにする」的なギミックがあると個人的にはすげぇ嬉しかったりするんだが*1


話を戻すと。

上述は「0からがっちょり組める面子でそろえられるんなら」って前提なので、「そんなメンバーばかりではない」場合は、もちろんフレームワークを使って「提供された機能を使う」ほうが楽なケースも多々。

あと、「0からがっちょり組める面子でそろえられる」場合でも、認識合わせのルールはしっかり決めないとえらいこっちゃになるケースが多いように思われるので*2

事前にその辺の「取決め」は、大枠から細かい所まで意識合わせしないとひどい目に合う感じなので、その辺は注意。


ただまぁじゃぁ「フレームワークつかったらそんなことがなくなるのか」といえばそんなことは全然ないので。

フレームワークによって強制できる取決め」は、全体からみると割と控えめだったりするので、その辺も注意が必要ではあったりする。細かい見た目からもうちょっと致命的な記述方法まで、色々と問題が起きるしねぇ。

んでまぁこれがまた「フレームワーク使ってる"から"誰が書いてもコードが均一になる」とかいう信仰を持っている方も一定数いらっしゃるので、どっちがより深刻な事態になるのかなぁ? とか、思うところは色々。


個人的には「仕事で書いてるんならちゃんと人と足並みそろえようよ」と。

「好き勝手にコード書くのは、プライベートな趣味か、でなきゃせめて"自分が頭張ってる"時にして」って思うざます。


次。

んじゃまぁ「ある程度のルールが均一化できた」として。

次に立ちふさがるのが「フレームワーク的な制約」の諸々。端的には「素組みならさほど困らない実装」のいくつかが、フレームワークを使ったりすると「えらい事面倒」になったりする感じ。

この辺も「8割くらい*3フレームワークに従って楽が出来て浮いた工数」を「残り2割の奇異な要求で、がっつりと工数が食われる」とかいう状況になったりして、全体的なバランスがですね、えぇ。


もちろん「フレームワークのお作法をドン無視して」ってやり口もあるのですが、その場合大体は、割れ窓の法則に従って「全部が壊れていく」ので、フレームワーク使う旨味が減っていくので。

結果として「フレームワーク、使わなかったほうがよかったんぢゃね?」とかいう状況になって、それはそれでど〜なのかなぁ? と。多分選択肢としては「劣悪」な部類だと思う。


で、この辺になってくると気になる一つ目が「そのフレームワークの作り」と、次が「そのフレームワークに対する習熟度」。

ちなみにその観点で、Laravelは、作りとしては面白いんじゃないかなぁ、と思ったです。

「知らないと出来ない」の塊ではあるにしても、「知ってたら、ある程度介入出来る箇所も多い」ような印象は受けたので。

Zend Frameworkは「そもそも縛りがほぼない」から、この辺については楽だったなぁ………それ以前の問題が山積み過ぎて困ったけど。

CodeIgniterもその辺の縛りはシンプルだったような気がする……ただそれならSlimまでそぎ落としてほしいとか思うので、色々と難しいなぁ、とか思うのですが。


閑話休題


………こう考えてみると「フレームワークの縛りがギチギチで介入が難しい」ってのは、昔はあったんだけど、今は減ってきてるのかなぁ? って気は、する。気がするだけかもしれないけど。

ただ、上述のように「フレームワークそのものの処理に介入」できるようになるためには、フレームワークのつくりまでをある程度「熟知している」必要があると思われて。

端的には「新しい案件で使うからキャッチアップしませう」のレベルだと、ちょっと、そこまで踏み込むのは難しいんじゃないかなぁ、とか思ってみたり。


なんてのを色々と脳内で繰り広げていくと。

一つの疑問がふと脳内に横切るわけなんですね。


「どのフレームワークを使う?」以前に「フレームワーク、使う?」


いやまぁもちろん「対象フレームワークを熟知してから使う」ってのは、一つの真っ当な正解だとは思うのですが。

とはいえ、割とコロッコロ移り変わるフレームワークを、どこまで追いかけていくのかなぁ? と考えると、色々と思案のしどころ、ってのが一つ。

もう一つが「じゃぁ熟知するフレームワークにはどれを選択する?」って話にもなって。もちろん「今のトレンド」に合わせてもいいのですが、多分それ、5年持たないんじゃないかなぁ? と。

その辺を考えると「いずれにしても(フレームワークよりは)長期間使える知識としての"PHPそのもの"や"SQLそのもの"や"サーバ知識そのもの"を学習する」とかなんとか。まぁそこから先に踏み込むと「PHPよりは長期間使える知識としての"プログラミングそのもの"」とかになってきて玉ねぎの皮のようになっていくわけなのですが。


で……そこからさらに考えて。

おいちゃんの場合は「実案件」ベースなので。つまり実案件が「フレームワークの諸々の縛りに、何一つとしてはむかわないニーズのみ」であれば、問題の大半は解消できるんですよ*4

ただ、現実問題として、見ている案件は、大なり小なり「フレームワークのこの部分の縛りをど〜にかして業務に合わせてほしい」っていうニーズがあって。

「素直にフレームワークを使う」と迂回路を作るのに工数がめっさかかって、でなきゃ「フレームワークを熟知する」か「フレームワークを使ってる意味をなくすレベルで壊す」か、「フレームワークを使わない」か。

んで、もう一つ出てくるのが、「顧客の要求を捻じ曲げてご理解いただいてねじ伏せる説得する」っていうルートです。


ようやっとここで出てくるわけなんですね「業務にシステムを合わせるのか? システムに業務を合わせるのか?」ってお題。

Google検索で「業務にシステムを合わせる システムに業務を合わせる」なんかでも色々と出てくるんですが。

おいちゃんが見聞きしている論調としては「アメリカではシステムに業務を合わせるが、日本では業務にシステムを合わせようとするから失敗する」的なお話。


個人的には「ケースバイケース」だと思うですし、もうちょっと突っ込むと、根本的にまずいのは「業務フローを定期的に見直すルートが存在しない」事なんじゃないかなぁ? とは思うです。

一見無駄に見えるフローが「予想以上に無駄」な事もありますし B-p 、一方で「実はちゃんと意味があった」事象もあるので。正確には「ある事象を懸念してルールを策定して連絡して伝えたのにルールが無駄だと軽視された結果、懸念した事故が起きて面倒をこうむった」事とか、ま〜ま〜あります。

なので「無駄な業務」が「本当に無駄なの?」ってのは、しっかりと理由込みで継承していかにゃならんのではないかなぁ、と。

その上で「昔は重要だったけど今は無駄になった」なんてのもあると思うので、定期的に検証のループを回す、と。


んで、ちょうど大垣さんが、Facebookのほうで、ど真ん中な書き込みをしてくださってます。

https://www.facebook.com/michiaki.furusho/posts/1840530206021119?comment_id=1840546786019461&reply_comment_id=1841203432620463&notif_id=1521601974590136&notif_t=feed_comment&ref=notif

パッケージを入れると今の業務に合わなくなるので、どうでも良いことは全てパッケージに合わせる、が良いのは確かです。

問題はどうでも良くないことで、一言で言えば「競争力を維持するための業務」についてはカスタマイズも検討する方が良いと思います。でもそれ本当に競争力??という検証は常に必要だと思います。

多分、ここに尽きるんですよね。

おいちゃん的にポイントだと思っているのは

・どうでも良いことは全てパッケージに合わせる

・「競争力を維持するための業務」についてはカスタマイズも検討する

・でもそれ本当に競争力??という検証は常に必要

この辺。


んで……こっからは経営素人なおいちゃんの考え方、として。

「これ本当に競争力?」って、どうやって検証するのか、ってのが、おいちゃんには正直、よぉわからんです。

「KPI回せばいいじゃん」とか言われそうな気もするのですが、KPI界隈もいろいろあるっぽいですしねぇ。

「施策を打ったらKPIが上がった!」だけで満足するのは危険( https://tjo.hatenablog.com/entry/2013/06/17/190319 )」とか、こーゆー話、なんか割とありそうな気がして、色々。


………確か、どこかで「2要素が、相関なのか因果なのかを(ある程度)判断できる」方法とか、あったような記憶がかすかにうすぼんやりと。


話をシステムに戻しつつ。

システムを組むのって「業務を組む」事でもありつつ、「システム自身」のお話にもなるので、二重に出てくるお話なんですが。

フレームワークが持つ縛り」を、どれくらい許容してどれくらい許容しないのか? ってのは、まぁ、少なくともしばらくは、ず〜〜っと付きまとってくるお話なのかなぁ、と。

その辺も結局のところ

・どうでもよい事か?

・重要な箇所か?

ってあたりの考察が、定期的に必要なんだろうなぁ。

あとは「重要な箇所」が「なぜ重要なのか?」を、最低限、言語化できる事と、可能であれば、必要な人に伝える事。


んで。

個人的には、どちらかというと「フレームワークの縛りが業務と相反する、或いは露骨にリソースを食う」なら、フレームワークをカスタマイズするなり改修するなり改造するなり部分的に置き換えるなり使わないなり、って選択肢を選ぶことが多かったんだけど。

その辺を、今後、ど〜しようかねぇ? っという感じで。

フレームワークの縛りが業務と相反する」についてはお客様と要相談。問題は「露骨にリソースを食う」場合で、「許容できる業務」もあれば「許容が不可能な業務」もあるかなぁ、と思うので。

その辺も「業務の性質を考えながら」になるんだろうなぁ、とかとか。


まぁおそらく最終的には「プレタポルテにも対応できる、普段はレディ・メイド」になるんだろうなぁ、とは思いつつ、まぁまだ色々と煩悶している時期なので。

とりあえず、その煩悶をそのまま文章にしてみましたww


……多分、フレームワークを「がっつり熟知する」には、端的には「そのフレームワークに好意以上のものを持つ」あたりが一番のモチベーションになりそうなんだけど……今の所、あんま、ないしなぁ。

そーゆー意味で、Slimがちょっと気になってる感じ。次点は、現状だと割とCodeIgniter。案件で一度「壮絶なコード」を見たけど、あの壮絶さに、逆に可能性を感じたのでwww


なんて駄文を、つらつら。

広い世界で、なんか一人くらい、この文章が参考になってくれればよいかなぁ。

*1:テンプレートの中で「DBに接続してSQL発行する処理」とか、あんまり見たくない

*2:Zend Frameworkの案件でいくつか「壮絶なの」を見てるしなぁ……伝聞も実体験も込みで

*3:なんとない印象値。根拠なし

*4:いやまぁそれでも最後「なんか色々と無駄メモリ使ってるなぁ」とか思うところもなくはないのですが、その辺も「クラウドでインスタンス増やす」で片付くしねぇ

2018-02-19

[]それは「やらなきゃいけない」事?

「誰が」やるのか?( http://d.hatena.ne.jp/gallu/20180130/p1 )ってエントリーをえらい事のんびりと書いて、割とすぐに出てきた、気になる記事。


「誰がやってもつまらなくて、苦痛なこと」を愚直に継続すると、ものすごく信用される。

http://blog.tinect.jp/?p=49073


ちょいと色々と端折って、結論部分を引用。

「つまらなくて、苦痛なことを地味に続けなさい、その一歩が掃除、ということなんだろう。でも、そういうオーナーはたいてい、掃除も続けられないそうだ。人生がかかっているのにね。」

「「掃除すりゃいい」ということではないとおもいますが、「つまらないこと」を継続できる人は、絶対的に信用されます。そのアドバンテージは、会社の中ではかなり大きいのではないかと。」


色々と興味深く、思う事も色々あるような内容でした。

なので、メモ。