GoF デザインパターン チートシート - Qiita
ここまで読んでくださった皆さんに、ちょっとしたクリスマスプレゼント。マンガでわかる GoF デザインパターン 23 種チートシートです。これでもうデザインパターンは完全にマスターしましたよ。やったね! (注: ここからはあとがきポエムです) ところでみなさん、せっかくデザインパターンを学んだので、これを使ってプログラムを書こう、チートシートがあるからなんでも書けそうだぞ、なんて思っていませんか。ダメですよ。そんなことしたら 2000 年前後に起きた失敗を繰り返してしまいます。 実は GoF のデザインパターンは、ビジネス的には成功したけど、教育には失敗しました。最初に出版された本に「オブジェクト指向における再利用のための」という肩書が付いていましたが、これが本当に良くなかった。 あの頃 (ポール・グレアムが LISP と Ruby を褒めるまで) は、「オブジェクト指向様こそが良い設計のす
E2Eテストコードのメンテナンス性に立ち向かう - Qiita
はじめに E2Eテストコードを書くにあたって、一番の心配事は テストが壊れる ことでしょう。 アプリ側の変更に伴いテストをすべて書き直すことを恐れるQAエンジニアは多いと思います。 例えば 機能はまったく変わってないのに、デザインリニューアルでテスト全部書き直しだ〜〜〜！ みたいなやつですね。 ここでは、自分が実際に「メンテしやすい」テストコードを試行錯誤する過程で得られた気づきをまとめていきたいと思います。 なお、自分の活動範囲は主にWebアプリのテストですので、基本Webアプリの話題になりますが、「いやネイティブアプリはこうやねん」みたいなツッコミもお待ちしております。 また、文中に登場するサンプルコードは CodeceptJSで記述しています。 使ったことがない方は気合で読んでください。 メンテしやすい vs メンテナンスフリー はじめに強くお伝えしておきたいことは、メンテナンスしや
トークンを利用した認証・認可 API を実装するとき Authorization: Bearer ヘッダを使っていいのか調べた - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? TL;DR HTTP でトークンを利用した認証・認可をする手法として RFC 6750 がある OAuth に限らず、トークンを利用して認証・認可する機構の一部として Authorization: Bearer ヘッダを使うことができる 使い方について詳しくはこの記事の下のほうに書いた 要求 トークンを利用した認証・認可機構を持つ API を作りたい クライアントがトークンを HTTP リクエストに含めて送信し、サーバはトークンを検証してリソースへのアクセスを許可したい Authorization: Bearer トークン ヘッダでトー
心理的安全性ガイドライン（あるいは権威勾配に関する一考察） - Qiita
権力格差が大きい国の文化圏では、権威勾配が大きくなります。また、個人主義であるほど自己主張がしやすくなるため、意見が生まれやすくなります。男性主義的であると、女性から男性への意見をしづらいと感じる社会であることを意味しています。また、不確実性忌避の傾向が高い国では新しいことや常識の外にあることを受容する力が弱くなり権威勾配が大きくなる傾向があります。 文化的権力格差 Q. あなたの職場では職位を尊称として使うか？たとえば、「〜〜部長」「〜〜課長」など。年少の同僚を「〜〜くん」や呼び捨てするなどの傾向はあるか？ Q. あなたの職場では上長の発言に疑義があっても明確な理由がなければ、反論すべきでないという風土があるか？ Q. あなたの職場では年齢が若い人は年齢が上の人の意見に反論すべきでないという風土があるか？ 年齢や権威に対してものが言えなくなる文化が強い場合、実際の職位の乖離を大きな権威勾
技術選択編 - #golang で CLI 作るときにいつもつかうやつ - Qiita
// cmd/foobar/main.go //---------------------------------------------------------------- func main() { if err := run(); err != nil { fmt.Fprintln(os.Stderr, err) os.Exit(1) } } func run() { cmd := cmd.NewFoobarCommand() return cmd.Execute() } // pkg/foobar/cmd/cmd.go //---------------------------------------------------------------- func NewFoobarCommand() *cobra.Command { var ( flagVerbose bool )
お前らのReactは遅い - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 煽りタイトルですみません。 最近、Reactのプロジェクトのページを動かしていて、 もっさりしてる（レンダリングの負荷が高いな）と思ったので どうやったら無駄なレンダリングを減らせるか思考錯誤したことをまとめました。 preactとか別ライブラリの話はしません。 よかったらこちらもどうぞ ReactJSで作る今時のSPA入門（基本編） 2019年07月06日追記： ブラウザのレンダリングの仕組みに関して良記事があったので先に一読しておくことをおすすめします。 良記事１：実際のところ「ブラウザを立ち上げてページが表示されるまで」には何が起
Kotlin/Native を Android/iOS アプリ開発に導入しよう
Kotlin/Native が Beta 版になりましたね！ Kotlin/Nativeがベータに到達、Kotlin 1.3にバンドル。Win/Mac/iOS/Android/WebAssemblyのバイナリ生成。KotlinConf 2018 - 2018年10月11日 Beta 版リリースの記事が出たばかりですが、私はすでに Kotlin/Native を Android/iOS 両方のアプリに導入してアプリをリリースしています。 Kotlin/Native を導入した経緯などまとめます。 (2018/10/16追記) Kotlin/Native を実際に使いはじめる人向けの記事を書きました → Kotlin/Native Multiplatform プロジェクトで Android/iOS 向けの共通ライブラリを作る Kotlin/Native を使うまでの経緯 Kotlin/Nati
Repositoryパターンのアンチパターン - Qiita
よく見かけるRepositoryパターンのアンチパターンの紹介と対策です。 Repositoryパターンとは Repositoryパターンとは永続化を隠蔽するためのデザインパターンで、DAO(DataAccessObject)パターンに似ていますが、より高い抽象度でエンティティの操作から永続化ストレージを完全に隠蔽します。 例えばDBコネクションやストレージのパス等はReposiotoryのインターフェースからは隠蔽され、Repositoryのユーザは永続化ストレージが何であるか(例えばMySQLやRedis等)を意識することなく保存や検索の操作を行うことができるようになります。 これによりRepositoryを利用するロジックは業務的な操作に集中できるようになる他、データベースの移行等の永続化層の変更が発生した際にロジックへの影響を切り離すことができるようになります。 // 例) ユーザ
ぼくたちのかんがえたさいきょうのi18n国家
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 本記事は下記のtweetから始まるスレッドに触発され、@qnighyや@na4zagin3からアイディアを拝借して書いた。 i18n力が最強の国は国内に複数の言語があり、そのうちいくつかは他国でも使われている言語の方言で、1バイト文字での代替表記が困難で、歴史的にISO-2022ベースの文字コードとUnicodeと独自エンコーディングが混在していて、フリガナなどの特殊な組版規則があり、右書き左書き縦書きを併用し、 — Masaki Hara (@qnighy) 2018年8月6日 皆さんのおかげで最強のi18n国家が建設されつつある。一
スピード感重視なのでテストは書かない。テストはなぜ開発を遅くするか - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? あまりにバズってしまったので、前書きを追加 ここまでバズってしまって正直すまんかった。 この記事はもともと愚痴記事をマイルドにして投稿しただけなので「テストを勧める」とか「テストを信奉する」とかそこまで強い意図は特にありません。（私がテスト好きなのは否定しません） 「テスト書こう」に対して「そんなコストはない」と言いながら、いろいろ問題が生じる現状を愚痴りたかっただけです。愚痴るだけだと生産性がないから、なんでこんなに認識が違うんだろうと原因を考えた結果、テストを書くことに対する技術で実際にコストが大きく異なるなと気づいて書いた次第です
[Kaggle]0から本当に機械学習を理解するために学ぶべきこと～一流のデータサイエンティストを例に～ - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 「機械学習が出来るようになりたい」そう思いつつも、中々身についた感じがしない。 そんな方々に向けて、Kaggleで公開されているデータ分析の手順を追いかけながら、そこで必要とされている知識を解説したいと思います。全体像を把握することで、より理解が進むはずです。 1. データを分析するために必要な統計的知識 機械学習の目的は未知の事柄を推定することです。そのために既にあるデータから何らかの法則性を見つけ出す為に様々な手法が考えられてきました。 統計学はご存知でしょうか？ 機械学習はデータを扱うという点で統計学と深い関係があります。平均値や
![[Kaggle]0から本当に機械学習を理解するために学ぶべきこと～一流のデータサイエンティストを例に～ - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/5d1a76a58eee1163a4fcc972ca11e4b975089503/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCS2FnZ2xlJTVEMCVFMyU4MSU4QiVFMyU4MiU4OSVFNiU5QyVBQyVFNSVCRCU5MyVFMyU4MSVBQiVFNiVBOSU5RiVFNiVBMiVCMCVFNSVBRCVBNiVFNyVCRiU5MiVFMyU4MiU5MiVFNyU5MCU4NiVFOCVBNyVBMyVFMyU4MSU5OSVFMyU4MiU4QiVFMyU4MSU5RiVFMyU4MiU4MSVFMyU4MSVBQiVFNSVBRCVBNiVFMyU4MSVCNiVFMyU4MSVCOSVFMyU4MSU4RCVFMyU4MSU5MyVFMyU4MSVBOCVFRiVCRCU5RSVFNCVCOCU4MCVFNiVCNSU4MSVFMyU4MSVBRSVFMyU4MyU4NyVFMyU4MyVCQyVFMyU4MiVCRiVFMyU4MiVCNSVFMyU4MiVBNCVFMyU4MiVBOCVFMyU4MyVCMyVFMyU4MyU4NiVFMyU4MiVBMyVFMyU4MiVCOSVFMyU4MyU4OCVFMyU4MiU5MiVFNCVCRSU4QiVFMyU4MSVBQiVFRiVCRCU5RSZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZ0eHQtY29sb3I9JTIzMUUyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnM9MDFiNTljZWQ3ZmU2ZTFlMTUxZDE3ZmUyZjE2OTNjNDE%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDB6ZW5vbm5wJnR4dC1jb2xvcj0lMjMxRTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz1mZGE5MjQxZmM0MTFiNTcyYWI4Yzk4NWYxMDQxYmU1ZA%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3D5787942b2ea3723d4eb35b278223dc6b)
大井競馬で帝王賞を機械学習で当てた話 - Qiita
概要 大井競馬場に行く機会があったので、機械学習を使って競馬の結果を予測できるかをやってみました。 その結果、帝王賞で一位を当てることができたので、記事を書きます。 かなり適当な予測なので、遊びとして見てもらえたらと思います。 証拠 当たったという証拠に、記念でとった馬券画像。 機械学習で予測したものと、パドックを見て予測したものと、２つ買いました。 (びびって複勝、しかも300円) 問題の設定 大井競馬場で行われる帝王賞の１位のみを当てます。 競馬には、色々な馬券の買い方がありますが、今回は簡単でシンプルな問題設定としたかったので、1位のみを予測することにしました。 データの取得 教師あり学習を行うので、過去の競馬結果のデータが必要です。 こちらのサイトからデータをクローリングしました。 南関東4競馬場公式ウェブサイト レース情報のページから、レースに出る馬の過去情報があるページへのリン
治安の悪い Slack Emoji を作るツールを作った - Qiita
(治安の悪くない Emoji も作れます) 作ったもの ここで遊べます おもしろいところ GIF アニメのエンコードまですべて js で完結しているので、ありがちな「謎のサーバーに画像アップロードするといい感じに変換してくれる」的なサービスと違って、素性の知れたコードがクライアント側でサクサク動きます。 なにができるの？ 画像を 128px x 128px に変形 画像を、 Slack にアップロードできる（現状）最大サイズの 128px x 128px に変形します。 ローカルのファイルから選ぶか、画像の URL を入力できます。アップロードするわけではないので、デカい画像でもサクサクなのがお気に入りです。 変形は 正方形に引き伸ばし（アス比無視） 正方形いっぱいに拡大して、余ったところはトリミング（アス比維持） 正方形に収まるように縮める（アス比維持） から選べます。 テキストから画像
システムで「性別」の情報を扱う前に知っておくべきこと - Qiita
0は性別に関する情報が得られない場合に使います。性別に関する情報はあるのだけど1とも2とも言えない場合は9を使います。要は「0でもなくて1でも2でもなければ9」です。 これを知っていればMだとかFだとかを議論をせずに済みますね。 国際規格に従うべき理由 国際規格に従うことは色々と利点があります。まず、どうしてそういうコード体系にしたのかを説明しやすいです。また多言語対応する際も規格通りに書けば伝わるはずなので迷わずに済みます。別システムへのデータの移行や、異なるシステム間でのデータの統合もコード体系が同じならラクラクです。もしかしたら別のプロジェクトで書いたコードをそのまま使いまわせるかもしれません。技術者に対するトレーニングも不要です。 対して、わざわざ国際規格に反する実装をする場合は上記のメリットがそのままひっくり返ってデメリットになりはしますが、もちろん、それなりの理由があれば規格と
コミュニケーション能力の正体と「カレー作りの寓話」 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 本記事では、そのなかで触れている二人の人物がパーティのためにカレーを作るという話を紹介します。きっとどこかで見たこ
タイムゾーン呪いの書 - Qiita
技術的な標準・規格 (TODO: IATA, Microsoft) tz database タイムゾーンに関する、ソフトウェア・エンジニアにとって最も標準的なデータが tz database (Wikipedia) でしょう。 "Asia/Tokyo" や "Europe/London" のようなタイムゾーンの名前は、この tz database のものです。 tz database のタイムゾーンは "/" の前の最初の部分に大陸名・海洋名を用い、続いて、典型的にはそのタイムゾーン内の著名な都市名・島名をその代表として名付けられています。21 国名は基本的に使われません。22 "America/Indiana/Indianapolis" のように3要素で構成されるタイムゾーンも少数ながら存在します。 tz database はボランティアによってメンテナンスされています。タイムゾーンの情
2018 年 React と Redux のエコシステム総まとめ - Qiita
Angular などの JavaScript フレームワークは大規模向けに設計されており、標準で多くのエコシステムが組み込まれています。 React は単なる View ライブラリです。そのため View ライブラリを補完するためのエコシステムの選択が必須となります。 エコシステムを自由に組み合わせて開発者とプロジェクトに応じた理想的なフレームワークを作成する必要があるわけです。 これは、小規模アプリケーションから大規模アプリケーションまでの様々な要件やニーズに対応できる柔軟性が高いことを意味していますが、エコシステムを選択するためのコストが必要となります。 下記では、筆者が最低限、導入を検討する余地があると考える主要な React のエコシステムとその簡単な概要を記載しています。 筆者の独断と偏見で選択したエコシステムであることを考慮してお読みいただきたいです。 既知のエコシステム (ほ
プロダクトマネジメントと新規サービス開発 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事は エムスリー Advent Calendar 2017 の24日目の記事です。 この記事では、プロダクトマネジメントと新規サービス開発についてお話します。 1. はじめに エムスリー株式会社ではエンジニアリング強化の一環として12/1からCTO+VPoE（Vice President of Engineering）制度に移行し、私、@yamamutekiが初代VPoEを務めることになりました。最近は採用活動などに力を入れていますが、本業はプロダクトマネージャーで、新規サービス開発や既存サービスのテコ入れを担当しています。今回は
サーバーサイドKotlin (Spring Boot / Doma 2) 入門 - Qiita
この記事は エムスリー Advent Calendar 2017 の18日目の記事です。 今年はKotlinが熱い1年でした！今年の5月に、Googleがandroid開発言語としてKotlinを公式にサポートするとアナウンスしてから、急速に利用が広がっているようですね 出典：https://blog.jetbrains.com/jp/2017/11/29/828 私が所属するエムスリーでも 日本Kotlinユーザグループ代表、長澤太郎が書籍を2冊出版 Kotlin Webアプリケーション 新しいサーバサイドプログラミング Kotlinイン・アクション（共同翻訳） イベント『どこでもKotlin』シリーズを開催 私のチームでサーバーサイドKotlinによるシステムリニューアルを実施 とKotlinに関する話題が盛り沢山の年となりました KotlinはJetBrains社が開発したいわゆるJ
Terraformの使い方 ver.2017冬 - Qiita
続きをかきました→ https://qiita.com/uraura/items/e13d883827443f27bf98 概要 TerraformでAWSのリソース管理をしていますが，(少人数でやるには1)まぁまぁ良い感じに落ちついたのでご紹介します． 以下，話を簡単にするためにTerraformでAWSのリソースを管理しているという前提で話をすすめます． 問題 Terraformは便利で，使いはじめると何でもかんでもコード化してやろう!!などと思ってしまいますが，すぐに以下のような問題にぶち当たります． コード化をすすめるとplan/applyにかかる時間が増大していく planが通ってもapplyでコケる場合がままある コード化をすすめるとplan/applyにかかる時間が増大していく コード化されてるリソースが少ないうちはあまり問題にならないのですが，時がたちコード量が増えてくると
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
