プログラマをクソコードで殴り続けると死ぬ - megamouthの葬列
ここにクソコードがある。 誰が作ったかはわからぬ。それが、どのような経緯でクソコードとなったのか、 あるいは、最初からクソコードであったのか、それらは全てクソコード自身が知るのみである。 ファーストコンタクト ある日、営業からシステム案件を打診されたので見積もりして欲しい。というメールが来る。 とある企業の既存システムに機能を追加する簡単な案件ですが、なななんとソースや仕様書をご支給いただけます！ と、それはサンタにプレゼントが貰えると信じて疑わぬ子供のような真っ直ぐなメールである。 ソースコードが入った圧縮ファイルを受け取ったプログラマは、早速、コードを読んでみる。 そのシステムが本当にいいコードで書かれているかを判断するには時間がかかるが、 クソコードであるかはおおよそ30分でわかる。 インデントがタブとスペースどちらかに統一されていないとか、フレームワークの誤用があるとか、またはフレ
真偽値を返す関数のネーミング - Qiita
みんな exists を使ってます。 納得できようができまいが、exists なのです。 ソフトウェアの世界では、Apple と Microsoft と Google が黒と言ったら黒です。 黙って従いましょう。 このように、関数名の表現に困ったら、世の中の API を参考にすると良いです。 非ネイティブの我々では思いつかないような的確な表現が見つかることもあります。 関数の名付け方 真偽値を返す関数は if 文で使われることが多いので、頭に if を置いて最もしっくり来る表現が良いと思います。 個人的には、真偽値を返す関数名を考えるときは以下のフォーマットに当てはめるようにしています。 if オブジェクト名 関数名 「項目が選択中だったら」なら "if item is selected" なので関数名は item.isSelected() となります。 同様に「項目が存在したら」なら "
なぜ gcc はファイルの最後に改行がないと警告を出すのか？ - Schi Heil と叫ぶために
gcc が出す以下の警告。消すのは簡単で EOF に改行を一つ入れれば良い。でもこれ何が悪いのか分からなかった。 warning: no newline at end of file コンパイラが出す警告だから絶対に何か意味があるはず。調べてみると意外にもテキストファイルの定義にたどり着いた。 ということで POSIX 的に行は改行で終了していて、テキストファイルは行の集合だからファイル末尾には必ず改行が来ると。 Text File / Line - odz buffer Definitions - 3.392 Text File Definitions - 3.205 Line つまり POSIX はテキストファイルにもちゃんと定義を定めていて、最後に改行が無いファイルはその定義に違反するから警告を出す。 There is also some confusion as to whethe
66歳からプログラミングを始め、自作の罠で年間90頭の猪を狩る猟師がいるらしい | Tech2GO
更新日: 2017年9月26日公開日: 2017年5月18日66歳からプログラミングを始め、自作の罠で年間90頭の猪を狩る猟師がいるらしい こんにちは！Tech2GO編集部の岸本です！ 皆さんは「猟師」と聞いてどんな印象を持っていますか？「田舎」「銃を撃って鹿や猪を狩る」「本当に猟師なんて存在するの？」などでしょうか？ 実は私も滋賀県で猟師として活動しながら本メディア「Tech2GO」にて勤務しています。猟師がIT系の会社にいるなんてびっくりですよね。ちなみに普段僕は鹿を狩っています。 ↓こんな感じです。 そんな、普段出会うことの少ない猟師が「Ichigo Jamを使った獣用の箱罠を自作」し成果を上げていると聞き、シニアプログラミングネットワーク #1に登壇されるとのことで滋賀から東京まで行ってきました！ 「ichigojam」とは、子供向けの安価なプログラミングが可能なパソコンのことです
プログラム日本語で書けばいい気がするけど（追記した）
定期的に思うんだけどプログラムで無理な英語にせず日本語にすればいいのにって思う。 （実践はしていない） 日本語で書ける言語使うんじゃなくて変数名や関数名がUnicode対応で日本語書けるもの。 日本語でいいと思う理由は主に２つ ○画面に表示する時 フレームワークや言語にもよるけど表示するときに英語の名前から日本語の名前に変換して表示って手間があるものがある。 最近見かけた例だと.NETでプロパティの属性に表示名書いて表示するときに取り出していた。 最初から日本語だとそのまま表示でいいことが多くて一段手間が省ける ○英語がわけわからん まず自分が英語化するとき。 いい単語が出てこないとか、しょっちゅう。 慣れが必要だし慣れてもなんかコレジャナイ感とかで苦戦する。 次に他の人の英語化したのを見る時。 その人の英語力にもよるけど、動詞名詞が変に混ざっていたり、sがついてたりなかったり、そもそもc
新人エンジニアこそちゃんと調べてちゃんと知りちゃんと考える - Qiita
本稿について 本稿は、 学生時代にHTML,PHP,Javaくらいなら触った事あるかな程度の配属4ヶ月目の新人である自分が、 ほぼ初めてJavaScriptや、色んなフレームワークに触れ技術の荒波に揉まれながら、 ちゃんと調べてちゃんと知りちゃんと考える事が大事だなーとぼんやりと思ったこと を書き記すものです。 出来るだけ上流のソースを読む 分からない事に出会った時 分からない事に出会った時、まずググりますよね。 そこでまず目に留まるのは「非公式かつ目的の用途に限定された」ものです。 しかも日本語だから読みやすい！やったぜ！ 先人達の知恵と努力の結晶はありがたく活用させて頂きたい所存です。 細かいことは考えず解決！しかし… 鵜呑み型ケーススタディの問題点 その解答例が自分の環境で上手く動作するのか 似たようなケースに流用出来るのか その解答例の内側ではどういったやり取りが行われているのか説
プログラマたる者、人に頼る前にこれぐらいはやっておきたい - Qiita
はじめに 春ですね。 全国各地で数多の新人プログラマが生まれたことでしょう。 新人のうちはわからないことだらけですし、真っ当な労働環境でしたら先輩方が「わからないことがあったら何でも聞いてやー」と言ってくれます。 ですので、プログラムが謎のエラーメッセージを吐き出したりしたらすぐに質問したくなるかと思います。 しかし、個人的な見解ではプログラマのスキルが最も鍛えられるのは、わからないことを前にして自分なりに色々と調べて試行錯誤する時です。 多分、世の中の凄い人たちの中には身近に質問できる相手がいなくてひたすら自分で頑張った結果、超進化を遂げたという人も少なからずいるのではないかと... というわけで、人に頼る前に自分にできることをしっかりやることで同期に差をつけちゃいましょう! もちろん新人じゃなくても、「すぐに人に頼っちゃうなぁ、どげんかせんとなぁ」という方々にも参考にしていただけると幸
よいコミットメッセージ・よくないコミットメッセージ - 弥生開発者ブログ
こんにちは、mzpです。 今日はMisocaのesaに書いていた「よいコミットメッセージ・よくないコミットメッセージ」という記事を紹介したいと思います。 あらすじ 開発チームでは「コミットメッセージには変更理由を書いて欲しい」「コミットメッセージはWhatよりもWhyが大事」という話を何度かしているのですが、なかなか徹底できていません。 ので、もう少し具体的に「こういうコミットメッセージはよくないですね」というまとめを作ってみることにしました。 ちなみにこの過程でみつけたコミットメッセージに、こんなものがあります。 一切情報がなくておもしろいですね。 ファイル移動を移動した事実しか書かない これは以下のようなコミットメッセージです。 ファイル名を変更 ディレクトリを移動 ファイルを移動したことはコミットメッセージを見なくてもdiffから分かりますが、なぜその移動をしたかが分かりません。 の
Javaで「はじめてのプログラミング」を教えるのはキツイと思った話 - GoTheDistance
2017年4月から人生初めての新人研修講師を務めさせて頂くことになりました。プログラミング入門がテーマです。 先方は昨年までJavaでカリキュラムを組んでいたんですが、JavaをやめてPythonでやらせてもらえないかと提案し快諾頂きました。プログラミングの入門書を書いたから特に感じることなんですけど、Javaはプログラミングの初学者に向いていない言語だと思います。 クラスありきの言語設計 それがJavaの良いところでもあると思いますが、プログラミング自体が初めての方を対象に考えた場合、はじめの一歩として不適切だと感じます。 Hello Worldが重たすぎる お馴染みのHello Worldです。初めてのプログラミングで以下のコードを見たら、何のことやら分からないでしょう。 public class Test { public static void main(String[] args
プログラムを「書く」 / プログラムを「組む」
後者の表現を使う習慣がない。というかプログラムって「組む」って感じあんまりしなくない？
プログラミングでよく使う英単語のまとめ【随時更新】
プログラミングでよく使う英単語のまとめ【随時更新】 随時追加、整理していきます。 名前をつけるときには、名詞、動詞の違い、複数形、過去形などに注意しましょう。 オブジェクト指向では、クラス名は名詞、メソッドは動詞とします。 使ってはいけない言葉 get / set アクセサ (getter / setter) やプロパティによく使われている。 それ以外に使うと混乱を招くのでよくない。 get は軽量な処理と考えるので、中に重い処理は書いてはいけない。 単純な取得/設定以外で使いたくなったら他の言葉を考える。 load, save, commit, store, enable, disable, fetch, register, configure, add, etc... check 意味が広すぎて何をしているかわからない。 できるだけ別の言葉を使う。 具体的に何をしているかに分解して考え
うまくメソッド名を付けるための参考情報 - Qiita
クラス名編をつくりました あるメソッドを定義しようとするとき、そのメソッドを使う人達が名前からどんなことをするか理解できるようにするには、メソッドの内容に応じて適切な情報量の命名が求められます。 この記事では、メソッド名に用いることでどのような情報が提供できるかを見ていきたいと思います。 真偽値を返すメソッド 場所 単語 意味 例
クソコードにならない為に、これだけは守って欲しい７つのこと - Qiita
まえがき 今回書く内容は、ある程度経験あるエンジニアでも、陥りがちなものに絞って書いてみたつもりですので、[重複コードは書かない]などの超あたりまえの事は書いていません。 2017/03/16 最近よく見られてそうなので１つ追記[そもそも継承するな!!!] そもそも継承するな!!! 継承するのは、どうしようもない場合のみにしてください。 その前に、strategyパターンや、compositeパターンなどの他のやり方を考慮してもなお、継承するのが妥当である場合のみにしてください。 基本的に継承しないほうが、スケーラブルだし、テストコードも容易にかけます。 継承はis-a関係 「あー、継承ね。はいはい」で飛ばしてんじゃねーよ。 いやマジで!!! ほぼ全てのエンジニアは[is-a]が何か知っています。 というのも全てのオブジェクト思考の書籍には出てくる概念だからです。 しかし、私の経験上この概
外国人が語る：英語でクラスやメソッド等の名付け方 - Qiita
アメリカ人です。 Hello 👋 この記事の目的 多くの日本人は自分の英語力には自信がないではないでしょうか。残念ながら「英語がわからん」、「英語が全然できない」という声をしょっちゅう聞いています。でも、今まで英語ができて意味がちゃんと伝わる何人かの日本人に会ったがあります。完璧な英語ではないけど(外国人も英語でミスる時もある...)、がんばって話そうとするので充分仕事ができる人たち。そういうがんばる姿勢はオープンソースのプログラムや英語圏のプログラムに手を出すためには一番大事なことだと思います（外国人側もすごく助かります）。日本の文化では「私はできる！」と自慢することは少ない中、この記事を通して、流暢に話せなくても自分のプログラミングの命名の仕方にはちょっとだけでも自信を持たせたいなと思います。完璧じゃなくていいです。Let's go! 合わせて読んでいただきたい 【日本人エンジニア必
コピペするプログラマに足りないもの 〜 プログラミング脳の鍛え方 | Social Change!
長くなったので先に三行でまとめておこう。 コピペするプログラマが生まれるのは教育の問題ではないか（仮説） 文法は学んでも処理の流れから考えることは教わっていない（根拠） ロジックを訓練するには脳内プログラミングが良いのでは？（提案） 少し前に私のMediumで、こんな記事を書いた。タイトルが言葉足らずだったおかげで、少し話題になった。「量産型プログラマを撲滅したい」 今回の記事では、この中で書いたコピペするプログラマがなぜ生まれるのか、どうすれば良いのか、考えてみたい。 どうすれば見分けられるのか 書いたプログラムを説明させてみれば、その人が、ちゃんと考えて作れる人か、コピペでしか作れない人か、すぐにわかる。自分の書いたプログラムの流れを説明できるということは「わかって書いた」ということだ。わかっていなければ説明できない。 「わかって書く」という一見すると当たり前のことができない人もいる。
nullが生まれた背景と現在のnullの問題点 ― null参照問題（前編）
Cの系譜を継ぐC#ではnullが長らく使い続けられてきたが、最近ではその存在が大きな問題だと認識されている。前後編でこの問題を取り上げ、今回（前編）はnullを取り巻く事情について考察する。 ← 前回 連載 INDEX 次回 → 近年、nullの存在は、billion dollar mistake（10億ドル規模の損失をもたらす過ち）と呼ばれるくらい忌避されるものになっている。 nullは、低コストでそこそこ安全に参照を扱えるという意味で悪くない妥協ではあるが、技術が進歩した現在ではもう少し賢い参照の扱い方があるはずである。C#のように、これまでnullを認めてしまっているプログラミング言語で、今からそれを完全になくすというのは現実的ではないが、nullに起因する問題を少しでも避ける手段はこれからでも追加していけるだろう。 今回は、nullが生まれるに至った背景から始め、nullが抱える問
C#でのnull参照問題への取り組み ― null参照問題（後編）
最近のC#ではnullの存在が大きな問題となっている。前回（前編）で説明したnullの事情を踏まえ、今回（後編）は、将来のC#がnullをどう取り扱っていくのかを見ていく。 ← 前回 連載 INDEX 次回 → 前編では、nullが存在する理由や、nullがあることで起こっている問題などについて説明してきた。 後編では、C#が具体的にどう課題に取り組んでいくかについて見ていこう。C# 7よりも先の話でまだ仕様は固まっていないが、現状での仮実装や、検討として挙がっている項目について説明していく。 無効な値の表現 ただし、「具体的にどう取り組んでいくか」の話の前に、「型を使ったnullの許容／拒否の区別」とは別軸で「無効な値を表現するのにnull（0初期化）が適切かどうか」という問題もある。まずはこちらについて話しておこう。 型情報の紛失 nullは、どんな型だろうが一律に0埋めすることで、最
文系人間のJava再入門0: プログラミングという行為に対する理解 - Qiita
プログラミングの学習速度が本当に十人十色問題 学校の授業でJavaを習ってみたけどなんだかよくわからないという話を聞きます。プログラミング言語の初期の初期の段階でつまずいてしまう理由を日々悶々と考えた結果を改めて吐き出す記事です。 プログラミングを学びだしたけど，正直全然わからないという学生の助けになればと思います。思いのほか長い文章になってしましました。 私 英語のできない文系（専攻は哲学でした） 最近はElixirとRustを自習中 Javaも好き 趣旨 計算機システムがよくわからなかったり，アルゴリズムがよくわからなかったりしても，想像力で何とかしていたあの頃を思い出しながら，「こんな理解の方法があってもいいんじゃない？」とゆるく提案する。 文系は文系なりの方法でプログラムと向き合う Hello World 多くの言語のサンプルなどで最初に触れるのはこの「文字列を出力する」という処理
「プログラミングは簡単に学べる」という嘘 | UX MILK
プログラミングを学ぶことは簡単なことではありません。それは誰でも知っていることです。 ですが、残念ながら「プログラミングは簡単！」といった文句でビジネスをしようとするマーケターはたくさんいます。彼らのプロダクトを使えば、あるいはそうなるのかもしれませんが。 Hearing the WWDC keynote say coding isn't hard frustrates me. It's extremely hard. You're setting beginners up for huge disappointments. — Tyler McGinnis (@tylermcginnis33) 2016年6月13日 WWDCキーノートで「プログラミングは難しくない」と言っているのは本当に腹が立ちます。ものすごく難しいですから。初心者を騙してがっかりさせるだけです。 誰かがあなたに対してプ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
良いデバッグログはプロジェクトの資産である
