さまざまなテストレベルとロールで活躍されている方々がテストコードをリーダブルにする方法について語り、それぞれの違いや共通点について議論する、「リーダブルなテストコードについて考えよう」。ここで株式会社ソニックガーデンの伊藤氏が登壇。リーダブルなテストコードとは何か、リーダブルなテストコードを書くための具体的な意識を紹介します。 伊藤氏の自己紹介伊藤淳一氏：リーダブルコードという発表です。いきなり余談から入りますが、今日仕事をしていたらテストコードに助けられました。 仕様変更がいつ入ったのかを調べなきゃいけなくなってコミットを追いかけていったら、過去の僕がすごくわかりやすいテストコードを書いていて、仕様Aを仕様Bに変えることがdiffを見れば一目瞭然というようなものを作っていました。リーダブルなテストコードを書いてて良かったと思った日がこの勉強会の開催日で、ナイスタイミングだと思いました。
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 内容 以下記載のURLを参考にロードマップをJavaバージョンにしてみた。 初心者から立派なJava エンジニアになる方への学習の道しるべになれば。 また自分自身すべてできるわけではないので、できるようにするためのメモ書きとして。 （ただ以下をなんとなく理解するだけで2,3年以上かかった。。。） 参考 ※ 会社の同期から基本文法についてレベル別記載のアドバイスをいただいたので修正（2018/4/9） ロードマップ 学習方法 1.Hello World どのプログラミング言語でもそうですが、まずは動かし方を学びましょう。 ゲシュタルト崩壊
最近あんまり触っていなかったので、久々にPythonをやろうと思ったときにいろいろ忘れてたり、新しく知ったりしたこともあったので、Pythonやるときに参考になりそうな情報をまとめました (但し、今回はデータ分析系のライブラリ関連は除いています) Pythonの言語仕様や基本等 概要 — Python 3.5.2 ドキュメントdocs.python.jp qiita.com www.python-izm.com 2系と3系の違い postd.cc qiita.com コーディング規約 はじめに — pep8-ja 1.0 ドキュメント ドキュメント生成 azunobu.hatenablog.com ドックストリング """ 3重ダブルクォートを使用して記載する。 ドックストリングに記述したテキストは関数やクラスオブジェクトの__doc__に保存される def hello(): """Out
レガシーコードをうまく手なずけて、もう一歩成熟させるにはどうすればいいのでしょう？この投稿では、大規模なレガシーウェブアプリケーションと格闘してきた私が学んだことを紹介します。レガシーコードをうまく手なずけて 、もう一歩成熟させるにはどうすればいいのでしょう？この投稿では、大規模なレガシーウェブアプリケーションと格闘してきた私が学んだことを紹介します。 レガシーコードはリファクタリングで救出可能 耳寄りなお知らせがあります！ リスたちは毎年何千本もの木を植えてくれています 。まあ自分たちが隠したドングリのありかを忘れてしまった結果ですけどね。そしてもうひとつ。 あなたのプロジェクトも救出できる のです。 ボスから任されたプロジェクトが どんなに醜い泥まみれのレガシーコードだったとしても 、そこには 必ず 道があります。道は曲がりくねっていて、木陰にはモンスターが待ち構えていることでしょう。
【プログラマー必見！】ライブコーディングが生で観れるサイト「Livecoding.TV」 ここ最近、プログラミングの需要が高まり日本でも動画学習のサービスが増えてきました。 個人的には録画ではなくて、ライブコーディングをしてる動画を見たいなあと思っていました。 生放送でプログラムを書いてるのはschooくらいですかね。 日本にはほぼ浸透していませんが、「Livecoding.tv」という名前からしてライブコーディング以外の何者でもない サービスがあるので紹介していきます。 Livecoding.tv schooと同じように生放送と録画に分かれていて、どちらも見ることができます。 サービスでは、無料プランと有料プランが存在します。 ライブコーディングしている人の国籍を見ると北米、南米、ヨーロッパがメインといったところです。 「japan」で検索かけても日本人じゃないのが不思議ですが笑 サービ
私たちの救世主DHH™は最近の Full Stack Radioのインタビュー で、 Basecamp の最新版で彼がどのようにRailsのコントローラを書いたかを説明しています。下記は、彼のすばらしい話を書き取ったものです。 これまでに思うようになってきたのは、「RESTの原則に従うには、どのタイミングで新たなコントローラを作るべきかを一度決めたら、ほぼ異例なくその原則を遵守するべきだ」ということです。いつだってその方がうまくいくんです。自分の作ったコントローラの状態を悔やむのは決まって、作ったコントローラの数が少なすぎた時です。多くの処理を任せようとしすぎてしまうんです。 そこでBasecamp 3では、ある程度理にかなったサブリソースがあれば、毎回コントローラを分割していきます。フィルタなどの場合ですね。例えば画面があって、それがある状態になっているとします。もしこれにいくつかのフィ
「AIZU ONLINE JUDGE」通称(AOJ)という、"提出されたプログラムの正しさ・効率の自動判定を行うオンラインジャッジシステム"がある。 http://judge.u-aizu.ac.jp/onlinejudge/ いわゆる競技プログラミング・プログラミングコンテストの過去問題などが多数掲載されており、各問題に対してソースコードを提出すると その問題の入力に対する正しい出力が得られているか否かを自動で判定してくれる。 …ていうのを何となくは知っていたのだけど実際に触ったことはなくて。先日 チームラボVSドワンゴ！競技プログラミング勉強会＠ドワンゴオフィス - connpass というイベントに参加したときにオンラインジャッジに関する解説などがあり 実際に数問やってみる、ということでユーザ登録して挑戦してみたので、その後も継続して挑戦してみることにした。 べつに競技プログラミング
第4回ペパボテックカンファレンスで発表した「ウェブサービスを開発するために詩を書いた話」の資料です。 http://eventdots.jp/event/573086
計算機プログラムの構造と解釈、通称SICPを一から翻訳し直しました。 ファイル: SICP非公式日本語版 翻訳改訂版 リポジトリ: https://github.com/hiroshi-manabe/sicp-pdf また、今回の翻訳をするにあたって考えたことを別記事にまとめました。 腐った翻訳に対する態度について SICPはMITの有名なプログラミングの教科書です。詳しくはminghai氏の記事をご参照ください。 この翻訳改訂版は、minghai氏の非公式日本語版（以降、minghai氏版）のあまりにも惨憺たる翻訳を見かねて、原著から翻訳をし直したものです。この翻訳を進めるにあたっては、minghai氏版の訳を置き換えていくというやり方で進めていきました。しかし、差分を取ればわかっていただけると思いますが、minghai氏版のテキストは痕跡をとどめていないはずです。この方式を採ったのは、
PDFのファイル構造を理解すると、テキストエディタでも直接PDFファイルを作ることができるようになります。このエントリーではPDFファイルの基礎要素を説明し、簡単なPDFファイルを例にしてファイル構造を説明します。更に、テキストを渡すとPDFファイルを吐いてくれる簡単なプログラムや、PDFを読み込んで簡単な解析をするプログラムを書いてみます。 目次 目次 まえがき オブジェクト 間接参照 ファイル構造 Hello, world! ヘッダ トレーラ 相互参照テーブル 本体 PDFを生成するプログラム 日本語の扱い方 日本語を含むPDFを生成するプログラム グラフィックス PDFを読むプログラム あとがき まえがき 1990年代前半、アドビシステムズは、どのプラットフォームやデバイスでも文書を確実に表示・共有できることを目的としてPDFファイルフォーマットを開発しました。 PDFの表示ソフト
APIとAPIを組み合わせてマッシュアップサービスを作ろうと思った場合、まず自分が欲しいデータを提供しているAPIを探す必要があります。今回はそんなAPIのディレクトリを提供しているサービスをまとめて紹介します。 PublicAPIs 執筆時点で5,330のAPIから検索ができるAPIインデックスサービスになっています。名前やAPI名などを入れることで、新しいAPIの登録申請もできるようになっています。 PublicAPIs | Directory of public APIs for web and mobile API For That 検索、ソーシャル、ファイナンスなど約20のカテゴリに分かれて登録されています。約300種類くらいのAPIが登録されています。 API For That | An API Directory Zapier IFTTTのビジネス版と言った雰囲気のサービスに
コーディング向けの日本語対応の等幅フォント「Sourceソース Hanハン Codeコード JPジェイピー（和名：源ノ角ゴシック Code JP）」が、2015年6月4日に公開されました。「源ノ角ゴシック Code JP」は、プログラミングやHTML/CSSのコーディング、ターミナルでのテキスト表示など、和欧表示用フォントとしての利用を想定されたフォントです。 ダウンロードはこちらから Release Fonts (OTF, OTC) · adobe-fonts/source-han-code-jp · GitHub ※このフォントは無償でダウンロード可能です。OTCとTTFの両方のフォーマットで配布されているので、Windows/macOSともに簡単にインストールできます。 ※上記リンクの「Fonts version ［バージョン番号］ (OTF, OTC)」となってい箇所の［Sourc
biz.moneyforward.com
日記 (0) プライバシーポリシー (1) プログラマー現役続行 (554) KOIT (12) 英語 (29) インターネット (2) シュガー社員 (6) Java (55) 本 (105) やりがい論 (2) 正誤表 (22) 読書会 (28) インターネット放送 (2) 技術書の翻訳 (5) JavaOne 2008 (3) Google Web Toolkit (24) GWTソリューション (2) プログラミング言語Java教育 (74) 音楽 (4) 英語イデオム (3) 映画 (3) その他 (58) カンファレンス (3) JavaOne 2009 (2) 名言 (2) 転職 (23) WiFi (22) マンション・ライフ (5) API設計の基礎 (10) JavaOne 2010 (3) 時の流れ (9) 技術的負債 (7) 献本 (7) 総閲覧数 (10) ソフト
ここ最近、自分が見ているプロジェクトの1つで、うまくスケジュール通りに作業が進んでいなかったので、その対策をした。 その中でも特に効果があった2つを紹介する。 背景 簡単にプロジェクトの背景を説明する。 スクラムっぽい開発をしている スプリントの期間は2週間 スクラムマスターはいるが専任ではない すでにリリース済みで運用中のWebサービスである 基本的によくあるスクラムっぽい感じで、2週間というタイムボックスの中にチームが作業可能なストーリーを突っ込んで、ひたすら消化する。 スプリントの最後には、レビューをして、次のスプリントの計画を立てる。 スクラムマスターは、一応自分が担当しているが、専任ではないし、他のプロジェクトも見ているので、注意深くチームを見れていない。 課題 以下のような課題があった。 バグの修正や問い合わせ対応など、計画時に含まれていなかったタスクがスプリント中に増えてしま
ソフトウェアアーキテクトが知るべき97のこと大人気の書籍『ソフトウェアアーキテクトが知るべき97のこと』のエッセイを無料で公開中！すべてのソフトウェアアーキテクトにおすすめの本がウェブで読めるようになりました。 エッセイ一覧システムの要件よりも履歴書の見栄えを優先させてはならない本質的な複雑さは単純に、 付随的な複雑さは取り除け最大の問題は、たぶん技術的なことではないまずコミュニケーション、そのための明快さとリーダーシップパフォーマンスの決め手はアーキテクチャー要求仕様の本当の意味を探れ立ち上がろう!すべてのものは、かならずエラーを起こすそれは交渉だということに気付け定量化を求めよ500行の仕様書より1行のコードフリーサイズのソリューションを求めるなパフォーマンスの検討に早過ぎるということはないアーキテクチャーとはバランスをとること犯罪的なコミットエンドラン
エンジニアの渋谷です。 マネーフォワードは3月30日に【給与計算ソフト - MFクラウド給与】という新サービスをローンチさせていただきました。 マネーフォワード、クラウド型給与計算ソフト『MFクラウド給与』(β版)を無料提供開始～法改正や税制改正にも自動対応。企業の給与計算・労務をもっとスマートに～ クラウド給与計算ソフト マネーフォワード クラウド上で完結する本格的な給与計算サービスとして、リアルタイム給与計算機能や料率自動反映などを備えております。 本サービスの企画自体は、昨年年末に３人でスタートし、年明けから様々な方にお手伝いいただきながら、約３ヶ月の開発期間でローンチしました。 今回は、新サービスをゼロから作り上げるにあたり、エンジニアとしてやって良かった、と思えた事を９つばかり紹介させていただきます。 １：リリース前確認シート 企画がスタートした時に、【ビジョン】【ミッション】と
単一責任の原則（SRP:the Single Responsibility Principle） クラスを変更する理由は1つ以上存在してはならない。どういうこと？変更理由が2つあるということは、責任（役割）も2つあるということ。そんなジェネラリストなクラスを許さない、という原則。 ところで、「単一責任」って、クラスを作る上で一見当たり前に見える。責任（役割）をそのまま責任ではなく、変更理由としているところがポイント。 この見る角度を変えるところがこの原則の運用の大切な所。なんで？役割を複数もつクラスはもろいクラスだから。 複数の役割を担っているクラスがあって、それをある1つの理由で変更すると、関係のないその他の役割部分にまで影響を及ぼす事になり、その結果予想もしない形でクラスが壊れてしまう。 保守で違う人が修正したら簡単に壊れてしまう。 保守で変更していくと、実装的だけでなく、設計的にもよ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
