タグ

プログラミングに関するikd9684のブックマーク (174)

  • 練習問題 - プログラミングスレまとめ in VIP

    これは何? † 練習問題(アルゴリズム編)もご覧ください。 練習問題を集めてみました。 言語は問いません。入力出力は特に問いません。 キー入力でもファイルでもソースにべた書きでもいいです。 答えは誰かが書いてくれます。それまではスレで聞いてください。 ↑ ループ練習 † Hello World![改行]を5回表示させてください。 print(或いはprintf,cout等)を5回コピーすれば当然可能ですが、 ループ構文(for,while等)を利用して、print等は1回の使用にとどめてみてください。 出力結果 Hello World! Hello World! Hello World! Hello World! Hello World! 解答例 Java版 C Python Haskell Scala Scheme 可能ならコマンドラインから入力を受け取って、n回表示するように改造してく

    ikd9684
    ikd9684 2015/06/14
  • コードレビューのベストプラクティス | POSTD

    Wiredrive では、私たちはかなりの数のコードレビューを行います。しかし、ここで働き始める前には私はコードレビューなどしたことがありませんでした。今回は、私がコードレビューをする時に何に注目するようにしているかや、私の考え出したベストなコードレビューのやり方をお話したいと思います。 コードレビューとは、簡単に言うと2人以上の開発者で問題を引き起こしそうなコードの修正について話し合うことです。コードレビューをすることのメリットについては多くの記事で語られており、知識を共有できること、コードのクオリティが上がること、開発者が成長できることなどが挙げられています。しかし、レビューを行う上で、どのように進めていくかという具体的なことについてはあまり多く語られてないように私は思いました。 レビューで何に注目するか アーキテクチャ/デザイン 単一責任原則 : 1つのクラスは変更する理由が2つ以上

    コードレビューのベストプラクティス | POSTD
  • オブジェクト指向プログラミングデザインルール : 一生涯プログラマ

    2014年04月01日00:00 カテゴリProgramming オブジェクト指向プログラミングデザインルール プロのプログラマとはただ仕様通りに動くプログラムを作ればいいという物ではない。 保守性や拡張性を考慮し、変更に強くバグの混在しにくいプログラムを効率よく作る必要がある。 その為に、プログラミングする上で心に留めておかなくてはならない事がある。 今回はその中でも、オブジェクト指向言語においてプログラミングする際に私が意識している事を書き留めたい。 デメテルの法則 オブジェクト間の依存度を最小限にする為に任意のオブジェクトが参照出来る範囲を下記の4つに制限する。(メソッドチェーンを許容しない) 但し、メソッドの戻り値が呼び出し元インスタンスと同じクラスの場合はメソッドチェーンを許容する。任意のオブジェクト自身メソッドの引数に渡されたオブジェクトメソッドの内部で新たにインスタンス化され

    オブジェクト指向プログラミングデザインルール : 一生涯プログラマ
  • 1時間以内に解けなければプログラマ失格となってしまう5つの問題が話題に | ソフトアンテナ

    プログラマの素養を確認するための簡単な問題として有名な「FizzBuz」問題。ただしこれだけ有名になってしまうと、プログラムの能力を試験するための新たな問題が必要とされているかもしれません。 経験豊富なソフトウェア開発者、Santiago L. Valdarrama氏が、「ソフトウェアエンジニアならば1時間以内に解けなければいけない5つの問題」を出題し、Redditなどで話題となっています。 その5つの問題は以下の通りです。 問題1 forループ、whileループ、および再帰を使用して、リスト内の数字の合計を計算する3つの関数を記述せよ。 問題2 交互に要素を取ることで、2つのリストを結合する関数を記述せよ。例えば [a, b, c]と[1, 2, 3]という2つのリストを与えると、関数は [a, 1, b, 2, c, 3]を返す。 問題3 最初の100個のフィボナッチ数のリストを計算す

    1時間以内に解けなければプログラマ失格となってしまう5つの問題が話題に | ソフトアンテナ
  • プログラミングとかウェブでよく出てくる小難しい英単語30選 - Dance with Tech

    よくプログラマーエンジニア)は、 数学が得意な人じゃないと出来ないとか言われたりしますが、 個人的には数学というより、 英語が出来る(好きな)人の方が有利だと思っています。 だってプログラミングってコメント以外英語ですし。 「なでしこ」とかはありますけどw 僕は学生時代、どちらかと言うと数学が苦手なタイプでしたが、 英語はわりと出来る方でした(というか好きだった)。 もちろん、数学も出来た方が有利に決まっていますが、 普通にご飯をべていく分にはそんなに必要無いと思います。 ということで、 英語の意味を理解すると、仕事が更に捗るんじゃないかと思いまして、 プログラミングとかウェブで出てくるけど、 ちょっと意味が分かりづらい英単語30個をまとめてみました! プログラミングで出てくる英単語30選 英単語読み方意味 allocate アロケート 割り当てる attr(attribute) アト

    プログラミングとかウェブでよく出てくる小難しい英単語30選 - Dance with Tech
    ikd9684
    ikd9684 2015/04/22
    これ、意味よりもカナが有益。
  • ダメなコードを改造しなくてはいけなくなったときは、ダメさを片っ端から潰していくしかない

    仕事としてプログラミングをしていると、ときどき、どう見てもダメなコードを扱わないといけないことがある。そういうコードでも動いている以上はそれなりの価値を提供しているわけだけど、ときどき触るのすら嫌悪感を感じるようなものがある。 なぜ嫌悪感を感じるのかといえば、自分で最低限だと思っている想定すら守られていないからだ。常識の通じない人たちの書いたコードには身の毛もよだつような何かがある。 コーディングスタイルが統一されていない インデントが狂っている 到達不能なデッドコードがたくさんある 無意味なコメントやコメントアウトされたコードがある コメントの文章が文章としておかしい コピペの繰り返しがたくさんある ネストが恐ろしく深い 関数が絶望的に長い 無意味に複雑 こういったコードを触らなくてはいけなくなったとき、そのままで編集するのはかなり難しい。コードの内容以前に、不自然な部分でいちいち引っか

    ikd9684
    ikd9684 2015/03/30
    「コメントの文章が文章としておかしい」全てはこれだと思うんだよね。自分のやろうとしてることを正しく言葉にできない奴が正しいコードなんて書けるはずない。コードを和訳しただけのコメント書く奴は総じて無能。
  • 精度95%以上! ソースコードは指紋、作者はほぼ特定できる

    精度95%以上! ソースコードは指紋、作者はほぼ特定できる2015.02.11 19:0010,327 ほぼドンピシャでバレバレです。 スペースやタブ、大文字やアンダーバーを組み合わせた命名規則、コメント…コードの書き方には、人によってスタイルがありますよね。それはもう指紋のようなもので、それさえ見えれば、誰がコードを書いたかほとんどわかってしまう…そんな驚きの研究結果が発表されました。 米ドレクセル大学、メリーランド大学、プリンストン大学、独ゲッティンゲン大学の共同チームの研究によると、自然言語処理と機械学習によるコード分析により、95%の精度で作者は特定できるそうです。 解析されるのは、レイアウトや語彙の特性と、「抽象構文木(AST)」です。ASTとは、「コードの書き方からまったく影響を受けずに、コードの型の特性をとらえる」もので、つまり、関数の名前、コメント、スペース入れ方などのクセ

    精度95%以上! ソースコードは指紋、作者はほぼ特定できる
  • データ構造と メソッドのネーミング - codic ブログ

    データ構造など技術的な背景をちゃんと知っていれば、データ操作に関する正しい英語を使えるねーて話です。用語のイメージもつかめるようにしていますので、shift / unshift とかイメージできない方もどうぞ。 1. push / pop = スタック push pop は、スタックの用語で、それぞれ pop はスタックから取り出す、push は挿入する事を意味します。JavaScriptRuby の Array には、スタックとしてのコンセプトもあるので、push / popという用語が使われます。 対して、Javaの ArrayList (インターフェースは Collection) は、単なる集合を表すインターフェースなので、抽象化のために add / remove というネーミングが使われます。そういえば、Javaには、Stackというクラスも別途用意されていますね。Stack

    データ構造と メソッドのネーミング - codic ブログ
  • プログラマが知るべき97のこと

    プログラマが知るべき97のこと大人気の書籍『プログラマが知るべき97のこと』のエッセイを無料で公開中!すべてのプログラマにおすすめのがウェブで読めるようになりました。 エッセイ一覧分別のある行動関数型プログラミングを学ぶことの重要性ユーザが何をするかを観察する(あなたはユーザではない)コーディング規約を自動化する美はシンプルさに宿るリファクタリングの際に注意すべきこと共有は慎重にボーイスカウト・ルール他人よりまず自分を疑うツールの選択は慎重にドメインの言葉を使ったコードコードは設計であるコードレイアウトの重要性コードレビューコードの論理的検証コメントについてのコメントコードに書けないことのみをコメントにする学び続ける姿勢誰にとっての「利便性」かすばやくデプロイ、こまめにデプロイ技術的例外とビジネス例外を明確に区別する1万時間の訓練ドメイン特化言語変更を恐れない見られて恥ず

    プログラマが知るべき97のこと
  • 毎日が天皇誕生日になるには何回天皇が交代する必要があるか(シミュレーション版) - 唯物是真 @Scaled_Wurm

    今日は天皇誕生日ですが、以前「あと何回天皇が交代すれば毎日が天皇誕生日になるか(不謹慎)」の期待値を求める記事を書きました 毎日が天皇誕生日になるには何回天皇が交代する必要があるか - 唯物是真 @Scaled_Wurm 祝日と祝日の間に挟まれた日が、国民の休日で休みになるのを考慮していないという指摘を受けたので、今回はその場合の平均回数を求めます さらに、挟まれた日が国民の休日になるというのを考えると、もっとずっと複雑になるな。(考える気はない)http://t.co/AuibRNF969— Hiroshi Manabe (@takeda25) 2014, 4月 30 厳密解をどうやって求めればよいか悩んでいたら「厳密解は諦めてシミュレーションでそれっぽい値を求めればよいのでは?」というアイディアをいただきました。ありがとうございます@Scaled_Wurm ああ、ここでシミュレータと言

    毎日が天皇誕生日になるには何回天皇が交代する必要があるか(シミュレーション版) - 唯物是真 @Scaled_Wurm
    ikd9684
    ikd9684 2014/12/23
    こけのむすまで。
  • 作りたいものを作るには結局大量のコードを書かないといけないことについて - Qiita

    Register as a new user and use Qiita more conveniently You get articles that match your needsYou can efficiently read back useful informationYou can use dark themeWhat you can do with signing up

    作りたいものを作るには結局大量のコードを書かないといけないことについて - Qiita
  • 視覚化による5つのガベージコレクションアルゴリズム入門 | POSTD

    ほとんどの開発者は、自動のガベージコレクション(GC)を当たり前のように使っています。これは、私たちの仕事を容易にするために言語ランタイムが提供する素晴らしい機能の1つです。 しかし、最新のガベージコレクタの中をのぞいてみれば、実際の仕組みは非常に理解しづらいことが分かります。実装の詳細が無数にあるため、それが何をしようとしているのか、また、それがとんでもなく間違った事態を引き起こしかねないことについて十分理解していない限り、すっかり混乱してしまうでしょう。 そこで、5種類のガベージコレクションアルゴリズムを持つおもちゃを作ってみました。小さいアニメーションはランタイムの動作から作成しました。もっと大きいアニメーションとそれを作成するコードは github.com/kenfox/gc-viz で見ることができます。単純なアニメーションによってこうした重要なアルゴリズムを明らかにできることは

    視覚化による5つのガベージコレクションアルゴリズム入門 | POSTD
  • 「オブジェクト指向の価値ってよく分からないですよね」について - manie's blog

    そういえばCORBAとかROSEとかUMLとかやってた気がします。 プログラミング勉強中の人にオブジェクト指向とは何なのかを何となく伝えたい話 - かまずにまるのみ。 「オブジェクト指向の価値ってよく分からないですよね。」 誕生の歴史を知ればよい。環境によっては価値がある。 コンピュータは情報数学と電子回路から誕生した。電子回路は半導体によってハードウェアからソフトウェアとなり、機械語(そしてアセンブリ言語)が必要になった。C言語はアセンブリ言語に配列と構造体を加えたものだ。手続型言語ではデータ構造とアルゴリズムを同時に設計するが別々の保守が必要だった。保守は同時にやるべきだ。データ構造とアルゴリズムを同時に同じ場所で実装し保守出来る仕組みがクラスだ。 情報数学と電子回路 情報数学は乱暴に言えばビット演算学だ。NOTとORとANDを使ってあらゆる命題論理を電子回路で置き換え可能な式に書き下

    「オブジェクト指向の価値ってよく分からないですよね」について - manie's blog
  • 「for やめろ」またはイベントループと nextTick() - Block Rockin’ Codes

    ものすごく遅レスですが、LLDiver で @esehara さんの LT であった話。 forやめろ、あるいは「繰り返し」という呪縛から逃れるために 簡単に言うと、 1~10 までを出力する方法を複数考えるというもの。 for, while, 再帰, goto etc.. と出て、途中で終わっちゃったので結論はよくわかりませんでしたが、 Node ではどれも使わずにできるな、と思ったのでちょっと例を出してみます。 ちなみに、タイトルでネタバレしている通りイベントループの話です。 そしてよくある「イベントループとは何か」「なぜ止めてはいけないのか」「process.nextTick() とは何か」「setImmediate() と何が違うのか」 などを解説する良い例だったので、書いてるうちに実はそっちがメインの解説となりました。 サンプルの実行結果は Node v0.11.13 です。(書

    「for やめろ」またはイベントループと nextTick() - Block Rockin’ Codes
  • クラスの命名のアンチパターン - Qiita

    昔から「名は体を表す」と言ひます。クラスの名前がクラスの果たす役割と一致してゐるかどうか常に考へ続けませう。 ImageInfo, AccountData, etc. Info って何やねん? Data って何やねん? ImageInfo って Image とはどう違ふねん?? FooInfo や FooData よりも好ましいかもしれない名前の例: FooAttribute, FooProperty, FooMetadata, FooDescription FooConfiguration, FooSetting, FooParameter FooResult, FooStatistics, FooSummary FooBuffer, FooList, FooCollection, ... ProductListItem, TranslationTableEntry, etc. Prod

    クラスの命名のアンチパターン - Qiita
  • プログラミング万能練習法

    暇な人はやってみるといいプログラミングの万能練習法 は良いトレーニングになる。 プログラムを自ら書きたいと思う人って、与えられたメニューをこなすだけの人間ではないと思うけどハッカーを目指している人には UNIX の勉強にもなるんじゃないだろうか。というわけで、実際の練習メニューは以下の通り。 プログラミング言語を選択する 書いてみようと思う POSIX のコマンド を決める man をはじめとするマニュアルを読んでコマンドの仕様を理解する 設計する(初回のコーディングと同時進行はやめたほうがいいかも) コーディング テストする。設計とコーディングの反復。 終了 C 言語で書いたならテストのあとにオリジナルのソースを読んで答え合わせするのですが、必ずしもオリジナルのコードが正解とは言い切れない。 自分が書いたプログラムが仕様どおりに動いているならアルゴリズムの違いなどは気にしなくていいと思う

    プログラミング万能練習法
  • 『なぜ60%の人はプログラミングが出来ないのか』

    プログラミングが出来る人間からみると、プログラミングが出来ない人の理由は単純に「ちゃんと勉強しないからだ」ということになる。 たしかに、自分達が歩んできた過程は、SDKやIDEの設定を行ってコンピュータの開発環境を整え、全く意味不明なアルファベットを打ち込んで、ウェブサイトやで言われたとおりの表示が出ることを確認して、また次のステップをやってみて、という「地味で地道な(そして性格まで暗くなりそうな)」ことを繰り返して出来るようになったものなので、その過程から逃れているからプログラミングが出来ないんだろ、というのはごく自然に思う。 このため、プログラミングを教えようというときに、地味で地道で性格が暗くなってハゲて死にそうな学習過程の苦しみを、いかに和らげられるかという試みは数多くなされている。codecademyやRails for zombiles: code schoolなど、ゲーミフ

    『なぜ60%の人はプログラミングが出来ないのか』
  • クソコードに対する怒りとコードレビューにおける人格攻撃について | おそらくはそれさえも平凡な日々

    デキるプログラマだけが知っているコードレビュー7つの秘訣 7つの秘訣の1〜5は当にそのとおりだと思います。 「怒り」って言葉を使っているところはなかなか画期的だと感じた。というのも僕は前から「人格攻撃に思われて」しまうような、コードで人を殴るようなことをしてしまう人が出てきてしまうのは何故かということを考えた時に、そこには「コードに対する怒り」があるからだろうなと思っていたからである。怒りがあるからこそ強く指摘しすぎてしまうことが起こりうる。 「怒り」というのはつまり「感情」である。であれば、「その『怒り』はコードに向けられたものであり、書いた人に対してのものではないので、その人に対しての攻撃ではない」というのは、理屈ではかろうじて通るかもしれないが、書いた人の「感情」的には通らないこともあることは理解したほうが良いと思う。 じゃあ怒らなければ良い、という話にはしたくなくて、どうしても怒

    クソコードに対する怒りとコードレビューにおける人格攻撃について | おそらくはそれさえも平凡な日々
  • ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習

    最近、あまりプログラミングが得意でない人のサポートをする形で、長い時間にわたってペアプログラミングを行っている。そのなかで、気がついた悪い習慣と成長するための良い習慣というものをまとめてみる。 この記事のバックグラウンドとなる体系的知識がになりました。 エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング あわせて読みたい 経営者マインドが足りない!vs. 現場に任せてくれない!の対立をなくすカードゲームをつくった話 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 あきらめるにはまだ早い!ソースコードの品質向上に効果的なアプローチ 心理的安全性ガイドライン(あるいは権威勾配に関する一

    ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習
  • 新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 - Qiita

    あわせて読みたい 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 「オブジェクト指向プログラミング」と「関数型プログラミング」のたった一つのシンプルな違い あきらめるにはまだ早い!ソースコードの品質向上に効果的なアプローチ 2015年に備えて知っておきたいリアクティブアーキテクチャの潮流 この記事について この記事は新人向けの研修内容を再編集してお送りいたします。 ここで述べる内容はどのようにして現在のプログラミングスタイルが生まれてきたかを理解することで、よりよいプログラムを書くためのもので、正確なソフトウェア工学の歴史を学ぶためのものではありません。正確な歴史を把握したい場合は、原典をあたるようにしてください。 また、想定している読者は「よくあるオブジェクト指向プログラミングの学習」を既にし

    新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 - Qiita
    ikd9684
    ikd9684 2014/05/14
    何から何まで知って欲しいなんて、そんな期待に応えられるほど優秀な新卒を採用できるのは羨ましい限り。