  |
はてなキーワード: ソースコードとは
文脈がよく分からないので、他での指摘と重複していると思うが、個人的に思ったこと。
文章がMECEでないので「まあそういうことね」という話は措いておいて。
a. 日本語ウェブサイトの記事本数で比較することはフェアではない
新しめの技術を活用している人の情報収集の順番としては、エディタでライブラリの当該部分のソースコードを読む、GitHubにリポジトリがあるのであれば、そこのissuesで検索をかける、Googleで英語（エラー文言等なので必然的に英語になる）で検索する、Stack Overflowで質問するという感じだと思うので、Qiitaでの出現数が減ることは仕方ないと思う。
ミクロで見ると、フロントエンド系の主要な論客がQiitaから離脱していることもある。
SSGの登場によってSPAのネガな部分のほとんどは潰されていると思う。
SPA的な手法を使うのであれば、SSGにしろという指摘であれば、的を射ていると思う。
他にも色々と言いたいことはあるが「SPAのことを言ったら一斉に突っ込まれた」という事象を観測できないので、とりあえず以上。
リンク辿ってたら懐かしいの見つけた
2年くらい前にうちの会社でも話題になったけど、商用利用は難しいで止まってた気がするな
https://pkhungurn.github.io/talking-head-anime-2/full.html
↑のとこでどういう理屈で組まれたのか丁寧に説明されてるから見てみて。英語読めんかったらごめん
https://github.com/pkhungurn/talking-head-anime-2-demo
Pythonで書かれてるから動作環境も開発環境も簡単に用意できると思う。
自分の顔で動かしたいならiPhoneないと駄目だった気がする。
ただディープニューラルネットワークの学習モデルは公開されてないんよな。さすがに企業秘密か…。論文出すらしいし。
まあPython環境はちょっとしたディープラーニング環境作るのにも便利だから構築しといて損はないと思う。
プログラムの開発とバグ改修をやっているのだが、営業担当からシステムの仕様とか操作方法とか開発スケジュールとかいろいろを問い合わせるLINEがいちいち届いてそれに逐一返事しなくちゃならなくて全然仕事が進まない。
別に今じゃなくてもいいことを、思いついたその場でいちいち連絡してくるからたまらない。
ソースコード追ってる最中にこれやられると頭の中がめちゃくちゃになる。
しかもメールなら３分で済む用事を３０分以上かけて話す。話が回りくどすぎて本題に入らない。
自分で調べればすぐわかるようなことまで毎回きいてくる。
（追記）
せっかくみんなが指摘してくれたことも、みんなの会社や仕事仲間では当たり前のことでも、うちの会社じゃそれやるとみんな怒っちゃうんだよ。
難しいから電話じゃないと伝えられないとかメール書く時間がかかりすぎて仕事にならないとか。挙句の果てには仕事やる気あるのかとか、もう無理。
一応、身の周りの掃除はしっかりやっとくよ。
「プログラミングに必要なのはググる力だ」などとまことしやかに言われます。が、これは嘘なので、プログラミング初心者は（中級者以上も）真に受けないで下さい。そして、プログラミング教育に携わる人は、こういう有害な嘘を広めるのはやめて下さい。
なお、ここでいう「プログラマ」とはプログラミングを仕事にする人、または作成したプログラムを公開する人を指しています。純粋に趣味でプログラミングをしており、ソースコードもソフトウェアも公開するつもりの無い人は、どんな方法でプログラミングをしようと自由です。
プログラマに（プログラマに限らず）必要なのは、自身の専門分野に関する基礎的かつ体系的な知識です。それらが不足していては、「ググる」ことさえままなりません。英語で喩えれば、時制や不規則動詞という概念を知らずに辞書を引いて、「I saw him yesterday. 」の「saw」をのこぎりのことだと思い込むようなものです。要するに、調べたい事項が何に関するものなのかを理解していなければ、調べようがないのです。
それでは、プログラミング初心者にとって必要な基礎知識は具体的にどのようなものでしょうか。
まず当然ですが、自分が使っているプログラミング言語やフレームワークの機能は一通り知っている必要があります。組み込みのデータ型や制御構文はもちろん知らなければいけません。高階関数、クラス、非同期処理等の発展的な機能も知る必要があります。言語だけではなく、パッケージマネージャ、タスクランナー、単体テストツール等の周辺ツールの理解も必要です。また、「コードコンプリート」とか「Effective ○○」のような書籍に書いてあるような設計・コーディングのベストプラクティスも知らなければいけません。要するに、現代のプログラミングの「常識」は全て知っている必要があります。
そもそも「そういう機能が存在する」と認識して初めて「調べる」ことができるのです。列挙型という機能の存在を知らずに「Javaで列挙型はどう書くのだろう」と調べることはできません。非同期処理の存在を知らずに、「JavaScriptで非同期処理はどう書くのだろう」と調べることはできません。
では、そのような一通りの知識を身に着けるためには、どのようなリソースから学ぶべきでしょうか。
逆に、Wikipedia、Qiita等の個人が趣味で書いた記事、プログラミングスクールの記事、プログラミングスクールや家庭教師、etcを主体に学ぶのはやめるべきでしょう。
もちろん、特定の話題について調べる過程で、非公式の情報に行き着くことはあるでしょうが、そこで使用されているライブラリ等の仕様については、必ず公式ドキュメントで裏を取るべきです。
時々、こういった正式なドキュメントを読むことが、初心者にはハードルが高いと言う人がいます。しかし、冒頭で述べたようなプログラミングを仕事にしようとしている人達が、こういうことができないのはおかしいです。
実際、公式ドキュメントを読むことはそれほど難しいことではありません。有名な言語やライブラリ等のドキュメントであれば、高校程度の数学力英語力とある程度のコンピュータ操作の経験があれば、理解できるように書かれています。その程度の素養も無いのにプログラマ（特に職業プログラマ）になろうとすることが、そもそもおかしいのです。運動が苦手なのにプロスポーツ選手になろうとするようなものです。
物流会社の事務員なんだけど会社がRPAツールを導入するってんで定型作業を自動化しろって話しでRPAプログラミングをやらされてたんだわ。
1、実務の合間にやらないといけない
現場がクソ忙しい時に悠長にデバッグとかやってられん。あとデバッグみたいな作業は見た目何もしていないように見えるからここぞとばかりに仕事振られたりする。
2、本番環境とか開発環境とかない。ぶっつけ本番で稼働→失敗→デバッグを繰り返さないといけない。
これは自動化する仕事によると思うんだけど、実際に現場で使うデータをRPAプログラムに投入しないとそもそも要件がわからないことがある。データの特性というか、物流事務なんかだと8割がシステム化されているけど2割は荷主や配送先のわがままで特徴的なデータの不備があって、それに対応するのが事務屋の仕事なんだけど、そういう面倒な作業を自動化しろとか言ってくる。そもそもRPAなんてシステム化のスコープ外の面倒な事務を(金をかけずに)自動化することが目的だから当たり前なんだが。
そうすると要件の洗い出しとかできない。ベテランのオペレーターにはそういうの全部頭に入ってるからマニュアルとか作ってないことが多い。実際新人に教えるときもぶっつけでやらせてわかんなかったら聞けみたいな世界だし。
3、(2)みたいな事象があるからソースコードがぐちゃぐちゃになる。ぶっつけ本番でプレッシャーがある中実行してその場凌ぎの改修して保守性皆無
RPAツールってWindowsのUIをいじって業務を行うプログラムを作るんだけど、結局今どの画面を開いているのかとか、どのエラーが出ているのかとかプログラム上で管理できない。既存のソフトウェアUIがたまたま運良くRPAツールと相性が良ければいいけどそうじゃなければめちゃくちゃやりづらい。特にIBMのPCOMMとかはツールとの相性が悪くて地獄だった。
書かなくてもわかると思うけど、業務で操作するソフトのUIが変わった瞬間にそのRPAプログラムはゴミになる。
(4)に関係するんだけど、RPAプログラムが立ち上がった時のパソコンの状態によって処理速度にムラがあるので、プログラム上このステップまで進んだらウィンドウはこの状態にあるだろうと仮定してプログラムを作ったところ、実際100回のうち99回はそうなんだけど、1回だけ処理がもたついてその状態にならなかったからバグって処理が停止する。みたいなことがある。
もちろんツールではウィンドウが操作可能になるまで待機、みたいなのはあるけど操作可能、全面にある、みたいな粗い粒度でしか状態管理できない。
7、こう言うのをちょっとパソコン得意とかEXCEL VBA かけますみたいなやつにやらせることの矛盾
うまくいくわけない。(4)(6)のところでウィンドウの状態管理とそれに起因するバグについて書いたけど、こういう時RPA担当は一般のプログラミング言語でいうsleepで職人芸的に時間調整するんだぜ？こんなのもう(3Dリアルタイム)ロボットプログラミングでしょ。
結論を言うと2022年の馬鹿みたいに複雑化した物流の事務(そしてそれは主に荷主と物流会社の主従関係によるわがままに起因しているのだが)をRPA化するのは無理だしもうやりたくないね。
少し前にmacOSはLinuxではないとTwitterで話題になりました。その際に
といった内容のTweetを見かけたのですが「元になったのはBSDではなくMachなんだけどな～。昔を懐かしみつつ、調べながら何か書くか」と思いつつ、面倒になったので記憶のまま適当に書くことにしました。
Machは当時一世を風靡していたマイクロカーネル設計を採用したOSで、BSDとは全く違うOSです。
ただしBSD互換機能を利用していたユーザーは、内部に関心が無ければ
といった印象を持っていたのではないでしょうか。互換機能としては成功なのですが。
macOSのもとになったNeXTSTEPはMachを改造して始まりましたが、現在では別物であると考えるべきです。
macOSは直接にはMachから派生したもので、BSDではありません。ただし
など、BSDと誤解させる点があるのは確かです。
上記のUnix → BSD → Mach → NeXTSTEP → macOSではソースコードを利用しながらOSを作って行ったため共通の部分がありますが、これらとは全く関係無く独立して開発されたものです。
しかし現状ではNode.jsやPythonなどでプログラムを作ろうとした場合にシェルで使うコマンドはmacOSとLinuxでは共通するものも多く
そもそも大企業の上層部はDXっていうのを買ってくればDXできると思ってる。
DXっていう研修とかDXっていうコンサルを買ってくればDXできると思ってる。
これが中小企業ぐらいだったら鶴の一声でDXできるかもしれない。
ところが大企業っていうのは意思決定者が細分化されていることが多くて
社長が「DXするぞ！」って言っても実際に社長はDXの状況を年に１回ぐらいしか確認しないし
「結局はこれだけやってりゃいいんでしょ？」
例えば、社内の会計システムがエクセルよりダメダメな終わってるような会社（某大手通信会社）でも
それを変えようとすると
「これで慣れてるから変えるな」
これ、実際にはそういうこと言う人はほとんど居ないんだが
会計システムを管轄している部署が実際に使う人達の部署の上位組織にあたることはほとんど無いし
下手したらコストセンターの部長は営業系の部長より立場が低い場合がある。
だから売り上げが下がるような可能性を忖度して新しい社内システムなんて簡単には入らないし
入れるとしても無茶苦茶時間かけて旧来のシステムとの整合性とか気にしまくってから導入する。
ってなってほとんど使われないのが現状。
他にも何かしらDXしようとしても結局は上司の意見を忖度する。
パワポの資料やめてnotionにしましょうとかソースコードのSubversionやめてGitにしましょうとか
そういうことを「言うことが構造的に難しい」っていうのが根本的に問題。
社長や部長が「そういう声を拾うぞ！」とか言ってご意見箱的なのを用意したりもするんだが
結局そこに投稿されてる提案が良いのか悪いのか判断できないから無駄。
必要なのはリーダーシップというある意味独裁的なやり方であって民主主義的なことをやってたら成功しない。
なのでDXを本気でやりたかったら上層部の人間がイケてるベンチャーで下っ端として１ヶ月ぐらい働いたらどうですかね。
日銭を稼ぐようなベンチャーでイケてるところは効率化の塊ですよ。
プログラマーをやっていると、何やっても火を噴くようになったソースコードというのを目にすることがある。
だが火を噴きつつもなんとなくタスクは完了できるし、いきなりそうなったわけでもないのでゆでガエルの様に経営陣はこんなもんだろうと深刻に見ようとしない。
だが、ちょっとした機能変更ですら1人月かかるなどという状況は異常だ。
これはそのソフトウェアが採用したアーキテクチャが死んだ、ということでもある。
アーキテクチャは当初はとてもいいものだろうとみんなが考えて採用するが、時と共に基盤技術が陳腐化する、新しい技術が台頭するということによって陳腐化したり使い物にならなくなったりする。
また、経済の発展と共にそのアーキテクチャではもたないようになることもある。
50cmくらいの溝にかける橋なら適当な板でも構わないが、その端の両端に気をつなぎ合わせて利根川を渡す橋を架けるとか、利根川をまたげるくらいの板を利根川に渡してみてもそれは端にはならない。自重で瞬く間に崩壊するだろう。
だが、ソフトウェアの世界では、じゃぁ、更迭の橋げたを下に並べようとかそういう事をする。
元の板なんかなくてもいいんじゃないですか？
いやもう橋の中に埋め込まれてとることはできない。
いや、だったら横にもう一つ橋を架けたら・・・
そんな金のかかることできるか！
みたいな変な議論をする羽目になる。
橋につぎはぎするのに毎年10億円を50年払い続けるのはいいが、新しい橋を20億円かけて架けてその後毎年2億円位のメンテナンスコストで済むほうは選ばない。
