僕が考える「良いコード」 - give IT a try
こんなコードだとわかりやすい 僕が考える良いコードの特徴（条件）を挙げてみると、 ぱっと見たら、だいたい何をやっているのかがわかるメソッド名 ぱっと見たら、だいたい中身が何なのか想像がつく変数名 ぱっと見たら、だいたい何をやっているのかが把握できるメソッドの内の処理フロー 驚きが少ないメソッド 副作用が少ないメソッド（責務が1つしかないメソッド） DRY原則を守っているコード だいたいこんな感じ。 つまり「すんなり読めて、すんなりわかるコード」が理想。 プログラムが小さいうちや、一人で開発しているうちは「汚くてわかりにくいコード」であっても「自分さえわかればOK」で済んじゃうけど、プログラムの規模が大きくなったり、複数人で開発するようになると、「汚くてわかりにくいコード」は絶望的に開発効率を下げる。 こんなコードはわかりにくい たとえば上の反対で、 メソッド名だけ見ても何をやっているのか想
好きなものと向き合う｜ばんくし
私は、プログラミングが好き、インターネットが好き、家族が好き。 そういう記事を書いてみる。 プログラミングとの出会い個人的にはあまり良い出会いではないなと思っていたので書いた事がなかったけど、私はあまり中学に行けてなかった故にプログラミングを初めている。今はどうなのか分からないし、誰かが気付いていたのかもしれないし、成績でカバーしてたのかもしれないが、当時私が通っていた中学校は牧歌的で、何となく誤魔化して休んだり途中で居なくなっても何とかなった側面があったので、親も仕事で居ない日中の家に籠もってはリビングの共用PCでよく遊んでいた。 当時UWSCというWindowsを操作するためのフリーソフト（動的型付け言語とそのインタプリタ）があり、義務教育に導入されつつあったeラーニングなるシステムを自動化したのが最初のプログラミングだと思う。数日に分けてやるはずのeラーニングの課題を数分で解くそのプ
どうして自分を過小評価するのかと言われた話
忘年会の時に、「おじさん(私のこと)って自分のことをできないエンジニアであるふりをするけど、どうして？」って言われたのだが、いざどうして自分がそういうふりをするのかを言語化しようとしたら難しかったので、時間をかけて言語化してみた。 ぶっちゃけ自分はできないエンジニアではないと思っている まず「できる」「できない」の定義だが、ここではしない。 いろんな人と比較されて「できない」側の人間として扱われてきた自分にとってその定義は考えたくない。 「できない」の定義は人を傷つけると思うのでしたくない。 なのであくまで読者の感覚的な尺度で解釈して欲しい。 自分はいわゆる別業種からの転向組で、エンジニアとして働き始めたのは 2018 年なので今年で 5 年目エンジニアだ。別業種からの転向ということでコンピュータサイエンスを大学で学んだ者・小学生の頃からバリバリやってきた者・新卒でエンジニアになって研修や
K&R - 苦しんで覚えるC言語
C言語を志す人ならば、おそらく、K&Rという書籍の名前を聞いたことがあるでしょう。 K&Rとは、世界初のまともなC言語の解説書です。 この本は、C言語の開発者自身が執筆していたこともあり、業界では大ヒットとなります。 K&Rは、コンピュータ業界最大のベストセラーとも言われます。 この本は、C言語のとても細かい部分まで踏み込んで説明してあり、 当時は、C言語のマトモな規格なんてものはなかったので、 このK&Rを元にしてC言語のコンパイラが作られていたほどです。 しかし、筆者は、皆さんがK&Rを読むことはオススメしません。 というか、むしろ、読んではいけません。 1つ目の理由は、説明がわかりにくすぎることです。 この本を読むには、C言語にかなり精通していないと読めないと思います。 そもそも、書籍自体、初心者が読むことは考えられていないようです。 2つ目の理由は、サンプルプログラムの中で、ポイン
リリース手法多すぎﾜﾛﾀｧ B/G、カナリア、機能フラグ、ダークローンチ、A/Bテスト、、など - Qiita
この記事でCloudWatch Evidentlyについて調べていると、「機能フラグ」や「A/Bテスト」などインフラエンジニアには若干聞き慣れないリリース用語が出てきました。 アジャイル開発やCI/CDの台頭に伴い多数出現したこれらのリリース戦略用語をまとめて整理してみることにします。 インフラエンジニアやSREと呼ばれるロールの方々も、リリース戦略を知っておくとCI/CD環境の構築やIaC、はたまたミドルウェアのバージョンアップなどで役立つと思います。 以下ウェブサイトを参考に、各用語を「デプロイ戦略」と「テスト戦略」の大きく2つに分けて紹介します。 デプロイ戦略 従来型のデプロイ（インプレースデプロイ） システム本番環境が一種類のみ存在し、新バージョンの資材デプロイによって旧バージョンの資材を上書いてしまうパターンです。 環境の設計や管理、維持コストをシンプルに抑えられるメリットがあり
30歳になった
30歳になったので20代を振り返ってみる。…と書き出したものの気が進まず放置していたら31歳がすぐそこまで迫っていた。31歳になったらさすがに書く気がゼロになりそうなので、今のうちに雑に書き切ることにした。 振り返り（時系列順） 大学を1年休んで海外を周った（写真）。これまでの人生でいちばん刺激だった1年間だった。 新卒で某大企業に入社したが適性が無くてすぐ辞めてしまった。「ここでやっていけなかったらどこでもやっていけないから」と忠告してくれた先輩、あなたのおかげで辞める決断ができて結果的に大正解でした。本当にありがとうございます。 プログラミングとデザインという最高の楽しみを見つけた。一生やっていきたい。 犬を飼い始めた。毎日1時間の散歩中に考えごとするのが習慣になった。自分が20代に作ったWebサイト/サービスのアイデアはだいたい散歩中に生まれた気がする。保護犬はいいぞ。 家の近くでヒ
頭が痛くならない「ダメージ計算式」の基本の話｜だらねこ
戦闘のあるゲームを作るなら、考えないといけないのがダメージの計算式。でも、計算式のコツとか基本とか調べると、小難しそうな話が出てきて め、めんどくせぇ～ってなったりしませんか？私はなります。色んな計算式とその特徴を羅列されても、よくわかんなくなっちゃう。 とはいえ私もゲームデザイナーの端くれなので、ダメージ計算式を考える機会がそれなりにあります。そして他人の作った変な計算式に苦しめられることも、いっぱいあります。泣きたい。 大元の計算式が悪いと、それを利用してバランス調整しても苦労する事が多いんですよ。なので、そんな悲劇を少しでも食い止めるためにもですね。 この記事では 数字が苦手な文系の人でも、なんかいい感じに計算式を考る…とっかかりになることを目指して書いていこうかと思います。 ※こういう計算式がある！選んで使え！！という記事ではありません。 ※計算式を考える時、こういうのを把握して、
NHK記者がプログラミングをしている記事を見て、正直悔しかった｜近藤佑子
話題になっていた、NHKの記者が、プログラミングで身近な業務の困りごとを改善していることについて書いた記事を読みました。 とてもいい記事で、AIやIoTなどの先端的なテクノロジーを使っていなくても、ITエンジニアをたくさん抱えて内製化しなくても、現場の記者が手を動かして、プログラミングで身近な課題を解決しているのがとてもぐっときました。 「地味なツール開発の積み重ねが新しいサービスの創造や、職場の『DX』といわれるものにつながる」と書かれているのはまさにそう思います。 書き手である三輪解説委員は、1998年、インターネットをまだ利用したことがなかったにも関わらず、記者として「情報セキュリティー」の回を担当することになり、ネット犯罪やセキュリティー対策の専門用語がわからないまま、取材先に何度も確認し、一本のニュース特集を制作したとのことでした。 そのことが、三輪解説委員にとって、国内では当時
記者に「プログラミングのスキル」って必要なの？ちなみにNHKニュースの画像生成も記者がコードを書いてます｜NHK取材ノート
記者に「プログラミングのスキル」って必要なの？ちなみにNHKニュースの画像生成も記者がコードを書いてます 新型コロナウイルスの新規感染者の数を示す日本地図に、毎日厳しい視線を送る男がいる。 コロナの感染拡大の今後が懸念されるが、地図がきちんと描画されているかも気になってしまう。 それはこの「新型コロナ感染者数マップ作画システム」をプログラミングしたのが彼だから。 ちなみに彼は技術部局のエンジニアではなく、いつもはテレビで解説している記者だったりする。 このシステム、記者が作りましたこんにちは、NHK解説委員の三輪誠司といいます。専門はITやサイバーセキュリティで、主に「シブ5時」や「くらし解説」などでニュースの解説を担当しています。 新型コロナウイルスの「感染者数マップ作画システム」は、1週間で作成しました。 言語はJava、地図はSVGで、ブラウザの画面をそのまま放送で使っています。SV
「仕事のコード」を残す際のチェックリスト｜Uchio Kondo
最初に注意: この文章は「はじめに」「総論」が長いです🙃 追記＠2021/08/11 17:46想像よりはるかに反響をいただいたので、せっかくだからと要点をMarkdownにしてGitHubに置いてみました。何かにご利用ください。 はじめに・「仕事のコード」、つまり、業務などで作ったコードが、なるべく負債にならず、なるべく俗人化しないようにするために留意すると良さそうなことを自分の経験などから列挙したものです。 ・ちなみに、「対象読者」に書いてありますが、そもそものモチベーションが「非エンジニアがノーコード系のサービスで作ったシステムが最近増えつつあるような...」というところでした。こういうのどう取り扱うといいんですかねとなった時、まずは運用できる形にしてもらいたい、という狙いがあります。結果的に、ジュニアなエンジニアが良いシステムを残す上でも使える知識かなと思います。 ・個別の項目に
ただプログラムが好きな会社員が、趣味でゲームを作り始めたら5年続いてNintendo Switchに3本ゲームを出していた話。Switch版『レイジングブラスターズ』発売記念インタビュー - ゲームキャスト
「俺の考えた理想のゲームを世に問いたい！」 インディーゲーム開発者の話を聞いていると、大抵は作りたいゲームがあって、業界に身を投じている。 しかし、「プログラムで物を作るのが楽しいから、ゲームを作ってみるか」と、理想のゲーム像がないところから業界に入り、5年で Nintendo Switch で3作もゲームを出すに至った珍しい開発者がいる。 2021年6月24日に『レイジングブラスターズ』を Nintendo Switch 向けにリリースした Terarin さんだ。 今回、新作発売記念でゲーム開発を始めたきっかけから、Nintendo Switch でゲームを出すまで、世にも奇妙な経緯を聞けたので、皆さんにお届けする。 正直、インタビューを通じてこんなに「独特だな」と思えた人は私の経験からしても少ない。 ゲーキャス： Terarin さんは、初めてゲームを出してから5年で Nintend
プログラマーがドキュメントを書かない理由
この記事は、著者の許可を得て配信しています。 Why programmers don’t write documentation 最近ではずっとコードのドキュメンテーションに関連した記事を書いていたので、当然、私のMediumのおすすめ記事には「開発者がドキュメントを書かない本当の理由」という記事が表示されるようになりました。この記事では、ドキュメントを書くための優れたツールがないことが、ソフトウェアエンジニアが自分の作業や判断をドキュメンテーションする意欲を失わせる最大の原因について書いています。 私は普段、特定の記事を批判したりはしませんが、この記事には怒りを覚えました。このライターは図解ツールについていくつかメリットに関して述べてはいますが、全体的に誤解を招くような内容になっており、この重要な問題をより分かりにくくさせています。2つの図解ツールを比較して、どちらも不十分なツールである
コードが読めるソフトウェア開発者 - As a Futurist...
僕はコードを読むのは得意な方だけど、それが過ぎてコードを書かなくてもシニアソフトウェア開発者になってしまった。実はコードをちゃんと読めるソフトウェア開発者って希少価値が高いのではないか、と思ったので自分がどんな感じでシニアになったのかをまとめてみた。似た様な人の参考になれば幸いだ。 同意。僕は未だ書く方はほとんど機会なく成果もないけど、コードを読み尽くして、負荷試験や本番で挙動を把握し続け、メトリクスでとことん確かめていった結果、Sr. Engineer になれた。 https://t.co/KXtMdEaRr8 — Ryosuke Iwanaga (@riywo) April 16, 2021 コードを書かなくてもシニアソフトウェア開発者になれた 僕は今 Amazon の Sr. Systems Development Engineer という職種で働いている。いわゆるソフトウェア開発職
小6でゲーム作りを夢みて大学4年間をプログラミングに費やした僕のゲームが、あした全国のゲーム屋さんに並ぶ話 - プログラミングで世界を変える
今の会社に入って1年半が経った。入社してからずっと取り組んでた大きなタイトルが公開されて、それが明日大きな節目を迎える。会社にとっても大きなことだし、僕個人の人生にとってもひときわ大きな出来事かもしれない。 これは、小6でゲーム作りを夢みて大学4年間をプログラミングに費やした僕のゲームが、あした全国のゲーム屋さんに並ぶ話。 1番古いゲームの思い出は『ポケットモンスター クリスタル』だった。 引用元: https://amzn.to/2OCXGlR , https://www.nintendo.co.jp/3ds/pokemon_crystal/index.html 当日のゲームボーイ用のカートリッジは内蔵してある電池を使ってセーブデータを保持してたのだが、僕が持っていったクリスタルはこの電池が切れていたためセーブができなかった。その上、幼い頃に1日中ゲームをやっていて怒られたことがあったら
お前は絶望的にプログラミングに向いてないから諦めて刺身にタンポポ乗せる仕事でもやってろ｜古都こと｜note
刺身にタンポポ乗せる仕事ってきょうび言わねーな……。 プログラミングとは、勉強も運動もスマブラも下手なクソ隠キャ中学生が「俺もパソコン1台で凄い技術者になって…！」とワクワクしながら始めるものの思ったより普通に難しいし学校の試験で出たような知識要求されるしで3日で放り投げ、10数年後にnoteで「お前らは絶望的にプログラミングに向いてないからやめろ」なんて記事を書くだけのザコに成り下がる、夢と希望に溢れた技術である。 近年ではパソコンのスペックの上昇にともないできることも増え、どこのご家庭にもあるRTX2080で簡単にディープラーニングもできるようになった。Unityで3Dゲームをバリバリ動かしてもブルースクリーンは出ない。やっぱ世界を広げるのは小賢しい知恵よりもスペックの暴力だぜ。 開発環境や言語も選択肢豊富で、エディタもかつては有料クラスでも手に入らなかったような贅沢な機能が満載のもの
【まつもとゆきひろ氏 特別講演】20代エンジニアのためのプログラマー勉強法まとめ - 素人Web屋の備忘録
先週末にサポーターズさん主催の【まつもとゆきひろ氏 特別講演】20代エンジニアのためのプログラマー勉強法 に参加してきました！ これまで技術的なことしか書けていなかったのですが、とても学びが深い講演会だったので初めて雑記的にまとめを書いてみようと思います。 内容濃すぎ && 80分 という講演会だったのでざっくりまとめです！ 講演会の様子はyoutubeで配信もされたので、このブログの最後にURL貼っておきます。 以下Matzさんによるプログラマー勉強法まとめ 今回「勉強」という言葉を使ったのはあえてミスリードを誘う目的。 具体的には「（学校）勉強」には「苦手を克服するべき」というメタファーがある。 「苦手を克服するべき」は社会人の勉強では間違い。 学生と社会人の勉強の違い9つ 1.満点VS満点なし 社会人の勉強に満点がない、つまり上限がない。平均値や偏差値がないから学生時代の常識が通用し
コードを書き続ける
「開発者は経営者になったらコードを書くのやめて、経営に集中すべき」という考え方を聞いたことがある人はいるだろうか？ 自分はこの考えを持っていた経営者の元で働いていたことがあるので、強く印象に残っている。そして優秀な開発者たちが無理やりコードを書く時間を取り上げられ、経営者とされていったのを何度か見ている。 ここに書くのは自分の経験談であり、こうすべきとかではない。そしてなにより自分は死ぬまでコードを書き続けたいと考えているタイプであるということだ。 伝えたいことは一つだけでコードを書き続けたい経営者からコードを書くのを取り上げるのが良い方法だと思わないということだ。 また、経営者だから偉そうにコードを書くとかは当たり前だがなしだ。経営者関係なく、ただの開発者としてコードを書くという前提のお話。 開発者と経営者起業して 5 年が過ぎた。経営者としても 5 年、開発者としても 5 年。社員をし
プログラミングを教えるときの10のポイント (という論文の紹介)
1. ギークの遺伝子なんてないことを心に留めようよく、「プログラミングには得意不得意がある(some kids get it, and some kids don’t)」とか、さらには「プログラミングには向いていない子がいる」とか聞きますね。 大学のコンピュータサイエンスの授業の成績分布が、とても良く理解できる生徒と何もわかっていない生徒にくっきりわかれる、という話も聞きます。本当でしょうか？Patitsasらの最新の研究によると、実際にはそんなことはなく、くっきりと成績の分布が分れてしまったコンピュータサイエンス入門のクラスは、5.8％に過ぎなかったそうです。 この論文では、「プログラミングには得意不得意がある」という迷信は、プログラミングを学びだしたときに躓きがちな生徒でなく（意識的か無意識的かにかかわらず）、スムーズに学ぶ生徒の方へ教える時間や熱意を費やすことにつながり、ひいてはコン
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub Copilot · Your AI pair programmer
エンジニアは英語を勉強した方がいい、英語ができないとつける変数名がめちゃくちゃダサくなる「kishName」
