  |
はてなキーワード: コーディングとは
自分が開発を始めたソフトウェアがイスラエルの企業の目に留まってそのまま現地に行っちゃった人のお話を読んでいた。
すごいなー→仕事心底楽しそうやなー→自分の実現したいことが周囲から認められて幸せそうやなーまでは思った。
けれども、こーなりたいなーとか自分もいつかのために勉学に励まなくちゃ！って気概まで全く至らなくて
プロ野球選手目指しますとはちゃうんだからと思っても、自分にはもう踏み出す足がないことにため息をついてしまった。
プログラミング嫌い、特にgo言語なにそれおいしいの？原始的で野蛮書くの辛いって口悪しくぶっちゃけたら転職の面接で落ちたばかりだ。
実際に似たような業界だけど、プログラマーとしての才能まじでないし、寿司打は一回り年下の後輩にぼろ負けするくらいタイピング遅いし、
正直コーディングよりも、yamlファイル、tomlファイルという設定ファイルをもっちり整えてる時間の方が好き。
マネージャー職もリーダーも無理。自分はこのポジむいてないなっていうのはよく知ってる。ソフトバンク行った同僚の残した資料を見てるとこれと同じレベルのドキュメント作る自信も皆無で。
新型コロナ感染症は、血栓形成が特異な病態として知られている。そのウィルス粒子のガワをコーディングするmRNAを筋注し、人体内でガワを作らせ認識させ忠和抗体を作る過程で同様なことが起こる可能性はある。んで体質(凝固因子等のsnp)や元々の冠動脈疾患リスクファクターの状態によって Vaccine related Acute
Thrombosis とでもいうべき病態が起こって稀には接種翌日に発症するのかも。頻度がすごく低いのはその発生自体がまれなのか、発生しても無症状で経過する事が多いなどの理由が考えられる(症状のない小さな肺動脈血栓・深部静脈血栓は日常診療でもしばしば経験されること)。
なので、接種後数日以内に亡くなった方々については発症経過や血清･血算等データの保存・集積をできる限り行って後々の検討に使えるようにしておいた方がいいんじゃないか。
どーしても在宅でコーディング系の仕事で雇われたいんだけど、どうやったら仕事にありつけるだろうか。
月休み4日手取り15万円のいまの仕事がしんどいから転職したい。
今の仕事はブルーカラー。2年間働いたけれど、昇給もボーナスも退職金もない。がまんすれば定年まで居られるだろうけど、経済面だけでなく肉体的にもきつい仕事なので続けられるかどうか……。
過去に、IT系っぽい会社で働いていたことがある。そこでは、実務としてコーディング経験はないが、デジタルデータの作成やディレクターのようなこともやっていた。
いま40歳をこえているが、趣味程度にウェブサイトを作成したりしていたことがあり、PHP , MySQL , JavaScript , HTML , CSS などWeb系の知識は少しはある。
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（人間性）とかインプットしておくと共通言語が増えて嬉しい。
この方向で進めてけば、その途中で正の生産性≒足引っ張らないぐらいになれるので、
そしたらやってけるんちゃうーって感じ。
私は一流SIerの上級管理職をやってるけど、こんな要素技術なんて結局意味がないんだって何回いったらわかるんだろうね日本のエンジニア（）は。この程度を勉強したところで結局派遣SESが関の山なんだけど本当にそういうのを目指したいのか？本当の意味でエンジニアになりたいのならとにかく顧客とのコミュニケーションと要件定義の仕方、そして進捗管理の報告、ちゃんとした開発プロセスを学び、次に機能設計、詳細設計をもれなく記載する技術を学ぶべきで、Docker（）なんてどうでもいい。
不勉強な人ほどウォーターフォールを馬鹿にするけど、結局すべての開発プロセスというのはウォーターフォールが基本だし、その中で要件定義や機能設計の重要性を勉強する。こういう正統な成長の道があるのに最も価値の低いコーディングから入るのは愚の骨頂。
ちょっとプログラミングできる、っていうレベルの人が一番うざい
長い月日をかけて誰にも使われないソフトウェアが完成する
完成する頃にはもう居ない
自分はサーバサイドだから、フロントエンドだから、AIだから、とか言ってその分野ばっかりやる人
ぶっちゃけその分野もこっちでやった方が早いしできるんだけど
まぁそれはみんな一緒かもしれんけど同じことばっかやってて成長しない
最近のQiitaにも多いけど「こうしたら動きました」って言って内容理解してない人
これってどういう意味？って効いたら「コピペしてきました」って言う（意味を聞いてるんだが）
大抵は冗長かつ不十分な実装になっててしばらくして動かなくなる
まぁ誰しも通る道だとは思うので丁寧に指導はするけれど
3年前、世間一般にはメーカー系SIerとして知られている会社を退職した。ただ俺のポジションはパッケージソフト開発であり純粋なSIerとは異なる。
客ともSEとも会話せず、ひたすらドキュメントとプログラムを書く部署だ。といっても別にペーペーではなく主任クラスであり、
会社の業績がとてもよかったこともあり年収は1000万弱はあった。35歳。
これだけ見るととてもいい待遇に見えるだろう。でも耐えられないことがいっぱいあった。
Linuxで動くアプリなのにVMを動かすのも苦労する8GBしかメモリのないWindows PC、紙にコードを印刷して説明しないと納得しない品質保証部、
手作業で実施しExcelにチェックを付けていくテスト、jquery一つ使うのに3ヶ月かかる承認フロー、開発中にバグを一つ出すごとに
ひたすら反省文を求める品質保証部と一緒になって詰めてくるマネージャー、常にコンパイルできないtrunk、
Java 5の時代から進化しないコード、使いにくい社内ミドルウェアの利用を強制される設計、開発期間の半分以上を占める最上流設計、
一旦書いたコードは消してはならずコメントアウトしないといけないコーディング規約など、数を上げればきりがない。
色々改善活動を頑張ったものの、結局Subversionの導入も品質保証部がついていけないから、ということでClearCaseといわれる
今ではほぼ誰も使ってないであろうバージョン管理ツールが使われ続けることになった。使いにくい社内ミドルウェアは
研究所がその道のプロと聞いたので一緒に改善を図った。そしたらRubyしか書いたことがない文系新卒の子が出てきた。
一応研究所の人だし…と思って新バージョンのプロトの開発を依頼したら、1分以上稼働できない状態になって出てきた。
研究開発は準委任相当なのでそれ以上修正を依頼できずに期間が終わった。
また前の会社独特の文化として、大きなバグを出した開発者の反省会（社内ではとある固有名詞で呼ばれている）があった。
この反省会のターゲットになった開発チームはその資料準備で開発が1〜3ヶ月ほど止まるほど大掛かりなイベントだ。
このとき、担当の品質保証部は「連帯責任だから」という理由で資料レビューに大変な精を出す。余計なお世話だ。
このため10〜20ページほどの資料を毎週レビューにかけて最高のものにしていく。でも結局本番では幹部からの怒号が飛んで終わりである。
連帯責任とかいっていた品質保証部は幹部と一緒になって詰めてくる。連帯責任ではなかったのか。
幹部によると、この反省会があるから今の会社があるんだそう。これを経験して一人前らしい。
こんな感じで開発の体制はひどかったが、世間一般ではホワイト企業と見られている通り有休は取りやすかった。
そのため、転職活動を始めた。そしたらなんと「メモリ32GBのマシン」「mavenが気兼ねなく使える回線」「自動テスト」
「GitHub」「CI/CD」 という発言がポンポン出てくる。メルカリだのGoogleだのといったイケイケWeb系ではなく、
いわゆるSIerでもだ。最初は何だこの格差はと思ったが、まぁ営業トークなんだろうな、と思い直した。というわけで
イケイケWeb系も内定は出たものの、つい安定をとってしまい某大企業のDX系の部署に転職した。
そしたら何だこれは。最高スペックのMacBook ProからGitHubにpushするだけで自動デプロイで即サービスイン、
問題が発生したら社用携帯に通知が飛んできて、クラウド監視サービスでログをチェック、即修正即デプロイ。
社内の連絡はSlackで、スタンプを押せばIssueがたち即関連部署が対応に走る。OfficeツールはGoogle Docsで、
計算表はちゃんと表として使っている。開発者はちゃんと開発をしており、反省会の準備や品質保証部の接待なんて業務はなく
純粋にエンドユーザーだけを見ている。ここはなんて最高の環境なんだと歓喜した。また個人的にはおまけ程度であるが、
年収は30万ほど増えて大台に乗った。
さて、それから3年がたった。人間というのはいい環境になれると対して喜びを感じなくなる、というのはそうだと思う。
今では別にdeployブランチにマージされたらCIが走って自動でテストが走りデプロイされるのも、だから何？
って感じだしまぁ普通の仕事として淡々とやっている感じはする。待遇面で悪化した点もちらほらあるし
（例えば年間休日が5日ぐらい減った、残業が月5時間ぐらい増えたなど）などもある。
ただ一つ言えることは前の会社には戻れないな…ということである。人間一度生活レベルを上げてしまうと下げるのは
ただ、一つだけ今の会社に転職してよかったと感じ続けられることが一つある。それは人だ。
前の会社では家でプログラムを書いているなんていった日にはおちょくられたり、人生楽しいの的な目で見られたりした。
芸能人とゴルフの話ができないとコミュ障扱いされた。そのため仕事の話はしても、飲み会にはできるだけ行きたくなかった。
でも今の会社では雑談としてFastlyが落ちても大丈夫なCDN構想とか、AtCoderの話をして盛り上がることができる。
ダイバーシティなんていうが、人間は所詮同質な人間同士で集まったほうが快適なんだな・・・という複雑な思いを抱いている。
皆さん読んでくれてありがとうございます。いくつか質問が出ているので答えられる範囲で答えます。
真面目な疑問なんだけど、Java5のコード書いてる人を1000万で雇う会社があるの？どういうモチベーション？？
製品自体が90年代から脈々とバージョンアップしている企業向けのソフトウェアなので、コードベースが古いというのがあります。
またユーザーからすると中身がJava17だろうがJava5だろうが関係ないわけで、要は業務が滞りなく進めばよいわけです。
そのため昔から受け継がれたスパゲッティコードを地道に解き明かし、新しく出てきた要件を今までのコードベースを壊さずにバグなしで追加していく、
もとからあったバグについては、その他の数百万行のユニットテストもないコードに影響なしで修正を施す、といった技能が必要になります。
こう考えると意外と希少なスキルなんだな・・・と思えるかもしれません。
clearcaseよりもsubversionの方が100億倍導入も運用も簡単だと思うんだけど品管どうなってんの？
ClearCaseご存知な方がいるんですね！一から作る製品だとSubversionのほうが簡単かもしれません。ただ、ClearCase専用の
社内ツールがいくつかあり、そのツールで出力した情報を社内資産として持っているという理由があったりします。
例えばお客さんから「この機能がバグってるっぽい」というクレームを受けた際、その機能周辺の情報をそのツールから検索し、
コードレベルで再発防止策を関係部署総出で練った上でお客さんに回答する、という運用フローになっています。
そのため、Subversionに変えるためには開発陣の一存では無理で、品質保証部やマネージャー層など全ての知識のアップデートが
必要になり、そこまでコストをかけて説得して回る必要はあるのか・・・という話になってしまうわけです。
ただ、社内の生産性を向上させるのが目的の部署としてはSubversionやGitを社内に浸透させたがっているのも事実で、
新規プロダクトなんかはGitを使っていました。ただしGitHubはプロキシでアク禁されているだけでなく、サービス名名指しで使用禁止
になっているので、相当の理由がない限り使えないかと思います。
主任クラスでも1000万円近くもらえるのか。すごい。
1000万という数字に興味のある方が多かったので参考までに書いておくと、等級ランクというものが存在して管理職を除く最上位のランクに
なると2人の子持ち、賃貸住まい、標準評価で大体900万になるという感じです。年功序列だが部署ごとに違うというイメージで、
研究所だと20代で到達する一方、利益を上げていない事業部や間接部署だと定年間際まで到達しない人も多い、ぐらいの感じです。
平均では30代中盤ぐらいでしょうか。
ちなみに私の場合は基本給は33万程度ですが、そこに裁量労働手当と住宅手当、家族手当がついて月給で50万を超えるぐらいでした。
ボーナスは個人評価よりも部門業績に大きく左右されるのですが、部署が最高評価の場合は夏冬とも150万以上でした。
最後の最後のダイバーシティについては、ダイバーシティを勘違いしているように思う
経験豊富なプログラマほどこの言説をすっと理解して、経験の浅い人ほど理解できないらしい。
よくある誤解に「学習のためには車輪の再発明をした方がいい」というものがある。
これは間違っている。学習のためであっても、既製品の劣化コピーを作るよりも、既製品を利用した方が学ぶものは多い。
たとえば、初心者がデータを保存するしくみを試行錯誤して実装したところで、既存のリレーショナルデータベースよりも良いものができるはずがない。
一方、最初からデータベースを使っていれば、単にデータを保存すると言う目的を達成するだけではなく、主キーや外部キー、インデックス、トランザクションやSQLなどの重要概念を学ぶことができる。
プログラミング初心者が車輪の再発明をするのは将棋で言えば、駒の動かし方を覚えただけの初心者が「一手目は76歩がいいのか26歩がいいのか」なんてことを延々と考えているようなものである。そんなことに意味はない。そんなことをするより、さっさと定跡を覚えた方がよい。
さて、経験豊富なプログラマほど「コードを書くな」というのがすっと腑に落ちるのは、それがどういうことなのかを理解しているからだ。
たとえば彼らは、「設定より規約」という概念について、具体的な実例とともによく理解している。
一方、経験の浅いプログラマは、設計やコーディング能力も低いし、複数のパラダイムや良いフレームワークにも触れたことが無いから、「コードを書かない」というのが何を意味するのか理解できない。だから、「コードを書くな」という主張も理解できない。
pythonの場合、組織でコーディングスタイルを制定するより「PEPに従え」と言ったほうが効率よいと思ってて、オープンソースのコードを使う場合も大抵PEP使っとけば整合性取れる。
ただ、なんでGoogleがインデントでスペース4ではなく、スペース2を採用しているか謎でめんどいのだけど。
いっとくが、俺は「Googleに勤めてる」なんて一言も言ってないからな某JO。エンジニアしてりゃGoogleの公開したコードを使うことぐらいあるんだよ。
コーディングに集中しているときに挨拶されると集中力きれるからやめてほしい
みたいなコメントがあってうぜえ
所詮仕事なんてコミュニケーションが一番大事なの。てめえのせいで職場の雰囲気が乱れて全体の出力が下がったらおまえ責任とれんの？
あー、いま「そんな古臭い職場は糞だ」と言おうとしただろ。わかるよ。
でもお前が現に働いてるのはそのクソの職場なんだよ。いいかげん自覚しろ。お前もそのレベルなんだよ
つーか、どーせ挨拶しないのがカッコいいとか思ってんだろ？集中してる俺カッコいいとか思ってるんだろ？
その気持わかるよ、俺もそう思ってた時期があったからな
早くお前が大人になってくれるのを願ってるぜ
CLIのプログラミング環境って話があまり一般的な話ではないから誤解した。
というのも、Androidアプリとかを作りたい場合は環境がGUIになるのは必然だが、インフラ側で動作するスクリプトを書く場合は、GUIのない環境でCLIだけでコーディングする場合があるからCLIを使う場合も多い。
https://blog.tinect.jp/?p=70708
下手で良いからどんどんアウトプットしろという中国のなんか偉い人の格言だ。
「あ〜これ俺が未だに出来てないやつ、、こんな親が居たらもうちょっと楽に生きれたかな」とちょっと親のせいにした自分に気づいて凹んだ。
訳あってweb制作の勉強を始めて、独学でどうにかこうにか学んでポートフォリオサイトを作るところまで来た。
勉強を始めてから自分の完璧主義を改めて自覚し、修正を試みながら取り組んできたつもりだけど、それが中々上手くいかず、仕事に出来たとしてもこなせるのか不安要素になっている。
数をこなさないと速度も質も上がらない。
遅巧拙速を知ってからそれを散々頭に言い聞かせているのに、いざ制作が始まると、出来るだけ良いものにしたいという意識が段々強くなり、自分で立てた締め切りをぶっちぎる。
記事にもあるような「まずは試作品作るくらいの感覚で作って、見せたりフィードバック得ながら整えようぜ」理論、完璧主義の修正に一番必要な視点だと言うのはよく分かる。
デザインを見せたかったらデザインとして作り切ってないといけないと感じるし、コーディングを見せたかったらコーディングとして機能を作り切ってないとフィードバックをもらう意味がないのでは？と思ってしまう。
見る側も本気で作ったものをレビューしたいはずだし、適当なものを出すのは失礼だと感じてしまう。
自分が納得いっていないものを人に見せる、ということへの抵抗がやたら強いという要素もあるのだろう。
数こなしてない自分の納得感なんて大したものじゃないとこれを書いている今は思うけど、作ってる時はそういう客観性も吹っ飛んでしまう。
結局はバランスで、適当にやりすぎても何も残らないと思うし、良いものを作ろうという気持ち自体は
悪いことでは無いとも思う。
ただ、その気持ちがスケジュールという優先順位を無視し始めることが問題。
毎日継続することだけは出来ているだけに、このバランス感の無さが悔しくて悔しくて悔しくて悔しい。
その割には大したアウトプットにはなっていないのだろう。
有能なはてなの皆さん、お知恵をお貸しください。
エンジニアは、「休みの日も勉強しないと行けない」「休み日もコーディングしてる」という話がある。
ビジネスサイドも同様に、休みの日でも勉強、仕事をしてる。それに反意があるのも知ってる。
がしかし、やっぱりやってる人とやってない人で大きく差が付く事は確かである。
北欧の何処の国か忘れたが「日曜日はお店を閉める事」という法律が出来た。
その国の人々の多くは、法律に従って店を閉めた。そして、休みを謳歌した。
が、アジアから移民の店は方を破った。日曜日も一生懸命働いたのだ。
結果、その店は儲かり、他の店は衰退していった。
この場合無理やり法律で縛ったから、日曜日開けた店は違法であり、悪者だが法律がなければ勤勉な店である。
