1年で150個のPull Requestを出した話。あるいはOSSに継続的にコントリビュートするということについて - Qiita
なんかエモいこと書きたくなったので書きます。 はじめに CrystalというRubyライクなプログラミング言語のコンパイラに、1年間(2016/12/26〜2017/12/25)で150個のPull Requestを出しました。 https://github.com/search?p=1&q=author%3AMakeNowJust+type%3Apr+repo%3Acrystal-lang%2Fcrystal+created%3A2016-12-26..2017-12-25&type=Issues&utf8=✓ 今年は閏年ではなかったので365 / 150 = 2.43333...、というわけで3日に1回以上のペースでPull Requestを出したことになります。 随分とたくさんのPull Requestを出したものです。 また、150個のうちマージされたものは106個でした。 htt
イマドキのJavaScriptの書き方2018
PySpa統合思念体です。これからJavaScriptを覚えるなら、「この書き方はもう覚えなくていい」（よりよい代替がある）というものを集めてみました。 ES6以降の難しさは、旧来の書き方にプラスが増えただけではなく、大量の「旧来の書き方は間違いを誘発しやすいから非推奨」というものを作り出した点にあります。5年前、10年前の本やウェブがあまり役に立たちません。なお、書き方が複数あるものは、好き嫌いは当然あると思いますが、あえて過激に1つに絞っているところもあります。なお、これはこれから新規に学ぶ人が、過去のドキュメントやコードを見た時に古い情報を選別するためのまとめです。残念ながら、今時の書き方のみで構成された書籍などが存在しないからです。 たぶん明示的に書いていても読み飛ばす人はいると思いますが、すでに書いている人向けではありません。これから書くコードをこのスタイルにしていくのは別にいい
IntelliJ Ideaでテスト駆動開発を爆速にするショートカット集 - Qiita
IntelliJ Ideaでテスト駆動開発を爆速にするショートカット集 前提 Mac,Java,Junit5 Windowsのショートカットキーも分かる範囲で記載しています。 はじめに 現在、2017年10月に和訳版が発売された「テスト駆動開発(https://www.amazon.co.jp/dp/B077D2L69C/)」を読んでいます。 本書の中に出てくるソースコードを写経することでより実践的に学べるということで、IntelliJ Ideaを使って写経しています。 写経の中で私が学んだ、IntelliJ Ideaでテスト駆動開発を進めるために使えるショートカットを紹介したいと思います。 ※ほとんどIntelliJ Ideaの公式チュートリアルの内容です。詳細は公式チュートリアルを参照してください。（https://www.jetbrains.com/help/idea/tutoria
書籍「テスト駆動開発」を写経するための環境構築 - Qiita
はじめに 書籍「テスト駆動開発(Kent Beck著,和田卓人訳)」を写経するために環境構築を行なったので、手順を残しておく。 構築の方針 Eclipseを使う。 書籍と同じ環境で進めたい。 JUnitがEclipseと連携する使い勝手を見たい。 細かい設定はしない。 とりあえず使えないと始まらない。あとからだんだん使えるようになるであろう。 環境 MacBookPro(Late 2013) macOS Sierra 10.12.3 手順 インストールと起動 ここから、Eclipse IDE for Java Developersをダウンロードしてインストールする。 そして、アイコンを押して起動する。 起動すると下記が出るがここはなにもせず[Launch]でよい。 これで最初の画面が出てくる。 プロジェクトの作成 起動後の画面で[Create a new Java project]を選ぶ
Webアプリケーションフレームワーク導入時に考慮すべき22の観点 - Qiita
本記事では、 チームによる持続的に変更可能なWebアプリケーションの開発を目標に、フレームワーク導入時に考慮すべき22の観点を紹介する。 フレームワークによって特徴は異なるが、本番導入にあたって、考慮すべきポイントはあまり変わらないので、極力フレームワーク1に依存しすぎないよう配慮する。また、話をシンプルにするため、REST APIを提供するアプリケーションを題材とする。 前提 ソフトウェアのエントロピー ソフトウェアがエントロピー増大の法則を避けられないことを、体感している開発者は多いだろう2。普通にアプリケーション開発を続けると、開発スピードは鈍化し、品質は低下してバグが増え、開発者からは技術的負債への怨嗟の声が聞かれるようになる。エントロピー増大というフォースは極めて強力で、意思を持って立ち向かわなければ、容易にダークサイドに堕ちてしまう。 関心事の分離 大規模Webアプリケーション
TDD(テスト駆動開発)をするぞという強い気持ちをもって新訳「テスト駆動開発」を読んでいるお話 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに Ateam Hikkoshi Samurai Inc. Advent Calendar 2017の13日目です。 本日はエイチーム引越し侍の今年5月入社のRubyist、 @ex_SOUL が担当します。 背景: なぜTDDについて書こうと思ったのか 以前、CodeRetreatイベントに参加した際、周りのRubyistが当たり前のようにテストを書いていたため、このままではいけない…！という危機感を持ったことが始まりでした。 そして先日新訳版の「テスト駆動開発」を購入しました。 翻訳に和田卓人さん( @t_wada ) が携わ
Amazon Auroraの先進性を誰も解説してくれないから解説する - Qiita
TL;DR; Amazon AuroraはIn-Memory DBでもなくDisk-Oriented DBでもなく、In-KVS DBとでも呼ぶべき新地平に立っている。 その斬新さたるやマスターのメインメモリはキャッシュでありながらWrite-BackでもなくWrite-Throughでもないという驚天動地。 ついでに従来のチェックポイント処理も不要になったのでスループットも向上した。 詳細が気になる人はこの記事をチェキ！ Amazon Aurora Amazon AuroraはAWSの中で利用可能なマネージド(＝運用をAWSが面倒見てくれる)なデータベースサービス。 ユーザーからはただのMySQL、もしくはPostgreSQLとして扱う事ができるのでそれらに依存する既存のアプリケーション資産をそのまま利用する事ができて、落ちたら再起動したりセキュリティパッチをダウンタイムなしで(!?)適
テストがなかった無法地帯にテストを導入して開発速度を1.7倍にした話 - Qiita
テストがなかった無法地帯のプロジェクトに自動テストを導入して、開発速度を1.7倍にした話をします。 自動テストがなぜないのか 自動テストのないプロジェクトには、そうなる理由が必ず存在します。よくみる理由は、「時間がないから1」「テストの書き方がわからないから」「無理やりテストを書いたつらい経験があったから2」といったものです。今回のプロジェクトの場合は、以下の2点でした： 自動テストの書き方がわからないから レビューがテスト代わりだったから まず、チーム編成が変わって私ともう一人がチームに加わるまで、実装者の中に自動テストの経験者はいませんでした。このような状況では、自動テストは困難になります。なぜなら、何をどうやってどこまでテストするかを決めるには、多少の慣れが必要だからです。この慣れがないと、何をしたらいいかわからないという状態に陥りがちで、結果として自動テストが後回しにされてしまいま
【リアルタイム共同編集】Atomで出来るようになったってよ - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? GithubがAtomのパッケージに Teletypeをリリースしました！ 公式サイト：Teletype for Atom また9月には、Atomを統合開発環境にするという「Atom IDE」パッケージが出ましたね！ ->Atomに統合開発環境パッケージが出たってよ 早速どんなものか説明したいと思います Teletypeってなに？ 簡単にまとめると 「離れていても複数人で同じファイルを**リアルタイムに編集**できる」ものです。 共同編集できるとなんなの？ 例えば上司や先輩にコードレビューをしてもらうときにわざわざ対面で行う必要がなく、
関数型言語Elmでテスト駆動開発(第1~4章) - Qiita
遂に新訳「テスト駆動開発」が発売されましたね！今回の記事では第一部のJavaで書かれているコードを関数型言語Elmでテスト駆動開発(TDD)に挑戦してみたいと思います！その狙いは、以下の通りです。 写経ではなく別言語で書き換えることで、TDDの習得を目指す Elm自体の勉強 オブジェクト指向プログラミングとの違いを明らかにする 関数型言語がTDDに適しているかを検証する 関数型言語やElm自体の布教 目的のほとんどが検証・学習や布教目的ですが、今回の記事の内容を書いている時点で既に関数型のパワーを大きく実感しております。初回の内容にして1~4章なのは、その力が強大がゆえです。どれほどElm-TDDを続けるかわかりませんが、なるべく第一部の内容完結を目指したいと思います。 方針と注意事項 この記事の方針ですが本文の内容やコードは、著作権を考慮して極力載せすに、ElmによるコードとテストのTO
JavaScriptフレームワーク選定の議論 - Qiita
相談内容 既存の管理ツールを新しく作り直すために新しいJSフレームワーク/言語使いたいのですが、何を選んだらよいでしょうか？ ここで選んだものは今後新しく作る時にも使用していく予定のため、学習コストよりメンテナンスしやすいものを選びたいと考えています。 利用者は社内外で特定の権限を持った人のみであるため、サーバサイドレンダリングはしない予定です。 言語は型があるものを利用したいのですが、TypeScriptとFlowのどちらがよろしいでしょうか？ 時間に余裕があれば、テストフレームワークやビルドツールについてもお聞きしたいです。 現在のページ/チーム jQueryなどで書かれている部分が多いですが、変更を加えることが難しくメンテナンスコストが高いです。 サーバサイドをやってる人が片手間で書くJavaScriptといった状況です。 今回新規で数ページを追加する必要があるため、何を利用すれば良
AMP/PWA をどこで/いつ使うか - Qiita
某所で使った資料の公開版 用語整理 PWA: ネイティブアプリのようなUXを提供するための機能群 SPA: JSで遷移するシングルページアプリケーション AMP: 後述 PWAMP: AMPで流入させてPWAを起動する形式 MFI: モバイルファーストインデックス いまさら聞けないPWAとAMP アメブロ2017: Isomorphic Web Appの進化編 AMP とは イニシャルビューのためのHTMLの特殊なサブセット GoogleにホワイトリストされたHTML属性しか使えない GoogleにホワイトリストされたJSプラグインしか使えない CSSはHEADに全部書く AMP仕様を満たすと、Googleがキャッシュして、モバイルの検索流入ではそのキャッシュを使う HTTPS必須 必ずしも全ページをAMPに対応する必要はない PWA: ServiceWorker の機能 リソースの先読み
GraphQLは90%のウェブサービス開発者にはまだ時期尚早ではないか - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? PySpa統合思念体です。チャットで話をしたことのまとめです。何人かで雑に話をしたことのまとめで、特定の誰かの発言というわけではなく、一種の怪文書です。 さて、GraphQLが世間を賑わせ始めています。Facebookが開発し、GitHubも機能提供をし始めました。GraphQLはRESTの未来か？みたいな論調もありますが、新しいものが出てくると既存のものをサンドバックにして「まだそんな古いの使ってやがるのかよwwwww」みたいな煽りをするのはもはやウェブ界隈の風物詩になっていますが、そういう信者発言をして「ああ、あいつまた踊らされてる
もういい加減「nullチェックをしたら安全」とかわけのわからないことを言うのはやめよう - Qiita
（僕の主観で）クソな記事をたまたま読んでしまってもにょったので愚痴。 Safe Harbor Statement 以下の事項は個人の見解であり所属する組織の公式見解ではありませんし、明日になったら違うことを思っているかもしれませんがそういう類のものです。 某所で危険と言われていたコード public void hogeMethod(Hoge hoge) { //hogeを使った処理 hoge.doSomething(); return; } 安全な理由: NullPointerExceptionが発生しない 僕がいいたかったこと それ、NPEを握りつぶしているだけですから！！！！！！！ (とくにJavaの世界においては)非検査例外というのはコーディングバグを示してくれるものですから、へんなnullチェックをいれるのではなく、積極的にNPEを発生させていきましょう。 こういうわけのわからない
不思議の国のSE用語 - Qiita
不思議の国 SEが住んでいるところ、そこは不思議な不思議なお国柄です。 新たな国民として移住してきた人、特産物のシステムを買いに来た人など色々な人がこの国には存在します。 しかしこの国で話される言葉は 独特 です。 ぱっと聞いただけでは意味がわからなかったり、よく似た表現であっても微妙にニュアンスが違っていたり。 似たような表現を使い分けるその裏に、その人の意図や省略された文脈が隠されていたりもします。 どこの国でもコミュニケーションを間違うと非常に厄介ですが、そんなことにならぬよう、 お国言葉らしきもの をまとめてみました。 SEを代表例として、このお国言葉を話す人も、話される人も、改めて言葉の意味合いを見つめなおしてみると新たな気付きが得られるかもしれません。 なお、そんなことから 「絶対にSEしか使わない用語」を集めたわけではない のでその点ご了承くださいませ。 他言語版 @micr
NginxでWebサーバ間をトレースするrequest_id - Qiita
$request_id Nginx 1.11.0 以降に限りますが、リクエスト毎に発番されるIDの変数として $request_id が追加されたようです。 http://nginx.org/en/docs/http/ngx_http_core_module.html#var_request_id この変数を利用することにより、Nginxコアだけでサービス間のトレースを簡単に行うことが可能になります。 シンプルな例 以下のように、$request_idをログに含めるだけでリクエスト毎のIDを記録できます。 http { log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "
マサカリの起源について - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 技術的な指摘をすることを「マサカリを投げる」と呼ぶ。ネットスラングにありがちだが、この言葉の意味は常に変動しており、地域、人によっても定義が異なる。現在では、何か自分で詰めが甘いことを書く時に「修正、批判コメント歓迎」の意味で「マサカリをお願いします」と言ったり、誰かが適当なことを書いてコメントやブコメで炎上している時に「さっそくマサカリ投げられてて草」というような使われ方をしているようだ。 この「マサカリ」という言葉がいつ、どのような形で使われるようになったのか、できる範囲で調べてみた。 2006年以前 僕は1990年代の後
なぜあなたのPull Requestは読まれないのか - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Pull Requestを出してレビューしてもらってから反映。 どこにでもあるありふれた開発フローに付きまとう、どこにでもあるありふれた問題。 「Pull Requestがレビューされない」 もちろん開発フローにレビューが含まれている以上、レビューをしないメンバーにも非がないとは言えませんが、多くの場合はレビューされないPRには問題があるものです。 デカい 兎にも角にもデカいPRは読むのがつらいです。 もちろん要件が明記されていないなど、他にもPRが読みにくくなる原因はたくさんありますが、一番はこれです。 極端な話、1行変更のPRは他に
kobito-oss のソースの読み方 - Qiita
メインの開発者として、備忘録を残しておく。 どんなものか試したい人は、 https://mizchi.github.io/kobito-oss/ で、IndexedDBの許す5MBぐらいまでは試せる。 一応言っておくと、これは僕が退職するんでOSS化ってわけではなく、元々あった計画の前倒しです。時期が早まったのはある。 以下、どのようにコードを読むか。 念頭に置くこと 2年前 の技術選定のスタック Mac版Kobitoと仕様が違う。Kobitoと同期しない、Inboxという仮グループがある。 mizchi/arda electron 以前の atom-shell 時代の互換コードが一部残ってる 細々とバグ対応はしつつ、あんまり依存パッケージのメンテ出来てなかった 公開にあたって、個別のタスクの綺麗さより、ビルドできるの優先した とりあえず yarn で固定して yarn upgrade-i
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ターミナルで始める「テスト駆動開発」写経のための環境構築 - Qiita
