「スキル伝授にはペアプロが最速」というのは何故か - 圧倒亭グランパのブログ
この問いに対して、自分なりの答えを言語化できたのでまとめます。 目次 目次 疑問 実践する機会 自分なりの答え 「コードを書く瞬間の思考」にアドバイスを貰える 他の方法で代替できない ペアプロの欠点 まとめ 疑問 きっかけは、下記の方々のやり取りをTwitterで見かけたからです。 「それをできる人とペアプロする」以上に短期間で新しい技術を身につける方法を知らない。— Jxck (@Jxck_) 2017年2月3日 ペアプロが最速だろうなあ https://t.co/SdbZZ2EypI— Takuto Wada (@t_wada) 2017年2月3日 サッと調べると「最速なのは同意」という意見が大半でした。自分もこれには同意するのですが、「なぜペアプロが最速なのか？」という疑問を持ったのです。 ペアプロ、最速だと思うんだけど、なぜ最速なのかがハッキリわからない。「わからないことがすぐに聞
ロシアの天才ハッカーによる【新人エンジニアサバイバルガイド】 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 弊社に５年間在籍していたロシアの天才ハッカーが先日退職しました。 ハッキング世界大会優勝の経歴を持ち、テレビ出演の経験もある彼ですが、正直こんなに長く活躍してくれるとは思っていませんでした。彼のようなタレントが入社した場合、得てして日本の大企業にありがちな官僚主義に辟易してすぐに退職するか、もしくはマスコットキャラとして落ち着くかのどちらかのケースがほとんどなのですが、彼は最後まで現場の第一線で活躍してくれました。 そんな彼が最後に残していった退職メールがなかなか印象的だったので、その拙訳をここに掲載します（転載について本人同意済み。弊
2015年の心に残った技術エントリ - ゆううきブログ
１年分の自分のはてなブックマークを見直した。 およそ 2,000 URLのエントリの中から、特に感銘を受けたり、記憶に残ったエントリを紹介したい。 2015年にブクマしたというだけで、必ずしも2016年に公開されたエントリばかりではないことに注意。 エントリ Scalable Deployments Advanced Techinic for OS upgradeing in 3 minutes MySQLやSSDとかの話 モバイルアプリのスレッドプールサイズの最適化 性能測定道 情報科学における18のメタテクニック Webオペレーションエンジニアのアウトプットと開発力 はてなに入った技術者の皆さんへ シンプルでかつ最高のJavaScriptプロファイラ sjsp を作りました！ ペパボのインターネット基盤技術研究・開発の活動 インフラチーム改め Site Reliability Engi
世界最強のソフトウェアアーキテクト
2021年9月18日に開催されたXP祭り2021での講演「マイクロサービスに至る歴史とこれから」の講演資料です。 https://xpjug.connpass.com/event/218516/ This document summarizes a microservices meetup hosted by @mosa_siru. Key points include: 1. @mosa_siru is an engineer at DeNA and CTO of Gunosy. 2. The meetup covered Gunosy's architecture with over 45 GitHub repositories, 30 stacks, 10 Go APIs, and 10 Python batch processes using AWS services like K
テストの自動化を考える前に
5. 前職で実際にあった出来事 マネージャ 今回はテストファーストでやります ぐるぐる はい！ マネージャ なので、実装に入る前に テスト仕様書を完成させます ぐるぐる はい？ マネージャ テスト仕様書は実装開始までに Fix され、以降の変更は認めません ぐるぐる はいぃぃぃぃ？
ソフトウェア開発時に気をつけてる振る舞い - futoase
他人と開発する多人数開発(2名以上)のお話。 なんとなく思ってること。 修正してください 仕様が変更になった上での変更であれば、修正ではない。 ので、「変更した理由」と「変更して欲しい意図」を説明する。 その前に一言、「修正」とかチケットで「修正」とつけてはいけない。 その人は「変更前の仕様」を充足した形で実装していたのだから。 バグを出した後の言葉かけ 僕は率直に、見つかってよかったと思うし、そう表現するのだけど、 人によって追い詰める言葉を発してしまう。 追い詰めると、次バグが見つかっても「気が付かなかったフリ」をされてしまう。 そうなると品質が下がる。意味が無い。 話を自己の経験100%で話してしまう 自分が得られた知見は重要なんだけど 働いてきた場所は10も無いだろう。というので 50%ぐらいに抑えて、後は他社の事例とか、 なんか優れたようなドキュメントとか開発の歴史事例とか それ
「ほとんどのユニットテストが役に立たない理由」を読んで | POSTD
数ヶ月前、私はJames O Coplienの ほとんどのユニットテストが役に立たない理由 という記事に出会いました。Jamesはほとんどのユニットテストは無意味であると考えていて、タイトルは内容をそのまま正確に表しています。彼は 追加記事 で議論をさらに展開しています。私は彼の議論に大変興味をそそられました。というのは、私はユニットテストから多くの利益を得ているからです。私たちはどうしてこのような異なる見解を持つに至ったのでしょうか？ 私が何かを見逃したのでしょうか？ 結局のところ私は彼の見解に賛成できませんでした。以下は彼の記事に対する私の意見です。 ユニットテストが必要な場合 私の経験では、ユニットテストはアルゴリズムロジックに対して行う時に最も有益です。結合度の高いコードについてはその性質から特に有益ではありません。結合度が高いコードはユニットテストのために多くのモックオブジェクト
クラスの命名のアンチパターン - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 昔から「名は体を表す」と言ひます。クラスの名前がクラスの果たす役割と一致してゐるかどうか常に考へ続けませう。 ImageInfo, AccountData, etc. Info って何やねん? Data って何やねん? ImageInfo って Image とはどう違ふねん?? FooInfo や FooData よりも好ましいかもしれない名前の例: FooAttribute, FooProperty, FooMetadata, FooDescription FooConfiguration, FooSetting, FooParame
デキるプログラマだけが知っているコードレビュー7つの秘訣
SonicGarden Study #11で放送された資料から一部スライドを抜いたものになります。 http://sonicgarden.doorkeeper.jp/events/13229 ----- 優れたプログラマだけが優れたソースコードを書くことができます。 では優れたプログラマになるにはどうすれば良いでしょうか。 自分の書いたコードを、優れたプログラマに指摘してもらうことが一番の近道です。それがコードレビューです。たった一人でコードレビューも受けずに、ただ書き続けてもクソコードはクソコードのままなのです。 そこで今回は、良いコードが書けるプログラマになるための、コードレビューを上手に実践する秘訣を話します。Read less
使いやすいシェルスクリプトを書く
できればシェルスクリプトなんて書きたくないんだけど，まだまだ書く機会は多い．シェル芸やワンライナーのような凝ったことではなく，他のひとが使いやすいシェルスクリプトを書くために自分が実践していることをまとめておく． ヘルプメッセージ 書いてるシェルスクリプトが使い捨てではなく何度も使うものである場合は，本体を書き始める前に，そのスクリプトの使い方を表示するusage関数を書いてしまう． これを書いておくと，後々チームへ共有がしやすくなる．とりあえずusage見てくださいと言える．また，あらかじめ書くことで，単なるシェルスクリプトであっても自分の中で動作を整理してから書き始めることができる．関数として書くのは，usageを表示してあげるとよい場面がいくつかあり，使い回すことができるため． 以下のように書く． function usage { cat <<EOF $(basename ${0})
継続的システムテスト - Test Automation
JaSST'Tokyo 2014で、"システムテスト自動化による大規模分散検索プラットフォームの開発行程改善"という題目で事例発表をした。下記は当日発表に用いたスライド。 【JaSST'14 Tokyo】システムテストの自動化による 大規模分散検索プラットフォームの 開発工程改善 from Kotaro Ogino ここでは、この発表に入りきらなかったコンセプトや、口頭でしか説明していないためスライドを読んでも分からない部分について補足する。 背景：開発スタイルの変化 -継続的テストについてリーンとDevOpsから考えてみる リーンは、顧客目線でソフトウェアの価値を定義し、それらをエンドツーエンドで細く速く流れるように開発するスタイルだ[1]。小さい要件を要求分析から品質保証まで流れるように実行し、少しずつリリースして行く。ウォーターフォールでは、重厚長大にそれぞれの工程を実施していたのに
Webアプリケーションの構成に関する予備知識 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 自分の担当したWebアプリケーションを引き継ぐ際に、予備知識として説明したことのまとめ 注意事項 もともと明確に定義されていない概念や、簡単に説明するため正確さを犠牲にした部分が多い 間違っていることを前提に、疑いながら読むのがベター アプリケーションの層構造 アプリケーションを構成するオブジェクトには非常の多くの種類がある アプリケーションの（より良い）構成をオブジェクト単位で考えるのは難しいので、もっと粒度の大きい単位で考えたい アプリケーションをいくつかの層（オブジェクトの所属するグループ）に分割し、層単位でアプリケーションの構成
レガシーコード改善ガイドを読んだ - $shibayu36->blog;
レガシーコード改善ガイド (Object Oriented SELECTION) 作者:マイケル・C・フェザーズ翔泳社Amazon レガシーコード改善ガイドを読んだ。 この本では、レガシーコードの内部をリファクタリングする際に何を気にする必要があるかとか、非常に長いモンスターメソッドをリファクタリングしていく時にまずどこからやるかとか、そういうことが書いてある。とにかくレガシーコードに直面して何から始めたらいいかわからないという時にはおすすめ。 リファクタリングという本と近い内容だけど、僕の中ではこの本よりはリファクタリングの方がなんとなく肌にあった。また今度再読してみようと思う。 印象に残ったところを書いていく。 依存関係を排除する 「たいていの場合、テストの最大の障害となるのが依存関係です」と書いてあるのだけれど、これは確かにと思った。いつもは無意識にやっているけど、言語化されてよかっ
要するに DI って何なのという話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
友人から「しんぺいさん DI について書いてほしい」みたいな話をだいぶ前からされてたんだけど書く気力ずっとなかった。でも仕事の気分転換にちょっとずつ書いたやつがいい量まとまったので公開するです。たいしたことは書いてないっていうか知ってるひとにはあたりまえのことしか書いてない。サンプルコードはわたしの趣味で Scala で書いてあるが、Java が読めればなんとなく読めると思います。 DI ってなに Dependency Injection、日本語で言えば依存性の注入です。おしまい。 で記事を終えてもいいんだけど、そもそも依存性とはなんなのか、それを注入するとはどういうことなのか、なぜ DI が必要となるのかみたいな話をこれからします。 そもそも依存性ってなあに 例を出します。入力された文字列をもとにおみくじをひいて、その結果を twitter に投稿するプログラムにしましょう。 まずは普通
ユニットテストにまつわる10の勘違い | DevelopersIO
渡辺です。さる方面からテスト系のエントリーがまだか…と催促されたので、ユニットテストについて少し考えてみたいと思います。 最近、TwitterのTLをチェックしていると、JUnitを利用しているにも関わらず違和感のあるTweetや、原因をJUnitにして本来解決すべき問題から目をそらしているようなTweetを多く見かけます。そこで、JUnitをによるユニットテストに関するありがちな勘違いをまとめてみました。 なお、JUnitの部分は、RSpecでもNUnitでも適当に置き換えて読んでも構いません。 1.JUnitを使うことが目的という勘違い JUnitを利用すること自体を目的にしたところで何も得る事はありません。 ありがちな話ですが、「納品物としてJUnitのテストコード（または実行結果）を求められている」ことが理由でJUnitを利用しているならば、それは足かせでしかない可能性があります。
xUnit Test PatternsのTest Doubleパターン(Mock、Stub、Fake、Dummy等の定義) - 千里霧中
最近、昔作ったTest Doubleの解説資料を参照・引用してくれる方がちらほら出ていて恐縮しているのですが、見直してみると結構わかりにくい資料なので今回文章としてまとめたいと思います。内容は世間一般的に言われているMock、Stub、Fake、Dummyといった言葉の定義になります。 Test Doubleとは Test Doubleとは、テスト実行時に、テスト対象が依存しているコンポーネントと置き換わるものです。「テスト代役」と訳されることもあります。世の中でMock、Stub、Fake、Dummyなどと呼ばれているものの総称に位置づけられます。 簡単な例を以下に示します。このコードでは、テストメソッド「テストコード()」がメソッド「テスト対象()」をテストしています。また「テスト対象()」は、中でメソッド「外部メソッド()」を実行しています。なお「外部メソッド」はテスト対象でないとし
「本当の基礎からのWebアプリケーション入門――Webサーバを作ってみよう」始めました - K.Maebashi's はてなブログ
以前から「誰か書いてくれませんかね」とか言っていた「本当の基礎からのWebアプリケーション入門――Webサーバを作ってみよう」ですが、誰も書いてくれないので自分で書きました。 本当の基礎からのWebアプリケーション入門――Webサーバを作ってみよう http://kmaebashi.com/programmer/webserver/index.html 現状、合計で140行くらいのJavaプログラムで、普通に画像やCSSを含むWebページが表示できています。こちらのページの下のほうにも画像を貼っていますが、こんな感じで、ローカルのファイルシステムに置いてある私のWebサイトのトップページが表示できていますし、もちろんリンクをクリックして遷移することもできます。 「えっ? Webサーバってこんなに簡単に書けるの?」と思う人も多いのではないでしょうか。 もちろんこんなのは「わかっている人」から
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PHP7 で堅牢なコードを書く - 例外処理、表明プログラミング、契約による設計 / PHP Conference 2016
はてなブログチームの開発フローとGitHub
プログラマのスキルが1日でガンガン伸びた！ #coderetreat in Drecom powered by AgileShibuya | Act as Professional
