数値で測るコード品質 - give IT a try
プロフィールのところにも書いてあるのですが、おいらの目標は「美しく無駄のないシステムアーキテクチャを設計、構築すること」です。 なぜならシステムの保守性や拡張性って、アーキテクチャやコードの品質によって雲泥の差が出ることを、幾度となく痛感してきているからです。 しかし、どんなアーキテクチャやソースコードがキレイなのか、拡張性や保守性が高いのか、っていうのはなかなか客観的に判断しにくいのもたしか。 「俺のコードはあんたのより分かりやすい」 「そうですか？？」 「絶対そうやろ！？なんでわからんのや？？？」 みたいな議論が始まったらたぶん平行線になっちゃいますよね。 そこでツールを使って、コードの品質を定量的に測ってみることにしました。 今回使ったツール 今回使ったツールはこちらです。 SourceMonitor V3.5 http://sourceforge.net/projects/dupl
プログラミングにおける不安と学びのプロセス - 人間とウェブの未来
僕の場合、実現したいことをコードで書けない時には、ひたすら似たコードを読んで理解して写して…を繰り返す。そのうちに手元に大量の自分のサンプルが溜まっていく。その繰り返しがパターンの細分化を促し、書けるコードの幅を広げていく。書けるコードを気持ちよく書き続けてるだけでは新しいコードは書けないからだ....と、向き合えるようになるには時間がかかった。 書き慣れたコードの延長で書いていると、自分でコードを書けている実感があって、リファレンスなど何も見ずに自分の力でプログラミングできている感があるのだが、ある時これはただ「慣れ」の感覚を高めているように思えた。素早く書けること自体は、それはそれで一種のスキルで素晴らしいのだけど、実現したいことをコードで書けるようになる、という観点で振り返ったときに、どうしても成長を感じなかったのだ。それ以来、まずいと思い、実現したいことを思い描き、それを実現するた
Treasure 2017 の研修資料は Go を学ぶのに最高だった - kakakakakku blog
Go 関連の本を読んだり，サンプルコードを写経するだけではなく，もっと実践的に勉強したいなと思って調べていたら，VOYAGE GROUP の Treasure 2017 と言うインターンシップの研修資料が GitHub に公開されていることを知って，さっそく挑戦してみた．数日間取り組んでみて，とにかく素晴らしかったので，紹介したいと思う．suzuken 先生，素晴らしすぎます！ Go入門 GitHub - voyagegroup/talks 学べるテーマ Go の研修資料とは言え，幅広いテーマで Go を学ぶことができる点が素晴らしかった．ザッと挙げるとすると以下のようになる．テーマを見るだけで，もうワクワクしてくるのではないだろうか？ アルゴリズム実装とテストコード フィボナッチ数 スタック CLI net/http curl 実装 スクレイピング実装 コンカレンシー goroutine
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える - pospomeのプログラミング日記
devfest 2017 tokyo の発表資料です。 Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える from pospome 当日は入室できない人もいたらしい & 機材トラブルで10minほど開始が遅れてしまった ということで申し訳なく思っています。 また、立ち見する価値がある内容を提供できたのだろうか? とも思っています。 スライドは単体でも発表内容が伝わるように文章を多めに載せているので、 是非確認してみてください。 100ページ越えていますが・・・。 #DevFest_room2 入れなかった。。— t.junichi (@tjun1) 2017年10月9日 ものすごい立ち見人数 #Devfest17 #DevFest_room2— バトルプログラマー柴田智也@少女終末旅行 (@tomoya_shibata) 2017年10月9日 ルーム2これから並ぶ方はま
これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE
和田卓人さんによるテスト駆動開発問題解説の寄稿です！ バグのないよいコードを書くには、よいテスト設計が重要です。今回は現在時刻に関する問題と、その問題で提出された実際の解答コードを紹介しながら、どのようにテスト設計し開発していくのかを解説していきます。 ゲスト解答による解答コードも公開中！ by CodeIQ運営事務局 はじめに こんにちは、和田(@t_wada)です。今日は先日出題させていただいたTDDに関する問題の総評を行いつつ、テスト容易性設計について考えてみたいと思います。 問題文 私が出した問題は、以下のようなものでした。 問1. 下記の仕様をテスティングフレームワークを使ってテストコードを書きながら実装してください。 【仕様1】 「現在時刻」に応じて、挨拶の内容を下記のようにそれぞれ返す機能を作成したい。 (タイムゾーンはAsia/Tokyoとする) 朝(05:00:00以上
テストコード：本物コードはテストに優しく - Strategic Choice
どういうこと？本物のコードを書くときに、前もってテストを書いておいたり、前もって書かないまでも、後から書くテストを意識しておきます。すると、面白いことに、テストしやすいような、テストに優しいコードを設計するようになります。そして、このことは、テストそのものへの好影響だけでなく、本物のコードの設計品質を飛躍的に向上させることになります。どうして？本物のコードは、テストに優しい設計を行うと、振る舞いごとにうまく分割されて、自然に構成されていきます。プログラムをクラスやメソッドに分割するというのは、疎結合にしたほうがテストしやすいからです。プログラムが密結合していて、クラス間でメソッド呼び出しがたくさん行われ、メソッド呼び出しに多くの引数が必要だったらこうはいきません。プログラムが理解しにくいだけでなく、テストコードも汚くて読み書きしにくいものになっているはずです。どうすれば？コードを設計してい
ユニットテストを書かないことについて - Line 1: Error: Invalid Blog('by Esehara' )
はじめに 最近は、同じ職場で働いている人に対して、『テスト駆動開発入門』の本を貸したり、自分自身でも全く更地のところにユニットテストを書くという作業をやったり、あるいは実装中にもユニットテストを書かないと、コードを書く手が少し滞ってしまうくらいには、テストに依存している自分がいる。 さて、ここ最近で一連のテストの話が各方面から出ていて、それらの議論について興味深く感じる一方で、たとえば自分はそうだけど、「執拗にテストを書いているけれども、これで前に進んでいるんだろうが」という罪悪感みたいなのを抱えている人というのは、それなりにいるんじゃないかと。特にユニットテストを腐らせて、テスト自体を負債にしてしまった人であるなら特に。 ここ最近の、アジャイル開発であったりとか、あるいはプログラマのための本みたいなのを開いたりすると、たいてい「他のことは良いからテスト書け」と載っている一方で、見回してみ
ユニットテストにまつわる10の勘違い | DevelopersIO
渡辺です。さる方面からテスト系のエントリーがまだか…と催促されたので、ユニットテストについて少し考えてみたいと思います。 最近、TwitterのTLをチェックしていると、JUnitを利用しているにも関わらず違和感のあるTweetや、原因をJUnitにして本来解決すべき問題から目をそらしているようなTweetを多く見かけます。そこで、JUnitをによるユニットテストに関するありがちな勘違いをまとめてみました。 なお、JUnitの部分は、RSpecでもNUnitでも適当に置き換えて読んでも構いません。 1.JUnitを使うことが目的という勘違い JUnitを利用すること自体を目的にしたところで何も得る事はありません。 ありがちな話ですが、「納品物としてJUnitのテストコード（または実行結果）を求められている」ことが理由でJUnitを利用しているならば、それは足かせでしかない可能性があります。
「速」を落とさないコードレビュー
Forkwell Meetup #3 https://forkwell.connpass.com/event/48147/Read less
サイトを37倍に高速化した7つの手法 - オールアバウトTech Blog
今回はオールアバウトのnnmrが弊社サイトAll About Japanの速度を高速化した経緯についてまとめます。 All About Japanとは そもそもAll About Japan（以下AAJ）とは何かといいますと、弊社が提供している訪日外国人向けの日本紹介サイトです。 外国人向けサイトで、英語、中国語（繁体字）、中国語（簡体字）、タイ語、韓国語の5か国語に対応しております。 「Anime」「Izakaya」「Ninja」といったような特集や、実際に観光する人向けのモデルルート記事が特色です。 ■ 特集 (url : http://allabout-japan.com/en/tag/sushi/ ) ■ モデルルート記事 (url : http://allabout-japan.com/en/article/222/ ) 技術的な紹介 LAMP環境です。 （サーバー構成は後に記述
知っていてこだわらない、それがいいソフトウェアエンジニアの条件なんだと僕は思うんだ - assertInstanceOf('Engineer', $a_suenami)
週末の午前中、カフェでアイスコーヒーを飲みながらふとポエムでも書いてみようかと思い立ってしまったので、ちょっと前からよく考えていることを書く。本当に思いつきで書くので乱文になる可能性が高いけどご容赦いただきたい。そもそもブログを書くこと自体が相当久しぶりだ。 僕ももう 30 をすぎて、プログラマの世界ではさすがにもう若手とは呼べなくなり、教育っていうのはおこがましいけど、まあ自分より若い人たちの指導みたいなことをやらないといけない立場になってきたからこそ、「いいプログラマとはどういう人なんだろう。この人たちはどういうことを学べたら幸せだろう。」ということをよく考えるようになった。そういう話をする。 プログラマは手段のスペシャリストである 世の中には目的・手段論みたいな論調が存在する。 「それは手段だよね。目的をはき違えたらダメだよ。」という話はいたるところでよく耳にするんだけど、僕はこれを
Ruby で高速なプログラムを書く
2. 自己紹介：遠藤侑介 • Ruby コミッタ（2008年～） – Rubyのテストを増強した – コードカバレッジ測定機能を 実装した – キーワード引数を実装した – Ruby 2.0 リリースマネージャ だった – 最近は何もしてない 2 ’06下 ’07上 ’07下 ’08上 60 70 80 90 100 coverage(%) 70% 85% C0カバレッジ遷移 4. eval$s=%q(eval(%w(B=92.chr;N=10.chr;n=0;e=->(s){Q[Q[s,B],?"].gsub(N,B+?n)};E=->(s){'("'+e[s]+'")'};d=->(s,t=?") {s.gsub(t){t+t}};Q=->(s,t=?$){s.gsub(t){B+$&}};puts(eval(%q(%(objectXQRXextendsXApp{H("#{e[%((d
Twitterはどうやって1秒に3,000もの画像を処理しているのか | FAworksブログ
現在、Twitter は1秒間あたり3,000枚の画像(約200GB)を作成し持続している。 しかしながら、2015年に Twitter はこれら画像ファイル等メディアファイルの保存方法を改善したために、600万ドルを節約することができた。 以前からそうだったわけではない。Twitter は2012年には主にテキストベースだった。 これはまるで、ホグワーツ魔法魔術学校であのかっこいい動く絵が壁にかかってないようなものだ。 2016年の今では Twitter はメディアを駆使した方向へと移行している。 Twitter は、プレビュー、マルチフォト、gif、vine、埋め込みビデオなどで写真をサポートできる新たなメディア・プラットフォームの開発を経て変化したのだ。 Twitter社のソフトウェア開発エンジニアであるHenna Kermani氏が、Mobile @Scale Londonでの興味
契約による設計から見た例外 - Qiita
正しさは相対的な概念である。 Bertrand Meyer [1] Bertrand Meyer氏は「契約による設計」という概念から例外を導出し、例外の必要性をエレガントに説明しています。また、彼の説明に則れば今までの議論と比べて例外をいくぶんか形式的に扱えるようになります。契約による設計を学ぶ前に、プログラムの正しさについてもう一度考えてみましょう。 プログラムの正しさ あるプログラムが正しいかどうかを判定するにはどのようにすれば良いでしょうか。最も簡単な方法は、あるプログラムの正しさを形式的に定義する事です。より直接的に言えば、あるプログラムの正しさを簡単な論理式で表現します。その論理式が真ならばそのプログラムは正しい。偽ならばそのプログラムは正しくありません。 これだけだと関数の戻り値を検査すれば良いだけのようにも聞こえます。しかし、そう簡単な話ではありません。純粋でない言語の場合、
手続き型のダンジョン生成アルゴリズム | プログラミング | POSTD
この投稿では、以前に TinyKeepDev が こちら で述べたランダムなダンジョンを生成する技法について説明しようと思います。元の投稿に比べて、もう少し具体的に話を進めるつもりです。まずは、以下に示したアルゴリズムの一般的な動作をご覧ください。 部屋の生成 はじめに、幅と高さを持つ部屋を円の中にランダムに配置しましょう。TKdevのアルゴリズムは、各部屋のサイズを生成するのに正規分布を用いています。これは一般的にとてもいいアイデアです。なぜかと言うと、これによってより多くのパラメータを扱うことができるようになるからです。幅/高さの平均と標準偏差間の異なる比率を選ぶと、通常は見た目の違うダンジョンとなります。 ここで実行すべき関数は getRandomPointInCircle です。 function getRandomPointInCircle(radius) local t = 2
新人プログラマ向け・スキル向上のための具体的なアプローチと考え方 - give IT a try
はじめに：「僕にもそんな頃があった」 先日、西脇.rb＆神戸.rbの合同勉強会として「RailsプログラマのためのSQL勉強会」を開催しました。 この勉強会は出題者（＝僕）が出したSQL問題を他の参加者が解く、というスタイルの勉強会です。 参加者の方の中には最近プログラミングを始めた、という人も何人かいました。 そういう人にとっては問題がちょっと難しかったので、ときどき僕がサポートに回って質問に答えたり、解き方をある程度教えたりしていました。 また、話がちょっと脱線して「僕が作ったこれぐらいのWebアプリは、伊藤さんなら何時間ぐらいで作れますか？」みたいな質問を受けたりもしました。 その中で言われたのが、 「説明されたらわかるけど、自分一人でこの答えにたどり着くのは無理です」 「えっ、そんな短い時間で作れるんですか」 といったようなコメントです。 そういったコメントを聞くと、「あー、僕にも
優秀なJavaScriptの開発者になるための5か条 | POSTD
(注記：7/15、いただいた翻訳フィードバックを元に記事を修正いたしました。) 子供の頃、私の興味は互いに関係性のない様々な分野に及んでいました。数学も歴史も大好きでした。 ルネッサンスマン 、つまり 博学者 と言う、複数の分野に秀でた人になりたいと思っていました。これはとても難しい課題で、私は突如として、器用貧乏な人になってしまう危機に直面したのです。 私は特定の分野に特化しなくては、と考え始めました。そうすればたとえルネッサンスマンにはなれなくても、少なくとも、器用貧乏にならなくても済むと思ったのです。どうしたらソフトウェア開発をするのに必要な広い知識を保ちながら、1つの分野で専門性を高めることができるのでしょうか。 この記事では、過去5年間、私が良いJavaScript開発者になるために使ったテクニックとリソースの概要をお伝えしようと思います。 最近の多くのWeb開発者は、ある共通の
【翻訳】あなたが求めていたリアクティブプログラミング入門 - ninjinkun's diary
original: The introduction to Reactive Programming you've been missing (by @andrestaltz) (translated by @ninjinkun, reviewed by @ma0e) あなたはリアクティブプログラミングと呼ばれる新しい方法が気になっている。 勉強するのは大変で、良い教材がないのでさらに難しい。私が勉強を始めたときは、まずチュートリアルを探した。見つけたのは一握りの実践的なガイドだけ、しかもそれらは表面をなぞっているだけで、リアクティブプログラミングのアーキテクチャ全体像を構築しようとしてはいなかった。ある関数を理解するのに、ライブラリのドキュメントは役に立たないことがある。 これを見て欲しい。 Rx.Observable.prototype.flatMapLatest(selector,
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Go at DigitalOcean
例外設計における大罪 - 契約
