未経験のプログラミング言語を学ぶ際は、大抵の人が ・入門書を手に入れる ・環境を整えてみる ・実際に入門書に書いてあることを打ち込んでみてその通り動くか確認する という手順で学習を開始します。完全に初学者ならばそれでもいいと思いますが、もし過去に少しだけプログラミングを触ったことある人や、別言語経験者、言語は経験があるけど新しいフレームワークを学び始めた（たとえばJavascriptは経験していて、これからReactを学ぶなど）際は、それだけだと物足りない…というか大して学びは得られません。 実際progateでも、特に動的型付け言語間ならばある程度一つの言語で業務経験あるならば未経験の言語とはいえカリキュラムをこなすだけなら退屈です。 また、入門書の後半には多少実用的なソースコード（「TODOリスト作ってみました」等）があるケースが多いですが、そのままですと「関数化されていない」「変数が
目次 プログラミングの変数・メソッドの命名でよく使う英単語 ログイン・認証 許可・権限 ネットワーク ファイル操作 外部入出力 データ入出力 データベース操作 オブジェクト操作 生成・構築 削除・破棄 変更 変換・結合・排除 分割・切り出す（スライス） 登録・設定 検索・置き換え 状態・状態変更 計算 プロセス操作 処理サイクル 確認（１） 確認（２） 比較 その他対で使う単語 コード・ID・引数（変数） 機械学習関連 その他（未分類） データベーステーブルのカラム名の工夫（変数） 変数の頭につける接頭語 プログラミングの変数・メソッドの命名でよく使う英単語 プログラミング時の「メソッド名」「変数名」の命名で使いそうな英単語を「同じ意味でもニュアンスによって使い分けされるもの」あたりを注意してまとめます。 ログイン・認証 単語 意味 log_in/log_out ログインする/ログオフする
いま学ぶべき第二のプログラミング言語はコレだ！ 未来のために挑戦したい9つの言語とその理由 業務に必要なだけではなく、コンピュータによって問題解決できていない分野を切り開き、エンジニアとして戦っていくため、刺激的な第二プログラミング言語に挑戦しましょう。Rust、Go、Erlang、Elixir、Clojure、Scheme、OCaml、Haskell、Scalaを紹介します。 みなさんが使えるプログラミング言語はいくつあるでしょうか？ ひとくちに「使える」といっても、ひととおりのチュートリアルは終えたという段階もあれば、言語仕様（あれば）やライブラリを知り尽くしていて、思いついた処理を即座にコード化できるという段階もあります。リファレンスとか参考書を見ながらであれば使える、ということも多いでしょう。 ベテランエンジニアなら、いろいろな仕事に携わっているうちに、さまざまな環境でそれぞれ必要
コードはたいてい一度しか書かれませんが、何度も何人も読むことになります。 普段何気なく書いているコードが他人の時間と精神を削っているかもしれません。 そんなわけで、個人的に辛いなと思うことを 9 つ挙げてみました。共感してもらえるものもいくつかあるんじゃないかと思います。 実体にそぐわない変数名 見分けの付かない配列とハッシュの変数名 呼び出し元で true/false を指定するだけの引数 暗黙の実行順序 [] メソッドの定義・Array の継承 ハッシュの乱用 密結合した mixin 過剰な nil guard 条件によって異なる返り値の型 推薦図書 静的型付き言語を使うことで解消される問題もありますが、その選択肢はひとまずなしということで。 Ruby 前提になっていますが、他の言語にも言えることも多いと思います。 実体にそぐわない変数名 例えば Vehicle というクラスが定義され
コード改善 meetup #2 http://kaizen.connpass.com/event/42118/ の発表資料。 自己紹介 名前: 正徳 巧 会社: 株式会社grooves 言語: Ruby github: sinsoku twitter: @sinsoku_listy コードを改善する 3つの方法 コードを改善する3つの方法 1. コードを削る 2. コードを直す 3. 増殖を防ぐ コードを削る よくありそうな業務コード 条件分岐が多い 似たような処理が複数箇所にある コピペっぽいけど微妙に違う 既存の仕様が謎 ココロ、オレル 未使用メソッドを探す 未使用メソッドは基本的に 全削除 する。 全削除に対する不安 いつか使うかも... disabled? の対象性のため enabled? も... どこかで使っているかも... 全削除に対する不安 いつか使うかも... disab
はじめに 先日、社内で「良いコードの書き方やお作法、プログラミングの原則って、どうやったら身に付くんだろうねえ？」という話になりました。 もちろん、「本を読んで勉強する」っていのも勉強法のひとつなんですが、そもそも、もっと強烈なモチベーションがないと、必死になって良いコードの書き方やプログラミングの原則って勉強できないのでは？なんて思ったりします。 強烈なモチベーションというのは、たとえば、 いったい何なん！？このスパゲティコードは！！！ なんでこんなコードを俺がメンテしなきゃあかんの！！？？ あ～、もう最悪や！！俺はこんなコード、絶対に書かへんぞ！！！！ っていうぐらいのモチベーションです。 というか、これは単純に僕のケースですね、はい。 幸い、ソニックガーデンに入ってからは、周りのプログラマがみんなちゃんとしているので、そんな思いをすることはほぼなくなりましたが、前職、前々職ではそんな
まえがき 今回書く内容は、ある程度経験あるエンジニアでも、陥りがちなものに絞って書いてみたつもりですので、[重複コードは書かない]などの超あたりまえの事は書いていません。 2017/03/16 最近よく見られてそうなので１つ追記[そもそも継承するな!!!] そもそも継承するな!!! 継承するのは、どうしようもない場合のみにしてください。 その前に、strategyパターンや、compositeパターンなどの他のやり方を考慮してもなお、継承するのが妥当である場合のみにしてください。 基本的に継承しないほうが、スケーラブルだし、テストコードも容易にかけます。 継承はis-a関係 「あー、継承ね。はいはい」で飛ばしてんじゃねーよ。 いやマジで!!! ほぼ全てのエンジニアは[is-a]が何か知っています。 というのも全てのオブジェクト思考の書籍には出てくる概念だからです。 しかし、私の経験上この概
イントロ 例外処理を書くことはよくやっているのだけれど、その時の主軸となる考え方について、今までなんとなくで行っていた部分が多かった。 毎回考えるポイントは例えば以下のような疑問。 どこのレイヤーで、どこまで例外処理を行えばよいのだろうか？ どの例外をキャッチし、どの例外を伝搬させればよいだろうか？ 前提条件をチェックし、失敗した場合、例外を出したほうがよいか、nil, false を返すほうがよいか？ 例外をどういう単位でラップさせるのが良いだろうか？ 例外をチェインし過ぎると却って煩雑になる気がする。どうすれば良いのだろうか。 しかし、この辺りの話って、API の設計だったり、仕様の影響もあるので、都度対応が異なってしまうもの。 したがって抽象化して理解することが難しく感じた。 とてもよく使ってるし、とても大事な事なことなのに。 そんな今更な事で悩んでいた時に、Effective Ja
前回投稿した「 The Wisdom of Programming （プログラミングに関する名言の知恵）」で、表面上は良さそうでも、ソフトウェアの開発において誤った考えを助長する結果になってしまう名言に注意を促しました。また、以前には「 favorite programming quotes 」（お気に入りのプログラミングの名言）というのも投稿していますが、もう少し名言を追加しておきたいと思います。 コーディング作業 「プログラムを詳細にわたって明確に記述する作業とプログラミングの作業は、全く同一のものである」―Kevlin Henney 「プログラム構築の本質のほとんどは、実際には仕様書のデバッグだ」―Fred Brooks 「よくある誤った考えは、プログラムの作成者は不可解なコードを書いてもコメント行で自分の考えを明確に表現できるだろうと思い込むことである」―Kevlin Henney
プログラマ35歳限界説！？プログラマ35歳限界説には2つの解釈がある。 1つ目は、IT業界自体が人間の能力には何も期待しておらず、単なる体力勝負であるから、体力が落ちてきて無駄に給与が高くなった35歳で廃用という意味。 2つ目は、本当に頭が働くのは35歳までで、そこを過ぎたあとは、真の知能職であるプログラマをすることは難しいという意味。私が興味あるのはこちら。そして本記事のスコープもこちら。 数学の世界では30歳で限界数学の世界では20台のうちに大きな成果を出さないと終わりだと言われる。人間にとって究極の知能職だからだろう。囲碁や将棋では、本当にトップレベルの実力が出せるのはやはりせいぜい35歳くらいまでで、それからは徐々に落ち目になる。 しかし囲碁将棋の世界では歳老いて強い人がいる囲碁や将棋のプロを見ているとしかし、40を過ぎてからも50になってからも強い人が時々いる。羽生善治の著書をい
codicは、プログラマーのためのネーミング辞書です。新しいcodicでは、翻訳エンジンを搭載しネーミングをジェネレートできるようになりました。
一時期はメソッド名は動詞で始まらなければならないと言われていましたが、昨今ではJava標準APIでも動詞ではないメソッド名が散見されます。本エントリではその傾向をまとめます。 of, from（from, of, valueOf, fromString, fromNullable etc.） fromやofはEffective Javaでも触れられているように、ファクトリメソッドとして利用されることが多いようです。例えばJAX-RSでは valueOf(), fromString() といった名前のファクトリメソッドを利用します。 EnumSet.of Integer.valueOf to, as（toList, asList, toArray etc.） 主に自分自身を別の形に変換するインスタンスを返すメソッドに使います。 IntStream.toArray Arrays.asList
(注記：7/15、いただいた翻訳フィードバックを元に記事を修正いたしました。) 子供の頃、私の興味は互いに関係性のない様々な分野に及んでいました。数学も歴史も大好きでした。 ルネッサンスマン 、つまり 博学者 と言う、複数の分野に秀でた人になりたいと思っていました。これはとても難しい課題で、私は突如として、器用貧乏な人になってしまう危機に直面したのです。 私は特定の分野に特化しなくては、と考え始めました。そうすればたとえルネッサンスマンにはなれなくても、少なくとも、器用貧乏にならなくても済むと思ったのです。どうしたらソフトウェア開発をするのに必要な広い知識を保ちながら、1つの分野で専門性を高めることができるのでしょうか。 この記事では、過去5年間、私が良いJavaScript開発者になるために使ったテクニックとリソースの概要をお伝えしようと思います。 最近の多くのWeb開発者は、ある共通の
kenjiskywalker [1:15 PM] @hisaichi5518: でかいソフトウェアのコードリーディングする時のコツ何かある？ hisaichi5518 [1:17 PM] メソッドの見つけ方覚える 手帳に図を描く くらい kenjiskywalker [1:17 PM] 手帳か〜 hisaichi5518 [1:17 PM] 手帳に図を描くのあんまやらないけどw kenjiskywalker [1:17 PM] メモどうしてんの？ hisaichi5518 [1:17 PM] してません！ kenjiskywalker [1:17 PM] 脳内スタック？ hisaichi5518 [1:18 PM] そう だからすぐ忘れて読み直す kenjiskywalker [1:18 PM] 反復派じゃん hisaichi5518 [1:18 PM] 今日もまたデバイス読んでる ken
Encapsulation with Package in Java 現在 Android を開発していて、色々なプロジェクトをみていると設計が考えられてない物が多く、「糞コード」と発狂することが度々あります。 しかし、なぜ「糞コード」だと論理的に説明する事は、なかなか難しいものです。 「糞コード」が生まれてしまう理由の一点としては、Web の便利な MVC フレームワークに慣れすぎてしまい、もっとベースにある__ソフトウェア設計__という根幹部分を忘れてしまったか、または考えられてない事ではないでしょうか。 そんな大人の階段を登り切った僕が、もう一度設計とは何かを考えなおし、これは「糞コード」だよと言うために、オブジェクト思考の重要で基本的な要素であるカプセル化とパッケージを軸とした考えをまとめたので共有します。 参考にした Web サイトも是非見てください。 Encapsulation
Djangoの主たる貢献者、ジェイコブ・カプラン＝モスは偉大な人物だ。だが、本人は自分自身を「英雄的プログラマー」ではないとしている。 PyConの基調講演で彼が語ったように、スーパープログラマーか、弱小開発者か、という二分法は全くの間違いだ。 しかも、それは害悪ですらある。開発者を「一流」か「三流」かで判断しては、その中間の存在を無視することになると彼も述べている。その結果、優秀な開発者は長時間にわたって酷使させられ、一方では劣等プログラマーには仕事が与えられず、業界でのキャリアを積めないという状況はよく起きている。どちらも好ましいことではない。 人はみな並の人間だ世間の評判通り、カプラン=モスをDjangoの発案者、あるいは共同開発者とするのは、実は適切ではないかもしれない。しかし、多くの人は彼を素晴らしいプログラマーと評し続けるだろう。 実際には違う。少なくとも、彼自身の基準ではそう
Jacob Kaplan-MossのPyCon 2015における基調講演: プログラミングの才能という都市伝説
Keynote - Jacob Kaplan-Moss - Pycon 2015 - YouTube The programming talent myth [LWN.net] PyCon 2015で、Djangoの貢献者であるJacob Kaplan-Mossが興味深い基調講演をしているので紹介する。LWM.netでほぼ全面書き起こしに近いまとめがあったので助かった。 自己紹介 Kaplan-MossはDjangoの貢献者であり、Herokuのセキュリテイ部門の部長である。PyCon参加者としては歴史が長く、その他のカンファレンスでもよく発表している。Pythonコミュニティは「自分にとってこの業界におけるとても重要なもの」であり、PyConの基調講演を行うということは、「自分のキャリア上の絶頂」である。 自分の最初のPyConの発表は2005年のことで、PythonとAppleScri
Last Updated on: 2019年2月12日キュアプログラミング（防御的プログラミング）の歴史をざっと振り返ってみたいと思います。セキュアプログラミングは防御的プログラミングとも言われるプログラミングの原則の１つ※です。古くからある概念ですが、誤解または理解されていない概念の１つではないでしょうか？ ※ Defensive Programmingとして記載されています。 何故、一般に広く常識として理解されていないのか？その理由は防御的プログラミングの歴史にあるのかも知れません。 参考： セキュアプログラミングの７つ習慣 「出力対策だけのセキュリティ設計」が誤りである理由 セキュアプログラミングの必要性が認識された事件 コンピュータセキュリティの基礎的概念は60年代から研究されていました。その成果も踏まえ、インターネットの前身であるARPANETは1969年から稼働を開始しました。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
