  |
はてなキーワード: Grepとは
https://type.jp/et/feature/26796/
この発言にもあるように「コードを綺麗にする＝読みやすくする」ってことだと勘違いしてる
コードを綺麗にするのは「バグを少なくする」ためであって読み手のためじゃない
グローバルに一文字変数を使って困るのは「どこでそれを触ってるか分からないから」であって「読みにくいから」ではない（まぁ読みにくいけど）
特に昔だとLintもないし変数の参照先を探すのはgrepぐらいしかなくて
$iとかだと$iiもひっかかるし$iの後ろにスペースがあったり無かったりするともう探すのは不可能に近くなる
それでも動いているなら最悪問題無いんだがバグの修正時にめちゃくちゃ困って
「作り直すしか無いな」
ってなるのでビジネス的にも大きな影響が出る
「どんなコードでも動くコードを作るのが正しい」「done is better than perfect（完璧を目指すよりも、まずは終わらせることが重要） 」のスタンスが効率的だろうなぁ、、と思うおいらです。
これも元の言葉の意味を曲解していて、「終わらせることが重要」というのはバグがあって良いわけじゃない
例えばログインボタンを実装したときに、ユーザー名とパスワードに何を入れてもログインできる状態にするのも「終わらせること」だし
ただこのままリリースできるわけではないし、プロダクトとしては「終わっていない」
パスワードを平文で保存して実装するのも「終わらせること」ではあるけれどそのままリリースしていいわけではないし
下手に動いてしまうとそのままリリースされたりもするのでよりタチが悪い
この言葉の重要なのは「better than perfect」の方であって「done」の方ではない
全てを完璧にする必要は無い（し、そもそも完璧は定義できない）ので「perfectでなくていいよ」というだけ
バグがあったり不十分だったりセキュリティ不備があって良いわけではない
毎日論理構成の中に浸ってる人は、推理小説は向いてるかもしれないですね。初期にちょろっと設定したグローバル変数が、最終的な結果に大きく影響してくるとか、「ここで使われてるのかー」みたいな感慨とか。
残念ながら「ああ、まともなコードしか読んできてないんだな」としか思えない
例えば「ユーザーの名前と住所は設定できてるから、性別を設定できるようにして」という依頼があって
コードを確認してみるとuser1, user2, user3という変数が100個用意されていて、user1.name = 'hoge', user2.name = 'gaga' って感じで100行書いてあって、更に住所で100行あって、性別も同じように100行追加しろっていうコードを読んだことが無いんだろう
そしてそのコードのどこかで住所設定が間違えているから確認しないといけないような作業をしてないんだと思う
小説で言うと同じ文章が100ページ続いていて、その中のどこかの漢字が違っていて、そいつが犯人、みたいな推理小説、面白いか？
他にも足したり引いたりこねくり回された変数値が最後に定数値で上書きされてたり、UserのオブジェクトがいきなりWeatherのオブジェクトに置き換えられていて、name属性に晴れとか雨のデータが入ってたりしたことがないんだと思う
汚いコードは伏線を回収しないし最終的に犯人も分からないし無駄に長いので推理小説には全く向いてない
で、やっぱりこういう汚いコードの問題は「バグが混入しやすいかどうか」であって「読みやすいかどうか」ではない
下手するとuserオブジェクトを100行ずつ書いてくれてる方が読みやすさはあるかもしれないが
「user36だけ住所が設定されていない」といったバグが混入し得るし、それを確認するのに多大な労力を必要とする
人間は誰もが間違いを犯すので誰もがバグを混入させる危険性があるんだけれど
その危険性は最大限まで下げるように努力するべきだし、インシデントを引き起こすことでビジネス的なインパクトも大きい
拡張子については、例えば Excel の拡張子が変わったとき一括対応できる、とか？
あとは普通に".txt" で取り扱ってるファイルはどれだ、って時にその定数の参照箇所を見ればもれなく分かるとか、
取り扱うファイルの種別を段階的に変えようってときも、どのファイルは変え終わっててどのファイルはまだ、とかも同じように分かる
あとはあれだ、どのスコープにおける分類なんだって話を明確にする事も出来るだろうな。
とか。
パラメータについては、複数の選択肢から選ぶ奴は enum にしろよ、とは思うが、
文字コードも大体同じような話か。
ここに定義したもの以外は登場しないよ、という保証をする事は出来るわな。
あと日本によるロシア下院議員384人に対する措置っぽいので、必ずしもBANされてない＝露探というわけでもなさそうではある。
AISAWA Ichiro
ESAKI Tetsuma
ETO Seishiro
FUJIMARU Satoshi
FUKAZAWA Yoichi
FUNADA Hajime
GOTO Shigeyuki
GOTODA Masazumi
HAGIUDA Koichi
HATOYAMA Jiro
HAYASHI Motoo
HIRASAWA Katsuei
HORIUCHI Noriko
ITO Yoshitaka
IWAYA Takeshi
KAIEDA Banri
KAJIYAMA Hiroshi
KAMIKAWA Yoko
KANEKO Yasushi
KATO Ayuko
KATO Katsunobu
KIUCHI Minoru
KOBAYASHI Fumiaki
KOBAYASHI Takayuki
KUSHIBUCHI Mari
MAEHARA Seiji
MAKI Yoshio
MITAZONO Satoshi
MOTEGI Toshimitsu
NAKASONE Yasutaka
NAKATANI Kazuma
NIKAI Toshihiro
NIKI Hirobumi
NISHIMURA Akihiro
NISHINO Daisuke
NODA Seiko
OBUCHI Yuko
OGATA Rintaro
OISHI Akiko
OMI Asako
ONODERA Itsunori
SAITO Tetsuo
SHIMOMURA Hakubun
SUZUKI Takako
TACHIBANA Keiichiro
TAGAYA Ryo
TAKEBE Arata
TAKEDA Ryota
TSUCHIYA Shinako
TSUKADA Ichiro
WAKAMIYA Kenji
WASHIO Eiichiro
YAMAGIWA Daishiro
YAMASHITA Takashi
YANAGIMOTO Akira
YONEYAMA Ryuichi
とりあえず俺のおすすめは以下の通り。
https://www.supersento.com/sp/
●ゆる〜と
●錯思コレクション100
https://www.jumonji-u.ac.jp/sscs/ikeda/cognitive_bias/about.html
http://kakidashi.com/index/index_sp
本の書き出しを一覧で見られる。
●Hatebu grep
——登さんくらい常に気持ちをフラットにできればいいのですが、仕事のストレスで参ってしまうエンジニアも多くいます。
そうですね。ストレスを感じる理由はさまざまあると思いますが、一つ例をあげるなら、仕事の目的が「お金を稼ぐこと」それ自体になっている人は疲弊しやすいかもしれませんね。
稼ぐことを目的としている人のゴールは、おそらくご自身の「安寧な暮らしの実現」にあるのだと思います。それがとても大事なことなのは言うまでもありませんし、否定するつもりも毛頭ありません。
一方で、私や私の周りにいる人たちは、現状の成果に満足せずに得たお金を次の進化のために再投資しようと試みる人ばかり。どちらが良いとか悪いとかではなく、価値観が違うだけのことです。
ただ、前者の「お金を儲けて安寧な暮らしがしたい」という人にとって、仕事から受ける疲労や気分の落ち込みというのは、ある種当たり前のことだとも思うんですよね。
——というと？
どこかで成長を諦め、安寧な生活を望むような性向が、かえって心身の不調やフラストレーションを生み、パフォーマンスを落とす一因になっているのではないかと思っているんです。
「お金を稼ぐためだから、しょうがないか」と思ってやっていること自体が、ストレスになるのではないかと。
登 大遊さん
でも、こればっかりは人の価値観ですからね。変えようと思っても、すぐに変えられるものでもない。
どんな価値観で生きるのかを選ぶのはその人ですし、どんな人生を選んでもリスクはついて回ります。
安寧な生活や休息を優先する生き方には、仕事に対するストレスやそれに付随する心身の不調などの副作用があるということに過ぎません。
ただ、一つ言えることがあります。日本において、「大義を持って働く」生き方を選択をした人は、これから大変有利だということです。
——どういう意味でしょう？
自分の手で未来を変えようと野心に燃える人が世界中から集まるシリコンバレーなどでは、埋もれてしまうかもしれない人であっても、日本の旧態依然とした組織の中では、同じことをするだけで、比較相対的に価値が高くなりますから。
技術者がわざわざベンチャーを立ち上げ、投資家からお金を引き出すために詭弁を弄したり、ニーズをでっち上げたりしなくても、日本の大企業にはストレートに解決すべき課題がいくらでもあります。そしてそれらの問題を、自分自身の頭脳を用いて解決しようとする時は、必ず、従来とは異なる方法で解決する必要があるのです。
なぜなら、まさに従来手法では解決できなかったことからその問題が放置または堆積されているためです。
——その場合は、どうすればいいのでしょうか。
その問題を一旦一般化・抽象化した上で、これを解決することができるより低レイヤーのフレームワークのようなものを作ってしまうことが重要です。一定の労力はかかりますが、それによって生じた汎用的成果物は、他の業務や他の組織においても普遍的価値を持つようになります。
ここで重要なのは、目的を「業務上の特定の問題の解決」から昇格させ、「その特定の問題と本質的に類似しており、かつ既存の最適な解決方法が存在しない、新たな汎用的解決方法の実現」という、より価値の高い目標に設定する必要があるということです。
登 大遊さん
——目先の特定の問題をその場しのぎで解決するのではなくて、普遍的な価値を目指すと。
その結果、問題がうまく解決され、成果物が出たならば、サラリーマン的な自分自身（個人）と自組織にとっての短期的な狭い利益だけでなく、同時に「世界における技術の進歩」という長期的で大きな価値が生じます。
具体例を挙げると、たとえば「UNIX」を構成する重要な機能、たとえばシェルやプロセス間通信、パイプ、grepといった機能。これは電話会社であるAT&T社の特許部門における、膨大なテキストファイルを全文検索するという特定の業務を解決しようとした同社の社員たちが、単にその社内問題解決にとどまらず、さまざまな組織や目的で汎用的に利用できる仕組みを考案し、プログラミングして実装したものです。
結果として、「UNIX」は汎用的に利用される価値を有し、単に一企業の業務に留まらず、全世界的に普及し現在のサイバー世界の基礎となっています。
このように考えれば、ICT技術者は、これまで組織内で放置または堆積されてきた多種多様な課題について、目先の解決ではなく、「正しい普遍的な方法で解決する仕組みを作る」という気概で、真摯に向き合えば、自然に世の中に貢献できる成果ができるわけです。
音声に対して窓関数かけて、横軸を時間、縦軸を周波数としてプロットしたのをスペクトログラムという。
数字が並んだだけだとわかりにくいが、グラフを描けば問題箇所がわかる、といった具合だ。
スペクトログラムを使い始めた際、これで問題がわかるものだと思っていた。
ネットにもスペクトログラムについての記載は多くあり、枯れた技術のように見える。
だが、実際やり始めると、広く広まっているこの手法はいいのか？と思えてくる。
① 耳で聞いたときの違和感に対して、どこが問題があるのかがわからない
③ 耳で聞いて差がある音声に対して、明確にどこが影響しているのか比較、diffが取れない
④ 多くの人はスペクトログラムを読めない。（歯擦音、母音、子音かくらいしかわからない）
あたりを感じている。
最近のホッテントリの傾向、昔は正気だったブクマカが党派性に脳をやられてキチガイ化してしまった様などを見るに
「このままこのサービスを使っていては遠くないうちに脳に致命的なダメージを負ってしまう」
と思ったので、はてなを退会することにしたのだが、アカウントが消えても増田は残るのでポンと退会できない。
愚痴ったら「同じ内容を連続投稿すればBANされるぞ」とトラバを貰ったが待てど暮らせどBANされない
仕方ないので色々試行錯誤してみたのだが、ITエンジニアでもないのにテキストベースでログインしてgrep使って一括削除など出来るわけもなく
結局Power Automation Desktopを使ってRPAで全部消した。
鉛筆マーク、削除ボタン、OKボタンの画像を認識させ、詳細で画像の表示待ちのチェックを入れたら、あとはひたすらループを回すだけ。
ハイクが終わった時点で辞めておくべきだったな、と思わなくもないが続けてしまったものは仕方が無い。
増田を全部消したい人は多分他にもいると思うのでこの増田だけは残しておく。
ブレグマン（2021）『Humankind 希望の歴史』を勝間さんがブログで紹介しているが、その記事のブコメが地獄と化している。
https://b.hatena.ne.jp/entry/s/katsumakazuyo.hatenablog.com/entry/2021/08/12/162845
「なんとなくだが俺はこう思う」「著者はチェリーピッキングしててクソ」みたいな主張がエビデンスなしに書かれており（そもそも君たち原書読んだ？）、それらにスターが当然であるかのように集まっている。これらは理性的な議論でもなんでもなくただのエコーチェンバー現象である。やはり、ブコメという文字数制限があるメディアできちんとした議論を行うのは無理があることが分かる。
こういう学術書やそれに近いものを読むときに私が習慣としていることがある。本を読む前にプロによる書評を読め。
ここでのプロというのは、新聞でそういう書評をいっぱい書いているプロのレビュワーのことではなく、プロの学者のことである。
例えば、"Bregman Humankind book review"とかでgoogle scholarなどを調べると、文化人類学者によるこの書評がヒットする。
A Sceptical Review of Bregman’s 'Humankind: A Hopeful History'
https://www.newenglishreview.org/custpage.cfm?frm=190173&sec_id=190173
この書評によれば、「過去において狩猟採集生活で住民同士が戦争ばかりして殺し合っていたというのは基本的には嘘」というブレグマンの主張は文化人類学的には嘘っぱちである。
"As a journalist he not only knows very little anthropology but also has an irritating folksy style"（ジャーナリストのブレグマンは文化人類学についてほとんど何も知らないだけでなく、イライラするほど垢抜けない文体を用いており）、"This is reminiscent of a very bad undergraduate essay"（これはとても下手な学部生のエッセイを思い出させるような主張だ）、などとやたら攻撃的な評がなされており、それはそれで大丈夫かという気持ちにはなるが、少なくとも一人の専門家視点から見た学術的な評としては参考になる。もちろんこの書評が真理で『Humankind』は読む価値なし、とここで主張したいわけではない（私は文化人類学者ではないのでその判断はできない）。
このような視点で批判的に本を読解することは、当該分野の知的蓄積を持っていない素人には不可能である。誤った知識を盲信しないために第三者によるファクトチェックには目を通しておいた方がよい。逆に、その道の専門家が「よく書けた本である」と肯定的に評していれば、ある程度安心して読むことができる。
日本語の書籍なら「（書名） 書評」でググる。学者による書評に絞りたい時は「（書名） 書評 教授」でググったり「（書名） （著者名）」でGoogle scholarしたりするとよい。
英語の書籍（日本語に翻訳された本を読むときもこれで原著の評判を調べる）なら「（書名） （著者名）」でGoogle scholarするのがおそらく一番よい。ある程度有名な本ならプロによって書かれた書評が学術ジャーナルに載っており、それがだいたいヒットする。特にいわゆる文系の学術ジャーナルには毎号Book reviewコーナーがよくあり、そこに載っている書評は「本の主張まとめ」→「本の批判的検討」→「本の評価」というフォーマットで書かれていることが多いため大変読みやすい。ただ一つ問題があり、これらのジャーナルはほぼ有料である。研究機関に所属するか金を払うことによりこの問題は解決する。
また、twitterで「（書名）」で調べ、研究者っぽい人による短評ツイートを探して読むという方法もある。研究者のTwitterはだいたい実名かつ顔写真アイコン（ソース：私の印象）なので、それで目grepしてからプロフィールをチェックするとよい。ちなみに関心がある分野の研究者のtwitterアカウントは普段からフォローしておくとたのしい。
冒頭で「ブコメがやべえ」と批判したが、こういう風呂敷を広げまくって人類史を俯瞰したぜと主張する売れ筋本に警戒心を抱いてしまう気持ちはよく分かる。なぜなら、最近のそういう本に対しては「適当こくな」と専門家からツッコミが入ることが実際に多いから。
例えば、Humankindの書評として上に挙げたものを書いたC.R. Hallpike先生は、ハラリの『サピエンス全史』に対しても批判的な評を行なっている。
Review of Yuval Harari's Sapiens: A Brief History of Humankind.
ちなみにこのHallpike先生は、未開社会のフィールドワークを行なった経験から「最近のポップな歴史書は文化人類学的デタラメばっか書きおって」と心底お怒りらしく、全員（チョムスキー含む）まとめてぶった切る本まで書いている。Hallpike先生が過激な主張を好むことも踏まえると（参考: https://twitter.com/profdanhicks/status/1336981539893161984 ）、この本に対するプロの書評が見つからないのは残念である。
C.R. Hallpike(2018). "Ship of Fools: An Anthology of Learned Nonsense About Primitive Society".
https://www.amazon.com/Ship-Fools-Anthology-Nonsense-Primitive-ebook/dp/B07HX4188K
また、このような人類歴史書スキャンダルとして最近話題になったのが、スティーブン・ピンカー(2019)『21世紀の啓蒙』における「学術的ルール違反」事件である。
ピンカーが書中で「科学史家による主張」として紹介していた言説が、脚注をたどると科学史家でなく社会心理学者によるものであったことが分かり、さらにピンカーによって引用されていた文章は実際には同じ論文内の別部分の文章を継ぎ接ぎしてピンカーにとって都合の良いように捻じ曲げられていた、という事件である。詳しくは以下のツイートを参照。
https://twitter.com/mccormick_ted/status/1419672144368308225
もちろん『21世紀の啓蒙』におけるピンカーの主張自体に対するプロからの異議申し立ても存在する。
https://www.abc.net.au/religion/the-enlightenment-of-steven-pinker/10094966
https://anond.hatelabo.jp/20210617075257
上がってるような基本（元増田に上がってるやつの倍ぐらい）が全部立ち上げからできて
2〜3個プロジェクト経験したらテックリードの素養が既に身についてそう。
プロジェクト的にもどっちかが弱いと
Rails/DjangoにjQuery+Bootstrapみたいな構成や
Amplify/FirebaseにVue/Reactみたいな構成も全然あるので
面接はなんとか抜けてもらうとして、
チーム開発での最低限の目標としては、
成果物から、指導、学習コスト、レビューコスト、技術的負債、マネジメントコストを引いた分が正になっていれば
ひとまず「チームに居ていい人」と見なされそう。
チーム的に良くても、経営層にそれで許されるかはわからんのでその辺の立ち回りも上手いことやるとして、
一旦は、正の生産性を目指してほしい。
以後、ブコメで誰一人一ヶ月でできるって言ってなくて笑うので、
一ヶ月というのは無視して、三〜六ヶ月程度をイメージしつつ書いていく。
似たような言語なのでどっちからやってもいいし、両方同時にやってもいい。
どっちかしかやらないならJavascriptがおすすめ。後ででてくる、Flaskは適当にExpressとかに置き換える
現場だとほぼTypescriptなので、Javascriptはある程度慣れたらTypescriptに移行したほうがいい。
どちらも、Python2とES2015以前の記法というレガシーがネット上に転がってるので参考にしないように注意。
・一貫性があって
・正しい書き方がされた
お手本プロジェクトをなにか(githubや書籍など)で手に入れて読むべき。
おそらくフレームワークに乗っかっているので並行して進めることになる。
話の流れで先にこっち
現在のコーディングのグッドプラクティス、デザインパターンはフレームワークの形をしている。
なので、ReactとVueをその思想から理解しきれれば、プログラミング言語の潮流の最先端に追いつけるはずだ。
TypescriptもVue.jsも書き方をどこまで取り入れるかが使用者の裁量に任されてるし、
開発でVueとReactのどっちを使うかはチーム次第なので、
一旦React+Typescriptでガチガチに書かれたコードプロジェクトを拾ってきて、必死で解読するのがいいと思うなー。
2割ぐらいわかった気になればチーム入ってから(React, Vueどちらだったとしても)動けそう。
パッケージとかテスト、タスク＆デプロイ辺りもこのタイミングで拾ってきたプロジェクトを使って学ぶ。
バージョン管理とコンテナの思想が優れているのは自明なので、これらはツールと見ていい。
そして、後からプロジェクトに入った人がプロジェクトの流儀に沿って使う分には難しいことはなさそう。
採用に来た人がgitとかわかってるとチーム開発経験者だなーって思うし、知らないと未経験者なんだなーって思うし、
そういう意味ではチーム開発の経験があるかどうかの試金石にはされてそう。
構築できる、ではなく、触れる程度で良さそう。
gitはプロジェクトの流儀によると書いたが、git-flowのイメージ図を理解して運用できるのがよい。
https://qiita.com/KosukeSone/items/514dd24828b485c69a05
こういうのができるんだなーって言うのを知っておいて、調べつつ書ければ十分。
あとはシェルスクリプトとかって思ったけど同様のことはPythonでもできそう。
地味にSSHでログインした先の環境だと、vimが主要なテキストエディタになるので
vimを最低限触ることだけ要りそう。もういらないかもって思ってたんだけどなー。
→ ファイル開いて入力モードに切り替えて書き込んで保存して終了
細かく書いたが、LPIC-1の範囲がほどよくまとまっているのでそっちを参照するとよい。
これが意図なら
この辺の機能を持った小規模Webアプリを作ってHerokuでデプロイすれば一旦完成とみなしてよさそう。
コード書き写しただけにならないようには注意しつつだけど、長く見て5人日ぐらい？
慣れると1日あればいけると思う。
フレームワークもなんでもいい。
Djangoとかでも各コンポーネントがどんな働き方してるか程度はわかるだろうしそれで十分。
余力があれば複数個触ってみたり、人から勧められたらそっちでも。
最近はサーバーレス&NoSQLが流行ってるのでFirebaseとかもやればいいと思う。
に尽きる。
計算量を気にしなかったせいで線形検索メソッドとfor文を組み合わせて
それらに対して分散や非同期処理で解消しようとするとか、
ちょっとでもアルゴリズムを触った人ならアホらしいなって思うような行為を
計算量を意識するだけなら、AtCoderのABCのC〜D問題辺りが解ければ十分。
有名な脆弱性や攻撃手法は、ほとんどフレームワーク等で解決手段が用意されている
のでアドリブをせずに正しい書き方でやれば良い。
開発現場でもセキュリティリスクがある箇所を1から自前で実装することを経験が浅い者にはやらせないので、
ただただ、フレームワークが正しいとしているやり方をなぞるのが良い。
開発の勉強のやり方としては、
・正しいコード見本を手に入れること
この辺りの習慣があればやってけんのかな、
その他、チーム開発って面では
TeamGeek（人間性）とかインプットしておくと共通言語が増えて嬉しい。
この方向で進めてけば、その途中で正の生産性≒足引っ張らないぐらいになれるので、
そしたらやってけるんちゃうーって感じ。
