君、プログラミング早いね / You write a program fast - Speaker Deckプログラミングを早くするために、という LT です プログラミングを早くするために何をすべきか、ステップアップ方式で解説しています。 HP: https://nrslib.com twitter: https://twitter.com/nrslib
Perl を書き続ける理由と大事にしたいこと | #interest_ae
私がプログラミングをするときの第一言語は Perl です。周囲には「私は Perl 以外のプログラミング言語はよくわかりません」と念を押すくらいには Perl ばかり書いています。 しかし、2018年の今日 Perl は一定の役割を終えた古い言語とみなされ、メインストリームからは退いたと多くの人が考えています。10年前の2008年を思い返しても、複数の対抗言語の登場で Perl に陰りがあった事は事実ですし、今日のメインストリームに Perl が居ないことを改めて言う必要も無いでしょう。 それでもなぜ私は Perl を書き続けるのか、少し考えてみました。 私と Perl 私と Perl との本格的な出会いの場は、大学院を卒業した2003年に入社したIT企業です。その会社がメインで使用していたプログラミング言語が Perl だったので自然と Perl を書くようになりました。 2003年3月
ガード節を用いた if-then-else 文の置き換え : 小野和俊のブログ
昨日 if-then-else 文の順序に関するエントリを書いたところ、いくつか「レアケースは先に切って return する」というブクマコメントがあり、確かにこの点も考慮すべき重要な点なので前のエントリの補完的な意味も含めてエントリを書く。 if (よくあるケース/正常なケース) { // 処理 } else if (比較的特殊なケース) { // 処理 } else if (さらに特殊なケース) { // 処理 } else { // 処理 } しかしもしこれがメソッド/関数で、次のように後続の処理がないものだった場合を考えてみる(後続の処理がある場合には先のエントリに書いた検討を行う)。 public void method() { if (よくあるケース/正常なケース) { // 通常の処理 } else if (特殊なケース1) { // 特殊な処理1 } else if (特殊
「プログラミングの常識」を時々見直す必要性について｜Rui Ueyama
自分の中のプログラミングの常識というものは、ときどき現実のハードウェアに合わせて調節しないといけない。ハードウェアが進歩し続けているので、コンピュータで簡単にできることと相対的に難しいことのバランスが変化し続けているからだ。ここでは特にストレージにフォーカスして書こうと思う。 昔はメモリが相対的にとても貴重な資源だったので多くのプログラマがメモリを節約することに血道を上げていた。例えばWindowsの初期の頃に設計されたデータ構造には、メモリをバイト単位ででもいいから節約したいという意図の痕跡がいまでも多く見受けられる。DRAMの次に速い記憶装置はHDDだったので、メモリが足りなくなればHDDにデータを保存せざるを得ないのだが、DRAMとHDDのランダムアクセスの速度差は、机の上の本の開いているページを見るのと、その本をAmazonで注文して到着するのを待つのと同じくらいのスケールで違うの
入社からの半年間でコードレビューで指摘されたことのまとめ - 30歳からのプログラミング
実務未経験でプログラマとして入社して半年以上が経った。 コードレビューで指摘されたことを備忘録としてまとめておく。 自分なりにまとめたものなので、レビュアーが言いたかったこととニュアンスや解釈がずれている可能性はある。 初歩的な内容ばかりで我ながらうんざりする。 せっかく優秀な同僚ばかりなのだからもっと高度なことを学びたいが、こういう初歩的なことが出来ないのが俺の現状なのだから、仕方ない。 そもそもPullRequestを送ったこともなかったわけだし。入社初日は、一人でPullRequestの出し方を練習していた。 それを考えればまあ、こんなものだろうか。 当たり前のことをちゃんと当たり前に出来るようになって、早く、次のステージに進みたい。 PullRequest(PR) PRのタイトルは分かりやすいものに。必要に応じてチケットの番号なども入れる。 コミットやPRは出来るだけ粒度を細かくす
個人開発のやっていき方
2017年7月20日に行われた Rails Developers Meetup #3 の発表資料です。
新人プログラマ応援とは？開発に役立つ使い方、トレンド記事やtips - Qiita
新人プログラマ応援に関する情報が集まっています。現在4256件の記事があります。また5569人のユーザーが新人プログラマ応援タグをフォローしています。
海外エンジニアが話題にしていて「なるほど」と思ったプログラミングに関する考え方３つ - ジンジャー研究室
プログラミングに関する格言みたいなのは昔から結構あって、例えばYAGNIみたいに日本でも十分浸透してるのは多いんだけど、やっぱり新しい概念はどんどん生まれていくので追いかけていると面白い。 というわけで、最近知った中でもっと日本でも言及されても良いと思ったやつを３つ紹介。 Simple Made Easy Rich Hickey（Clojure言語の作者）による講演(2011年)のタイトル。全文はここで読める。英語しんどくてPOSTDに投げたんだけど音沙汰がない。まだ全部見てないから和訳欲しい。 内容としては、みんな安易に「簡単」なものを選びがちだけど「シンプル」なものの方が価値あるぜ、というもの。曰く、「シンプル」は絶対的・客観的な指標だけど「簡単」は相対的・主観的なもの。例えば英語の話者にとってドイツ語は難しいが、それは自分にとって「遠い」存在であるだけで悪いものじゃない。 「慣れてい
How To Become A Hacker: Japanese
なぜこんな文書を書いたか わたしは Jargon Fileの編集者で、またその他似たような有名文書いくつかの著者なので、しばしば熱心なネットワーク初心者から「ウィザード級の大ハッカーになるにはどうやって勉強すればいいの？」といったようなお尋ねメールを頂きます。でもかつて 1996 年に、こんな大事な問題を扱った FAQ や Web 文書 はみあたらないことに気がつきました。というわけで、これを書き始めました。多くのハッカーがいまやこれを決定版と見なしているし、つまり実際に決定版なんだと思います。でも、この問題について自分が唯一無二の権威だと主張するつもりもありません。気にくわなければ、自分なりのヤツをどうぞ。 この文書をオフラインで読んでいるなら、最新版は次のところにあります。 http://www.catb.org/~esr/faqs/hacker-howto.html なお、この文書の
毎日コードを書くこと - snowlongの日記
ワザノバで紹介されていたKhan AcademyのJohn Resigが投稿した Write Code Every Dayの翻訳です。 訳がおかしいなどの指摘をいただけると大変助かります。 去年の秋、自分のプロジェクトのコーディングを始めたんだけど、あまり進捗がよくなくてKhan Academyの仕事の効率を犠牲にすることなしに作業をすすめる方法を見つけらずにいた。 自分のプロジェクトへの取り組み方にはいくつかの問題を抱えていた。 私は週末にプロジェクトに取り組むことを優先し、平日の夜は時々といった具合だった。 自分にとってはその戦略は効果的ではなかったことが今ではわかっている。 週末の間も仕事と同じくらいの高いクオリティでプロジェクトに取り掛かり完成させるという作業は信じられないほどのストレスだった。（そして、うまく行かなかったら失敗したような気分だった。） 週末にいつも予定が空いている
エンジニア必見！本当に参考になるおすすめの企業ブログ20選
今回はエンジニアの方に本当におすすめの企業ブログを紹介します。プログラミング、チーム開発、業務効率化などの実践的なTipsが豊富なブログを厳選してみました。エンジニアがワクワクするようなコンテンツがたくさん掲載されています！ クックパッド開発者ブログ URL：http://techlife.cookpad.com/ RSS：http://techlife.cookpad.com/feed/ クックパッド株式会社が運営するブログです。Webエンジニア、アプリエンジニア、インフラエンジニアなどすべてのエンジニアに見て欲しいブログです。 はてなデベロッパーブログ URL：http://developer.hatenastaff.com/ RSS：http://d.hatena.ne.jp/hatenatech/rss 株式会社はてなが運営するブログです。エンジニアとしての働き方やはてなの最先端の
新人プログラマに正月休み中を使って読んでみてほしい技術書をセレクトしてみた。 - Qiita
エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 はじめに 今年、書いた幾つかの記事のタネ本であったり、新卒教育の際に参考書籍としてあげたものを中心にリストアップします。一応amazonへのリンクも貼っておきますが、先輩が持ってたりすると思うので、冬休みに借りて一気に読んでおくのもいいかと思います。 その時々、必要な技術の習得に日々追われているんじゃないかと思いますが、いつまでも使
bool型変数名、プロパティ名の命名規則
bool型でよく使われる命名規則にis（～か）、can（～できるか）、has（～をもつか）から始めるというものがあります。
なぜひどいコードを書いてはいけないか - hitode909の日記
ひどいコードは何やってるか分からない ひどいコードが何やってるか分かっても、なぜそうなってるのか、そこを変えるとどうなるか分からない ひどいコードは新たな変更に耐えられず書き直されることになる ひどいコードを書き直すには、ひどいコードがどうなっているか理解し、どこを変えるとどうなるのか理解する必要がある ひどいコードはたいていひどいテストコードが支えていて、テストコードがあったとしてもひどいコードと同様の問題があり、頼れるものが何もない どんなにひどいコードでも、書いた人を憎んではいけない。たとえ自分の書いたコードだとしても、先輩の書いたコードだとしても、ソフトウェアとしてひどい物にはひどいと言っていくことが大切で、だからと言って人に向かってひどいと言ってるわけではない。 最高の仲間たちが日々変化する難しい問題に対処していいコードを書いたり、ときにはひどいコードを書いている、という😇的な
プログラミング一般 DRY原則 YAGNI KISS原則 OAOO UNIX思想 可逆性 曳光弾 直交性 契約による設計 DbC プログラマの三大美徳 PIEの原則 SLAP パフォーマンスチューニングの格言 驚き最小の原則 ボーイスカウトの規則 One Fact in One Place DTSTTCPW 割れた窓の法則 名前可逆性 オブジェクト指向プログラミング デメテルの法則 パルナスの規則 求めるな、命じよ コマンドとクエリ分離原則 オペランドの原則 用語 抽象データ型 サブタイプ ダックタイピン
プログラミング原則一覧 - Strategic Choice (via jun26)
プログラミング出来ない奴ちょっと来い
プログラミング出来る方法教える。 世の中「プログラミング言語」を説く本はごまんとあれど「プログラミング」を説く本やブログはあまりない。 いや実際に "ない" というのはかなり語弊があるかもしれない。 しかし、通常この種の説明している本に辿り着くまでには多くの時間が必要だ。 普通の人は、多くの間違った方法を試し、その都度試行錯誤を重ね、プログラミング経験を経ることよって、重要な概念を獲得するのだと思う。 例えば、「計算機プログラムの構造と解釈」や「実用 Common Lisp」、「コンピュータプログラミングの概念・技法・モデル」などの書籍は現実の問題に対し "プログラム" をどう書くかという問題に正面から取り組んでいる良書だ。 しかし、どれだけ”普通の”プログラマが上記のような書籍を読んでいるのだろうか。 そして、"普通のプログラマ" がプログラミングを学ぶ書籍として、それらは果たして適切と
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Ruby未経験だった僕がドヤ顔で偉そうなことを言えるようになるまでの3年間 / #hmrk01
GitHub - everyleaf/el-training: 株式会社万葉の新入社員教育用カリキュラム
優秀なプログラマーになるためのコツ
IT業界・エンジニアの転職ならTech Stars Agent
