プログラミング勉強を加速させる7つの習慣 - Qiita
※ 本記事は自分が運営するブログに転載しています 株式会社LITALICOでWebエンジニア（Rails）を担当しています、@YudaiTsukamotoです。 この記事は『LITALICO Advent Calendar 2016』16日目の記事です。 はじめに 私は学生時代は情報工学の専攻でもなければ、趣味でプログラミングをやっていたわけでもなく、 社会人になってWebエンジニアとして初めてまともにプログラミングを勉強し始めました。 入社するまでに独学で勉強の真似事をしてはいましたが、そもそもどうやって勉強していいのか全然わからず、 本を読んで写経をして何故だか理由はよくわからないが動作してしまうミニブログを眺めては、ため息を付いて挫折を繰り返しておりました。 そんな初心者だった自分が、Webエンジニアとして食べていくために本気で努力して身につけたノウハウを、 「プログラミング勉強を加
高校生にWeb上でプログラミングを教え始めたエンジニアがこの8ヶ月間で得た気づき - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 画像: N高等学校課外授業(N予備校)での生放送授業のブラウザ上での見た目、コメントが書ける 目次 はじめに 教えることになったきっかけ Web企業にエンジニアとして就職できるようになる、というミッション 既存のWeb教材に感じた問題意識 「各自進められるゲームブック形式の教材」と「徹底的にフォローする生放送授業」 コンセプトをもとに構成されたコースと内容 ゼロからプログラミングができるようになった人が生まれた日 永劫、プログラミングは一部の天才たちのためのものか？ プログラミング学習のモチベーションの課題と対応 まじめなオタクたちが社
技術的負債とどうやって戦うか - Qiita
プロジェクトが進行するにつれて増える『負債』 長いプロジェクトに携わっていると、技術的負債をいつ返すのかが課題になってきます。 リファクタリングはいつの時点でやるのか、これは長いプロジェクトを運用していく上で問題になっていきますが、今回は負債の種類を整理し、それぞれどう対応をしていけばよいかを考えていきたいと思います。 私達の開発では常に時間が足りない 最近読んだ、「アジャイルサムライ」という本には下記のようなことが書いてありました。 (開発における)3つの真実 プロジェクト開始時点にすべての要求をあつめることは出来ない 集めたところで要求はどれも必ずと言っていいほど変わる やるべきことはいつだって与えられた時間と資金よりも多い 以上のことからわかるように、私達の開発には時間が無いということが常だということがわかります。実際、技術的負債が多いプロジェクトほどこの傾向が強いのではないでしょう
契約による設計の紹介 - Hatena Developer Blog
こんにちは、チーフエンジニアの id:hakobe932 です。 はてなでは毎週、社内技術勉強会を開催しています。先週の勉強会では現在開催中のはてなインターン2016の参加者のみなさんもインターン生も参加して、いっしょに技術交流を行いました。 このエントリでは、そこで発表した、契約による設計の紹介をしたスライドを公開します。 契約による設計はBertrand Meyer氏によるオブジェクト指向入門*1という書籍で紹介されている考え方です。 オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング) 作者: バートランド・メイヤー,酒匂寛出版社/メーカー: 翔泳社発売日: 2007/01/10メディア: 単行本（ソフトカバー）購入: 11人 クリック: 307回この商品を含むブログ (130件) を見る 契約による設計で
「有害なgoto」「時期尚早な最適化」、そしてプログラミングにまつわる神話は諸悪の根源である | POSTD
以下のプレゼンテーションは、私がPapers We Love Madridの初会議で発表したものです。講演のテーマは、Donald Knuthの論文「Structured Programming with Go To Statements」（goto文を用いた構造化プログラミング）でした。 我々が人間として抱える最大の問題は、信念と現実を混同することである。 – Alan Kay それ（goto）を禁止するか、それとも使わない方向へ教育するかが問題だ。 – Donald Knuth この記事では、神話についてお話ししたいと思います。Googleで 神話（myth） の定義を検索してみると「広く信じられているが誤った信念や観念」とあり、dictionary.comを見ると「立証されていないか誤った共通的信念であり、社会制度を正当化するために用いられる」と説明されています。ここで問いたいのは、
Blue. No! Yellow! : プログラミング言語の進歩史と生産性にまつわる問答 | POSTD
世界初のプログラム内蔵方式コンピュータに搭載された、最初のプログラムを書くのに使われた言語は何だったでしょうか？ もちろん、バイナリの機械語です。 なぜですか？ えー、当然ながら、シンボリックアセンブラがなかったからです。最初期のプログラムは、バイナリで書かなければなりませんでした。 バイナリの機械語と比較して、アセンブリ言語でプログラムを書くと、どのくらい簡単ですか？ ずっと 簡単です。 数字を言ってください。何倍ぐらい簡単ですか？ えー、まあ、アセンブラは、あなたの代わりに面倒な事務処理を全てしてくれますからね。つまり、全ての物理アドレスの計算です。全ての物理的な命令を構築するわけです。あなたが範囲外にアドレス指定するなど、物理的に不可能なことをしないよう確認します。そして、簡単にロードできるバイナリの出力を生成します。 それによって、軽減されたワークロードは、 膨大 です。 どのくら
SyntaxDB - Programming Syntax Database
SyntaxDB lets you easily look up syntax for your favourite programming language. Now supporting Java, C, C++, C#, JavaScript, Swift, Python, Ruby, and Go.
つらくないコードレビューの運用 - Speaker Deck
All slide content and descriptions are owned by their creators.
オブジェクト指向プログラムのためのパターンランゲージの使用
以下の文章は、Kent Beck、Ward Cunninghamによる「Using Pattern Languages for Object-Oriented Programs」の日本語訳である。Ward Cunningham氏の許可を得て、ここに掲載する。 Kent Beck, Apple Computer, Inc. Ward Cunningham, Tektronix, Inc. Technical Report No. CR-87-43 September 17, 1987 Submitted to the OOPSLA-87 workshop on the Specification and Design for Object-Oriented Programming. 概要 オブジェクト指向プログラミングへのパターンランゲージの適合について概説する。ウィンドウベースのユーザーイ
プログラミングで変数名や関数名のネーミングに迷ったときに便利なカンニングペーパーまとめ
僕は、プログラムをする上で変数や関数に良い名前を付けるのはとても重要と考えています。 というのも、良い名前を付ければ、それだけでそのコードがしたいことの説明になり、コメントと同等の働きをすることもあるからです。 自分がちゃんとそれをできているのかはさておき、僕は普段から、できれば読みやすくて分かりやすい名前を付けたいと思っています。他の人も読むコードであれば、できればプログラムでよく使われるような単語を利用して書いた方がより分かりやすいです。 ただ、よい名前を考えるのって、ちょっと面倒くさいんですよね。僕はこれまで、英語の辞書を利用して、考えたりしていたのですが、「何か、プログラムでよく使われる単語をまとめたものはないか？」と探したら、ドンピシャのものがいくつかあったので、それらをまとめて以下で紹介します。 photo by Michael Coté codic codic – デベロッパ
プログラマを悩ませること Top 10 | POSTD
10. 「何か」は分かるが「なぜ」が分からないコメント プログラミング入門コースでは、早い段階かつ頻繁にコメントを記述することを生徒に教えます。プログラムを書き始めた初期段階（ごく単純なコードであっても、時に理解し難いことがあります）では、これは実際に役立つことなのですが、習慣にとらわれてしまうプログラマが多くいます。 上記のコードが何をするのか分かりますか？ 私は分かりません。 問題は、多くのコメントがそのコードが 何をする のかを説明していますが、 なぜ そのコードが書かれているかが説明されていません。では、異なるコメントが書かれた同じコードを見てみましょう。 こちらの方が分かりやすいですね。何が起きているのかを完全に理解できるとは言えませんが、最低でもなぜこのコードが必要なのかが文脈から判断することができます。 コメントは、構文を理解してもらうためにではなく、読み手がコードを理解しや
エッセイ一覧 | プログラマが知るべき97のこと
[出典] プログラマが知るべき97のこと 当サイトはオライリー・ジャパンによる公式なサイトではありません。 個々のエッセイは「CC-by-3.0-US」によってライセンスされています。
プログラマが知るべき97のこと
プログラマが知るべき97のこと大人気の書籍『プログラマが知るべき97のこと』のエッセイを無料で公開中！すべてのプログラマにおすすめの本がウェブで読めるようになりました。 エッセイ一覧分別のある行動関数型プログラミングを学ぶことの重要性ユーザが何をするかを観察する（あなたはユーザではない）コーディング規約を自動化する美はシンプルさに宿るリファクタリングの際に注意すべきこと共有は慎重にボーイスカウト・ルール他人よりまず自分を疑うツールの選択は慎重にドメインの言葉を使ったコードコードは設計であるコードレイアウトの重要性コードレビューコードの論理的検証コメントについてのコメントコードに書けないことのみをコメントにする学び続ける姿勢誰にとっての「利便性」かすばやくデプロイ、こまめにデプロイ技術的例外とビジネス例外を明確に区別する1万時間の訓練ドメイン特化言語変更を恐れない見られて恥ず
C言語プログラミングの覚え書き（改訳） - アスペ日記
原文: Notes on Programming in C Rob Pike 1989年2月21日 Copyright (C) 2003, Lucent Technologies Inc. and others. All Rights Reserved. Lucent Public License Version 1.02 前書き KernighanとPlaugerによる“The Elements of Programming Style” （「プログラム書法」木村泉訳）は重要で影響力のある本です。この本にはそれだけの価値があります。しかし、その中の簡潔なルールが、本来意図されたような哲学の簡潔な表現としてではなく、よいスタイルのレシピとして受け取られているように私は時々感じます。この本が変数名は意味を持つようにつけられるべきだと言うなら、名前が使い方を説明するちょっとしたエッセイのような
プログラマとして30年以上の経験から得た教訓 | POSTD
私は、プログラマとして30年以上仕事をしてきた中で、学んだことがあります。そのいくつかを以下にご紹介します。もっと挙げることもできますよ。 実物を見せないと、顧客の希望は分からない。 このことは最初の仕事で学びました。顧客は、実物を見るまでは、何が本当に必要なのかがよく分かりません。言葉で長々と説明するよりも、機能検証のためのプロトタイプを提示する方が確実に役立ちます。 十分な時間があれば、あらゆるセキュリティは破られる。 現代社会において、セキュリティを保つことは信じられないほどの難題となっています。プログラマは常に完璧を求められますが、ハッカーは1回でもハッキングができれば成功なのです。 セキュリティが破られた場合、事前にその状況に備えた対策を講じているかどうかで結果が変わってくる。 最終的にセキュリティが破られることを想定する場合、その時に起こることに備えて対策を立てておく必要があり
リーダブル・コードを書く | POSTD
ここ数年間をプログラミング的な観点で見ると、私が望んでいたほどには面白みがなかったと言わざるを得ません。このことは、恐らく他のプログラマの皆さんも同意見かと思います。そこで、私はこの期間をある意味、充電期間と捉えて、自分の開発ツールの強化に取り組んできました。そして土曜日になると、Bashを使って ワークスペース 作りに精を出していたのです。 最後にシェルを使って真剣にプログラミングに取り組んだのは、かれこれ恐竜がまだ地球を支配していた頃だったでしょうか。何年も触れていなかった言語を改めて取り上げ、その昔に自分が書いたコードを見直してみると、いかに自分が成長したかということを実感できて、なかなかに面白いものです。 14年前、私は”コンパクトなコードは優れている”という考えに随分と傾倒していました。コードが少なければ、そしてDon’t Repeat Yourself（DRY）に従えば、バグも
Semantic Versioning 2.0.0
english セマンティック バージョニング 2.0.0 概要 バージョン番号 MAJOR.MINOR.PATCH を前提として、 あなたが互換性のない API の変更を行うときに MAJOR バージョンを、 後方互換性のある方法で機能性を追加したときに MINOR バージョンを、 そして、後方互換性のあるバグ フィックスをしたときに PATCH バージョンを、 インクリメントします。 追加のラベルとして、プレリリースとビルド メタデータが MAJOR.MINOR.PATCH フォーマットへの拡張として利用することができます。 序論 ソフトウェア マネジメントの世界には「依存関係地獄」と呼ばれる非常に恐ろしい場所が存在します。 あなたのシステムがより大きくなるほど、あなたのソフトウェアの中へより多くのパッケージを溶け込ませるほど、いつかこの絶望の底にいるあなた自身に気づく、そんな可能性が
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
うまくメソッド名を付けるための参考情報 - Qiita
言語処理100本ノック 2015
コードレビューガイドライン #loupestudy
