builderscon2017の発表資料です。 https://builderscon.io/tokyo/2017/session/182ba13a-ccd5-4ddd-9565-c4e20df1d871
![Oss貢献超入門](https://cdn-ak-scissors.b.st-hatena.com/image/square/30f01b55c7fac24ffc638396662cd1f200b96e79/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Foss-170805064011-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
教えて、ござ先輩! なぜプログラミングに「表現力」が必須? わずか3つの表現文法でイメージをコード化する方法 自分のイメージを、ちゃんとコードとして表現することができていますか?そのために必要なのは、イメージを論理へと変換する、「表現力」です。エンジニアが身につけるべき表現力を、ござ先輩がばっちり解説します! 株式会社クオリティスタートの代表を務めている、湯本(@gothedistance)と申します。インターネットでは、「ござ先輩」という愛称でブログを書いたり、雑誌やWebメディアに記事を書かせていただいています。本業ではITコンサルタントという立ち位置で、主に業務アプリケーションの業務分析/要件定義や、エンジニア向けの新人研修の講師などの仕事をしています。 プログラミングは非常に自由なもので、同じ処理や条件を記述しているにもかかわらず、エンジニアによって書かれたコードがかなり違うことが
天才プログラマーと自分との実力差をカンタンに測定する方法を発見しましたよ、という話。 結論から言うと、いろんなところで過去に開催されたプログラミングコンテストの入賞者の結果を見て、その問題を同じ条件で解いてみること。 あるウェブサイトに2015年に開催されたプログラミング・コンテストの結果が載っていた。(本記事の末尾にそのプログラミング問題の日本語訳を載せた) 入賞者は1位の人が15分、2位が22分、3位が24分、となっていた。 プログラミングの問題をザッと眺めていたら、実装すべきアルゴリズムがパッと思いついた。「これはひょっとして1位の人は超えられなくても3位入賞ぐらいはいけそうじゃね?」などと考えてしまった。 それでそのウェブサイトが用意しているエディタを使って、コードを書きだした。 15分経過:「あれ?もう15分も経った?まー1位にはなれなくてもトップ集団には入るわ」 20分経過:「
はじめに ひとつ前のエントリでRSpecの話を書いたので、それにちなんで最近僕の身の回りで起きたテストコードに関する雑多なエピソードをいくつか書いてみます。 その1:テストコードを書いてない処理で見事にバグを出してしまった・・・!! 僕はソニックガーデンの中では「テスト番長」の異名を持っていて、基本的にテストコードはしっかり書くタイプです。 ですが、どうしてもリリースを優先しなければいけないときは、やむを得ずテストコードを後回しにして先にリリースすることもあります。 先日リリースした「テストを後回しにしたコード」は、リリース直後は問題なく動いていました。 その数週間後、別の仕様変更が入り、変更したコードをリリースしました。 「テストは全部パスしているので大丈夫なはず~!」と思ったら、リリースの翌日に変なシステムエラーが発生。 エラーが起きている場所を見て、ガーン。 例の「テストを後回しにし
まえがき 今回書く内容は、ある程度経験あるエンジニアでも、陥りがちなものに絞って書いてみたつもりですので、[重複コードは書かない]などの超あたりまえの事は書いていません。 2017/03/16 最近よく見られてそうなので1つ追記[そもそも継承するな!!!] そもそも継承するな!!! 継承するのは、どうしようもない場合のみにしてください。 その前に、strategyパターンや、compositeパターンなどの他のやり方を考慮してもなお、継承するのが妥当である場合のみにしてください。 基本的に継承しないほうが、スケーラブルだし、テストコードも容易にかけます。 継承はis-a関係 「あー、継承ね。はいはい」で飛ばしてんじゃねーよ。 いやマジで!!! ほぼ全てのエンジニアは[is-a]が何か知っています。 というのも全てのオブジェクト思考の書籍には出てくる概念だからです。 しかし、私の経験上この概
最近、自分のGitのコミットログを読み返してみたら、すごく分かりづらかったので勉強も兼ねて、Gitのコミットログのプラクティスを勉強してみました! 🐰 Gitのコミットメッセージの書き方次のサイトを参考にさせていただきつつ、簡単にまとめてみました! Gitのコミットメッセージの書き方 | プログラミング | POSTD Gitのコミットメッセージの書き方 - Qiita 書き方を知ることのメリットGitのコミットメッセージをわかりやすく残すことで、その変更どんな目的で具体的にどんなことを修正したかを 次の変更を行う人に伝えることができ、次の人の修正する時間を節約できる。 具体的にどんなことを書くべきかどのように変更を行ったかは、コードを見れば分かる。もしわからないのなら、コードにコメントを書くべき。 変更した理由を明らかにすることに焦点を絞り、変更前がどうで、何が問題で、今はどのように機
今年こそ、プログラミングをモノにしたい!ITトレンドに敏感な読者の中には、そんな決意を秘めた人も多くいるだろう。 そうは言っても、多忙な皆さんのこと。勉強時間を確保するのは、なかなか難しいのではないだろうか。 今回ご紹介するのは、忙しい人でもストレスなくコードを記録できるお手軽サイト。プログラミング学習者のための支援ツール、「Code Half」だ。 ・単語帳感覚でコードを記入 内容は、実にシンプル。1日ごとに憶えておきたいコードを、指定の日付欄に記入していくだけ。 ここでコーディングを教えてくれるとか、問題が出るとかそういうことではない。その役割はあくまで、毎日の学習習慣を維持するところにある。 使い方も簡単。Eメール、Twitter、GitHubのいずれかで登録すれば、すぐに利用できる。ログインすると即、カレンダーが表示されるので、今日の日付に記憶したいコードを書き込んでいけばいい。努
プログラムを独学で勉強している初心者です(2ヶ月くらい) ちょっとした疑問があり、質問させていただきます。 プログラムのサイトなどには、変数などの名称には英語を使うべきと書かれています。 これはなぜなのでしょうか? はっきり言って、この風習があるために勉強で困っています。 勉強のためにサンプルコードなどを見ていても、英単語が並んでいると、 どれがプログラム特有の命令で、どれがプログラム記述者が自由につけた変数名なのかが わかりにくいのです。 変数は変数であることがはっきりわかったほうが便利だと思うのです。 プログラムに慣れている人にはそんな必要ないのでしょうが… 自分でコードを書く時には、あとから自分でわからなくならないように 変数名には必ず「h_」をつけるようにしています。 h_speed とか h_count とか。 英語にするべき理由と、初心者のうちだけでも変数がわかりやすくするよう
去年Androidソースコードレビューで指摘する事が多い項目まとめという記事を書いた時はアプリ全体を一度に見るような機会が多かったため、内容も大きめのものばかり書いていましたが、最近はプルリクエスト単位でレビューする機会が増えたので細かい項目についてまとめてみようと思います。 ミリ秒で時間を指定する時に自前で計算している 1000L * 60L * 60L * 24Lのようなコード。 TimeUnitを使いましょう。 24時間の場合は以下のように書けます。 TimeUnit.DAYS.toMillis(1L) ある文字列がhttp/httpsで始まるかチェック URLUtil.isNetworkUrl()を使いましょう。 ただしequalsIgnoreCaseで判定してます。 ベースURLにパラメータを付与していってURLを生成したい StringBuilder#append("&key=
一人でプログラムを書いてたりすると、環境によってはあまりコードの書き方には指摘を受けなくて困りますよね。プロになっても、曲がりなりにもちゃんと動くコードを書けてしまうとあまりに当たり前のことなんかは指摘されることも稀で、そのままある程度偉くなっちゃった日には、もはや自分で気付くしかなくなってしまいます。 FindBugsとか、Effective Javaなら使ったり読んでみたり読ませたりすることはできますが、それ以前のところって難しいんですよね。よいコードと言うよりそれが当たり前だと思われているので、指摘するにしても「こうすればいいよ」(アドバイス)じゃなくて「なんでこうしてないの?」(詰問)になってしまいがちです。 そこで、最近そういうJavaニュービーに指摘している(したい)ことの多い、Javaの基礎的な事柄をまとめてみました。ワタシJavaチョットデキルって人は、これ以外にもやりがち
今日見つけた「はしれ!コード学園」ってマンガをご存知でしょうか? たま〜に「Google Adsense」かなんかの広告に表示されてます。 はしれ!コード学園 現在第3回まであるようですが、IT業界の人はなんか笑えるんじゃないでしょうか。 https://codeiq.jp/magazine/2015/10/30057/codeiq.jp https://codeiq.jp/magazine/2015/10/31456/codeiq.jp https://codeiq.jp/magazine/2015/11/33256/codeiq.jp わたしは仕事で「Javascript」使っているのでやっぱり「JSちゃん」を推しておきましょか。 ゲームを作りながら楽しく学べるHTML5+CSS+JavaScriptプログラミング (NextPublishing) 作者: 田中賢一郎出版社/メーカー:
http://martinfowler.com/bliki/TestCoverage.html 「テストカバレッジ(コードカバレッジ)の目標値はどれくらいがいいのか?」という質問とか、コードカバレッジの高さの自慢とかを、ときどき耳にする。でも、大事なポイントを外している。コードカバレッジは、コードのテストされていない部分を発見するための有用なツールである。ただテスト自体がどれだけ良いかという指標としては、テストカバレッジはほとんど役に立たない。 二つ目の例を先に検討してみよう。「カバレッジが87%以上じゃないと本番には入れない」というようなことをやっているところも多いみたいだ。「TDDやっているならカバレッジが100%があたりまえ」という言葉を聞くこともある。賢人が言った: カバレッジが高いことを期待する。マネージャがそう期待することもある。でも微妙な違いがある。 – Brian Mari
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く