タグ

ブックマーク / qiita.com (317)

  • [和訳] Dropboxアカウントのせいで胃潰瘍になった - Qiita

    こちらのReddit投稿 (https://www.reddit.com/r/sysadmin/comments/eaphr8/a_dropbox_account_gave_me_stomach_ulcers/) の和訳記事です。番環境でやらかしかった人シリーズが盛り上がっていたので波に乗って(?)Twitterにヤバすぎる恐ろしい話が流れてきたのをすかさず和訳してみました。やらかしちゃった人というよりはやらかされちゃった人目線ですがいずれにせよそこら辺の怪談話よりよっぽど怖いです。 Dropboxのアカウントのせいで胃潰瘍になった。 皆は誰もが触れたがらない、会社を紐やガムやクリップでつなぎとめている「例のアレ」を見つけたことってある?そういうのって往々にして大型連休前の金曜午後4:45に落ちるし、般若のような様相を呈した上司が「このままだと第二のスターリングラード攻防戦が勃発するぞ

    [和訳] Dropboxアカウントのせいで胃潰瘍になった - Qiita
  • 設計要件をギッチギチに詰めたValueObjectで低凝集クラスを爆殺する - Qiita

    /// <summary>契約金額</summary> public class ContractAmount { public int AmountIncludingTax; public decimal SalesTaxRate; } 当然データの入れ物(以後データクラスと呼称)だけでなく、税込み金額を計算するロジックが必要です。ここであまり設計を考えないと、この手の演算ロジックはデータクラスとは別のクラスに実装されることが多いです。以下のようにControllerに実装されることが多いのではないでしょうか。 /// <summary>契約コントローラー</summary> public class ContractController { private ContractAmount _contractAmount; /// <summary>税込金額を計算する。</summary>

    設計要件をギッチギチに詰めたValueObjectで低凝集クラスを爆殺する - Qiita
  • Docker再入門 - Qiita

    Dockerにあまり触れる機会が少なく、たまに使うとコマンドとか仕組みをすぐに忘れてしまう。そんな自分へのナレッジ 公式ドキュメント Docker Documentation 上部のメニューで、Guides, Product manuals, Glossary, Reference, Samples に分かれていて、選択すると左側にコンテンツがツリーで表示される。 特によく使うであろうリファレンスはこちら Docker CLI コマンド Dockerfile reference Dockerコンテナを起動・実行する コンテナを生成して起動する Dockerイメージからコンテナを作成して、指定したプロセスを起動する。 Dockerイメージは、ホスト内にあればそれを使い、なければ設定されているReposityからPullする。 docker create -> docker start をまと

    Docker再入門 - Qiita
  • Go + gRPC でC言語プロジェクトのビルドを早くした話 - Qiita

    この記事は Go2 Advent Calendar 2018 の 24 日目の記事です。 私は組込ソフトエンジニアで、職場にはレガシーな環境が多く残っています。 そして、ビルドツールが古かったりして 2MB にも満たないバイナリを作るのに数十分かかったりしています。 時間がかかる主な理由は、複数 CPU による分散コンパイルが実現されてない(場合が多い)から、です。 ということで、 Go 言語の goroutine を用いて CPU をなるべく使う形のタスクランナーを書くことが多いわけですが、最近は gRPC 経由で複数のマシンを活用する分散ビルド環境を作っているのでまとめました。 動くサンプルを紹介しつつ、徐々に分散ビルドになるように段階的に進めていきます。 分散処理のイメージ 実際に仕事で使っているプロジェクトの分散 build は以下の画像のようになります。 1 CPU で普通にビル

    Go + gRPC でC言語プロジェクトのビルドを早くした話 - Qiita
  • エラー画面やAPIエラーから独自エラーまで! フローチャートでちゃんと理解するLaravelの例外処理とケーススタディ - Qiita

    エラー画面やAPIエラーから独自エラーまで! フローチャートでちゃんと理解するLaravelの例外処理とケーススタディPHPLaravelexceptionlaravel5.5 TL;DR Laravel 5.5 ベース(Laravel 5.7 まで対応) フローチャートでおおまかな処理の流れと、どこでどんなことをするのかを解説します それを踏まえて「こんな時はこうする」というケーススタディを紹介 中小規模のプロジェクトにはそのままコピペで使ってもらえるベストプラクティス的なものを目指しています 実際にこれをベースにしたものが中規模業務アプリに実装されています バリデータ編もあります。 → フロー図で理解するLaravelバリデータの仕組みと、チーム開発でのケーススタディ 動機 個人的にエラー処理の仕組みを理解するために書いたチャートです 自分で勉強しようとしたとき、Laravelのエラー

    エラー画面やAPIエラーから独自エラーまで! フローチャートでちゃんと理解するLaravelの例外処理とケーススタディ - Qiita
  • クリーンアーキテクチャの書籍を読んだのでAPIサーバを実装してみた - Qiita

    はじめに クリーンアーキテクチャの書籍を読んだので、実際にクリーンアーキテクチャの考え方を採用したREST APIGO言語で実装してみた。 ↓↓↓↓ソースコード↓↓↓↓ https://github.com/yoshinorihisakawa/sample-api-hoop/tree/develop この記事ではクリーンアーキテクチャの説明というよりかは、実装ベースの実践的な内容にしている。 対象読者 ・クリーンアーキテクチャで実装されたソースコードを理解したい人 ・クリーンアーキテクチャの右下の図がよくわからない人 ・アーキテクチャについて勉強を始めた初心者 クリーンアーキテクチャとは? クリーンアーキテクチャとは、8th Light, Inc.のブログ記事で提案されている。 一言で言うと、依存関係をコントロールし持続可能なソフトウェアを実現するための体系的な手法である。 ※ DIやD

    クリーンアーキテクチャの書籍を読んだのでAPIサーバを実装してみた - Qiita
  • キズナアイとねこますの声を入れ替える機械学習をした - Qiita

    最近バーチャルユーチュ-バーが人気ですよね。自分もこの流れに乗って何か作りたいと思い、開発をしました。 モーションキャプチャー等を使って見た目を変えるのは かなり普及しているっぽいので、自分は声を変えられるようにしようと開発しました。 やったこと キズナアイさんとねこますさんの、それぞれの声を入れ替えられるようにしました。これによって、ねこますさんのしゃべった内容を、キズナアイさんの声でしゃべらせることができます。(逆も) 機械学習手法の一つであるCycleGANを用いて、変換するためのネットワークを学習しました。 パラレルデータ(話者Aと話者Bが、同時に同じ内容を話した音声)が必要ありません 。YouTubeから拾った音声でも変換ができます。 当然ですが、一度学習すれば、利用時には何度でも繰り返し利用できます。 期待できる効果 見た目だけでなく、声まで美少女になれます。やったね。 他にも

    キズナアイとねこますの声を入れ替える機械学習をした - Qiita
  • 【今日からできる】コミットメッセージに 「プレフィックス」 をつけるだけで、開発効率が上がった話 - Qiita

    はじめに 今まで commit message を「なんとなく」書いていたが、プレフィックスをつけることで、コミットメッセージに対する考え方が変わった。 そのおかげで開発効率が上がったので、その内容をシェア。 プレフィックスをつけるってどういうこと? 以下のようにコミットメッセージの先頭に、なんらかの文字をつけること。 feat: xxx という機能を追加 fix: yyy で発生するバグを修正 refactor: zzz の機能をリファクタ のように feat, fix, refactor などがプレフィックスです。 最近 OSS の Contribution Guide などでよく見かけます。 導入したプレフィックスルール Angular.js/DEVELOPERS.md Angular.js の開発者ガイドに書いてあるメッセージを参考にしました。 以前のコミットメッセージ(例 ちなみ

    【今日からできる】コミットメッセージに 「プレフィックス」 をつけるだけで、開発効率が上がった話 - Qiita
  • 実践テスト駆動開発(GOOS)読んだ - Qiita

    実践テスト駆動開発を読んだ(和智さんいい仕事、ありがとう!)。 タイトル(GOOS = "Growing Object-Oriented Software, Guided By Tests")に、「テスト(TDD)」と「オブジェクト指向(Object-Oriented)」と「育てる(Growing)」が入っていて、ずっと読まなきゃと思っていた。出たときに角谷さんに「これは!」、と薦められたのに、機会を失っていたけど、最近、astahの開発でテストに悩みがあって読んでみた。 外から攻めるか、内からか テストを書いてプロダクトコードを育てていくという話なのだが、内側のテスト(ユニットテスト)と外側のシステムテスト(受け入れテスト、システムテスト、エンド・トゥ・エンド(E2E)テスト)をどっちを先に書くべきかいつも悩む。外側のテストを書いて、内側に進んでいくのか、内側から組み上げるか。設計の方向

    実践テスト駆動開発(GOOS)読んだ - Qiita
  • はじめてドメイン駆動設計をしてみて感じたこと - Qiita

    この記事はCrowdWorks Advent Calendar 2017の4日目の記事です。 はじめに 今年CrowdWorksにエンジニアとして新卒入社した@kinakoboです。CrowdWorksでは10月から新たな試みとしてドメイン駆動設計(DDD)を実践しています。 DDDを実践するに至った経緯は、サービスの規模拡大に伴いアプリが肥大化し、技術的負債が増えてきたことで、機能追加をスピーディーに進めづらくなってきたからです。 今回実装しようとしている機能を今まで通りRuby on Railsを利用して実装することは可能ですが、変更に強い柔軟なサービスにするためにもDDD+Scalaで実装し始めています。 DDD未経験の状態から2ヶ月実践してみて、まだ道半ばですが感じたことを書きます。同じような課題感を持っている方の参考になれば幸いです。 エヴァンスに挫折したら・・・ DDDと言え

    はじめてドメイン駆動設計をしてみて感じたこと - Qiita
  • テストがなかった無法地帯にテストを導入して開発速度を1.7倍にした話 - Qiita

    テストがなかった無法地帯のプロジェクトに自動テストを導入して、開発速度を1.7倍にした話をします。 自動テストがなぜないのか 自動テストのないプロジェクトには、そうなる理由が必ず存在します。よくみる理由は、「時間がないから1」「テストの書き方がわからないから」「無理やりテストを書いたつらい経験があったから2」といったものです。今回のプロジェクトの場合は、以下の2点でした: 自動テストの書き方がわからないから レビューがテスト代わりだったから まず、チーム編成が変わって私ともう一人がチームに加わるまで、実装者の中に自動テストの経験者はいませんでした。このような状況では、自動テストは困難になります。なぜなら、何をどうやってどこまでテストするかを決めるには、多少の慣れが必要だからです。この慣れがないと、何をしたらいいかわからないという状態に陥りがちで、結果として自動テストが後回しにされてしまいま

    テストがなかった無法地帯にテストを導入して開発速度を1.7倍にした話 - Qiita
  • PHPでDDD実装事例(クラス図、コードレビューでの指摘ポイント有り) - Qiita

    追記 1.一意な識別子を生成するnextIdentity()メソッドの実装を追記しました 2.ReservationServiceクラスを修正しました (リファクタリング、Customerクラス追加) 3.続編では無いですが、その②を書きました。 PHPでDDD実装事例その②リポジトリ&ファクトリで永続化・生成処理をカプセル化(Laravel)(図あり) 背景 自分が運営しているハウススタジオの予約受付業務の自動化システムを、今学習しているDDD風に設計して、YYPHPにてコードレビューしてもらったので、 ・前提となる業務の内容 ・業務ルール ・クラス構成(クラス図) ・設計の考え方 ・実装コード ・レビューでの指摘ポイント あたりを共有しようと思います。 未熟な部分もあると思います。 この記事を読んで改善点などあれば是非是非コメント下さい! 言語はPHP、フレームワークはLaravel

    PHPでDDD実装事例(クラス図、コードレビューでの指摘ポイント有り) - Qiita
  • 布団から腕すら出さずに会社を休む [Google Home] - Qiita

    時は遡ること1年前… 以前、こんな記事を書きました。 会社が休みになるボタンを作ってみた [Amazon Dash Button] しかし、この Amazon Dash Button をハックした方式では以下の問題点がありました。 同ネットワーク内にサーバを立てておく必要がある ハック的な使い方をしているため、動作不安定 目を開ける必要がある ボタンを押す動作すら面倒くさい ノールックでボタンを押そうとするとボタン(半休/全休)を間違える そのくらい我慢しろや!という項目もありますが、 やはり運用していく上で一番面倒だったのは、自サーバをローカルに立てておく必要がある点でした。 ネットワークに流れる ARP パケットをイベントのトリガーにする仕組みなので、 サーバをクラウドへ持っていくことができなかったのです。 (あくまで、一般向けの Amazon Dash Button をハックして利用

    布団から腕すら出さずに会社を休む [Google Home] - Qiita
  • Linus Torvalds氏によるGitの内部構造の解説 - Qiita

    初めに LinusによるGitのinitial commitのREADMEの訳です。 社内のSVNからの移行を促すために資料を整備していたのですが、SVNでやっていたことを移し替えたりコマンドを覚えたりするより内部構造を知ったほうが早いことに気づきました。 それで、gitの内部構造についての解説資料を色々見ていたのですが、データ構造については原作者のこのREADMEに言い尽くされている気がします。のみならず、gitを使うものが抱くべき精神性のようなものが示されており、深い感銘を覚えました(ヒャッハー)。 README: ”GIT - 馬鹿コンテンツトラッカー” コミットメッセージ:git, 地獄からきたインフォメーションマネージャ gitの意味 "git" は何を意味することも出来る、お前の気分次第だ。 3文字で、発音可能で、実際のUNIXシステムで共通コマンドとして使われていないものであ

    Linus Torvalds氏によるGitの内部構造の解説 - Qiita
  • メモリリーク、デッドロック、リダイレクトループ、JVMクラッシュ...バグだらけのWebアプリケーションを使ってバグを理解する - Qiita

    メモリリーク、デッドロック、リダイレクトループ、JVMクラッシュ...バグだらけのWebアプリケーションを使ってバグを理解するJavaバグ脆弱性トラブルシューティングjconsole 概要 Webアプリケーションの開発や保守をしていると、いろいろなバグに遭遇します。メモリリーク、デッドロック、リダイレクトループ、JVMクラッシュ等々、バグは様々です。こういったバグは、実際にコードを書いて、実行・再現させてツールで解析してみると理解が深まります。 ということで、いろいろなバグを実装したWebアプリケーションをつくってみました。現時点では、以下を簡単に再現できます。 メモリリーク (Javaヒープ領域) メモリリーク (Permanent領域) メモリリーク (Cヒープ領域) デッドロック (Java) デッドロック (SQL) 完了しないプロセスの待機 無限ループ リダイレクトループ JVM

    メモリリーク、デッドロック、リダイレクトループ、JVMクラッシュ...バグだらけのWebアプリケーションを使ってバグを理解する - Qiita
  • Pandoc で Windows に作るmarkdown to html, docx 環境 - Qiita

    Pandoc のインストール github pandoc から最新版の Pandoc-x.yy.z-windows.msi をダウンロード。 Pandoc-x.yy.z-windows.msi をインストール。 システム環境変数 Path に 「C:\Users\UserName\AppData\Local\Pandoc」を通す。(※UserName は現在のログインユーザ名) 基コマンド

    Pandoc で Windows に作るmarkdown to html, docx 環境 - Qiita
  • GitHub APIから学ぶ次世代のAPI実装方式GraphQL - Qiita

    最近公開されたGitHubAPIは、GraphQLという形式に対応しました。今後はこちらが主流になっていくようで、既存のREST APIからGraphQLへのマイグレーションガイドも提供されています。 今回は、このGraphQLについて、実際にGitHubAPIを叩きながらその仕組みを解説していきたいと思います。 GraphQLとは 歴史 GraphQLは、Facebookの中で2012年ごろから使われ始めたそうです。その後2015年のReact.js Confで紹介されたところ話題となり、同年"technical preview"のステータスでオープンソースとして公開されました。その後仕様が詰められ、2016年9月に晴れて"preview"を脱し公式実装として公開されました。これと同じタイミングで、GitHubからGraphQLバージョンのAPIが公開されています。 このあたりの経緯

    GitHub APIから学ぶ次世代のAPI実装方式GraphQL - Qiita
  • オブジェクト指向の法則集 - Qiita

    この記事は、故石井勝さんが1999年に書いた記事を Qiita に転載するものです。オブラブ(objectclub.jp)にて記事をホスティングしていましたが、現代でも十分に読める内容なので、たくさんの方に読んでもらいたいと思い、若干の編集(リンクとコンテキスト追加)を平鍋が行い、転載します。今でも、読みやすく、カジュアルな語り口のよい記事です。 オブジェクト指向の法則集(転載元:http://objectclub.jp/community/memorial/homepage3.nifty.com/masarl/article/oo-principles.html ) なお、この記事の他にも石井さんのオブジェクト指向やRubyに関する多くの記事をオブラブの「まさーるのページ」で読むことができます。では、以下に石井勝さん(旧メールアドレス masarl@nifty.com)の記事を転載します

    オブジェクト指向の法則集 - Qiita
  • CORS 対応時の注意点などメモ - Qiita

    同じオリジンのAPIと非同期で通信、という場合は xhr で普通にこなしてますが、別ドメインのAPIと非同期で、となると割とつまづくポイントがあったのでメモ。 こちらのサイトが大変分りやすかったです。 CORSではまったこと http://inside.pixiv.net/entry/2014/12/16/181804 xhr2 を使う 特に何かしなくても、ブラウザがxhr2対応しているものであればxhr2を使うことになります。 逆にいうと、xhr2 対応していないブラウザだとダメ。 とりあえず普通に実装する 特にクロスドメインであることを気にかけず、クライアントサイド、サーバサイドそれぞれをまずは実装します。 Origin 許可する サーバサイドでアクセス元となるOriginを意識して設定する必要があります。 サーバサイドのレスポンスヘッダの追加 クライアントサイドはモダンブラウザなら特

    CORS 対応時の注意点などメモ - Qiita
  • JavaScript,jQueryの爆速コーディング、デバッグ方法論の勧め~実践向け逆引き(windows,chrome向け)~ - Qiita

    JavaScript,jQueryの爆速コーディング、デバッグ方法論の勧め~実践向け逆引き(windows,chrome向け)~JavaScriptjQuery ※2017/4/21にオンロード時のデバッグ方法8を追記しました! こんにちは!エイチーム引越し侍の加藤です! みなさんJavaScript書いてますか? console.logめっちゃ使うよねーって人は目からうろこのデバッグ方法を、 ケース毎に紹介していこうと思います。(僕はconsole.log使いません) サーバーにデバッグ用のコードをアップロードすること無いので、 消さずに意図に反してリリースしてしまう危険性がないのもお勧めです。 前提知識 F12で出てくるデベロッパーツール(Elements, Console, Source, Network)の知識 Ctrl+Shift+Fで外部ソース(js,css)に対して一括検索が

    JavaScript,jQueryの爆速コーディング、デバッグ方法論の勧め~実践向け逆引き(windows,chrome向け)~ - Qiita