Docker for Windowsで快適な環境を得るまでの そこそこ長い闘い
2019年8月更新 2年の間にWindowsでのDocker開発環境が進化したのと 知人より凄い便利な機能を教えてもらったので共有します おさらい 今までの大雑把なおさらいとして Windowsでのサーバ開発はDockerを使えば問題なく出来る （実際私は2016年からWindowsでサーバ開発を行っている） VirtualBoxなどを使い、boot2dockerを使いVM上のLinuxで開発も出来るが Windows10 Pro64bitで Hyper-VをONにして Docker for Windowsで開発するとカッコイイ ただし、WindowsにはBashがないのでシェルスクリプトが実行できない WSLを使いDockerをインストールし、Docker for WindowsのExportを使えば良い ただし、WSLのマウントポイントが /mnt/c/ になっているため、環境変数やs
Kyash Android で UIテストを導入した時の方針 - Konifar's WIP
先日、Kyash のAndroidアプリのUIテストをEspressoで書いてCIで回すようにしました。 ユーザー登録、ログイン、カード登録のテストが、毎晩元気に走っています。 きっかけはKPTです。iOSでログイン直後に発生するユニットテストでは気づけない問題が見つかり、 Problem として上がってきました。 テストケースを15項目くらいSpreadSheetにまとめていて大きなリリースの時は手動で確認していたのですが、なぜか「今回はやらないで大丈夫」と判断した時に限ってバグが発生するんですよね。また、手動のテストケースはミスや形骸化しやすいので、 Try としてテストケースの一部を自動化してみることにしたのでした。 Espressoでテストを書く時は、@sumio_tymさんの素晴らしい資料があるので、下記2つを読んでおけば間違いないと思います*1。 DroidKaigi2017
Gradle のマルチモジュールプロジェクトで JaCoCo の結果を集計する - ひだまりソケットは壊れない
Java / Kotlin のコードカバレッジツールとして JaCoCo を使いたい。 Gradle のマルチモジュールプロジェクトでの JaCoCo の導入について記す。 (この図は JaCoCo によるコードカバレッジの集計結果の履歴を Codecov で表示した例。) JaCoCo について JaCoCo は、JVM 言語のコードカバレッジツールである。 Java Agent によるオンザフライ方式のバイトコード instrumentation によるカバレッジ計測が可能である。 以前、Kotlin のコードカバレッジツールについて書いたので、こちらも参考にどうぞ。 Java (JVM 言語) におけるコードカバレッジの計測方法 - ひだまりソケットは壊れない Gradle プロジェクトで JaCoCo を使ったカバレッジ計測を行う Gradle の JaCoCo プラグインを使うこ
そのアプリ、本当に MVI が必要？ - @numa08 猫耳帽子の女の子
久々に技術っぽいポエムを。 Qiita で Android の MVI アーキテクチャについての記事を書いている。 qiita.com 思ったよりも大作になってきて、ちょっとどこから編集を追記すれば良いのかなという気持ちになっていたりするのだけれど、ぼちぼち作っていきたい（また書籍化したい・・・？）。 さて、 この Qiita の記事を書くきっかけはあるプロジェクトの中で MVI アーキテクチャを採用しませんか？ということになったため。練習レベルで MVI アーキテクチャや iOS の Reactor Kit を使ったコードを書いたことはあるけれど、ちゃんとプロダクトで使ったこともないし、人に説明ができる感じでもないなという状態だったため、今一度自分のスキルセットを確認しようと思い筆を執った次第。 で、コードを書いていて思ったのだけれど全部が全部 MVI っぽい感じのコードにはならない。ま
ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か[DDD] - little hands' lab
DDD連載記事 背景・前提 なぜDDD初心者はググリ出してすぐに心がくじけてしまうのかの記事で、 ネット上の文献で紹介されるアーキテクチャが様々なものとなっているのです。IDDDではヘキサゴナルアーキテクチャというものが掲げられていましたが、それを進化させたオニオンアーキテクチャ、クリーンアーキテクチャなどの有名な亜種が存在します。 これが実装に着手する際に非常に大きな混乱を呼ぶのです。文脈の理解、採用するアーキテクチャの選定に時間を取られることでしょう。 と書きました。こちらに対して、私が「一番とっつきやすい」と考えるアーキテクチャを紹介します。 前提としてですが、完全に個人的な経験に基づく私見になります。 DDDの理論の中で、アーキテクチャに関しては「エリック・エヴァンスのドメイン駆動開発」(以下原典)と実践ドメイン駆動開発(以下IDDD)とでも異なったものが紹介されており、唯一の正解
![ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か[DDD] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/ed125204d89ae253a4ab2a6c711eff21748ee9c7/height=288;version=1;width=512/https%3A%2F%2Fqiita-image-store.s3.amazonaws.com%2F0%2F30489%2F81fcfd95-2ce1-82a8-db69-8618338a5f22.png)
クリーンアーキテクチャの書籍を読んだのでAPIサーバを実装してみた - Qiita
はじめに クリーンアーキテクチャの書籍を読んだので、実際にクリーンアーキテクチャの考え方を採用したREST APIをGO言語で実装してみた。 ↓↓↓↓ソースコード↓↓↓↓ https://github.com/yoshinorihisakawa/sample-api-hoop/tree/develop この記事ではクリーンアーキテクチャの説明というよりかは、実装ベースの実践的な内容にしている。 対象読者 ・クリーンアーキテクチャで実装されたソースコードを理解したい人 ・クリーンアーキテクチャの右下の図がよくわからない人 ・アーキテクチャについて勉強を始めた初心者 クリーンアーキテクチャとは？ クリーンアーキテクチャとは、8th Light, Inc.のブログ記事で提案されている。 一言で言うと、依存関係をコントロールし持続可能なソフトウェアを実現するための体系的な手法である。 ※ DIやD
「スマホ見ながら運転」自転車ではね男性死亡 : 社会 : 読売新聞（YOMIURI ONLINE）
茨城県つくば市の県道沿いの歩道で６月、歩行者の団体職員男性（当時６２歳）が、無灯火のマウンテンバイクにはねられて死亡する事故があり、県警が、運転していた同市の男子大学生（１９）を重過失致死容疑で水戸地検土浦支部に書類送検していたことが２３日、捜査関係者などへの取材でわかった。大学生は事故直後、男性宅を訪れて妻（６２）に謝罪し、スマートフォンを見ながら運転していたと説明したという。 県警の発表によると、事故は６月２５日午後８時４５分頃に発生。男性は正面から来たマウンテンバイクにはねられて頭を強打し、２６日未明に死亡した。マウンテンバイクにはライトが取り付けられていなかった。 男性の妻が大学生や県警から受けた説明によると、事故当時、大学生は両耳にイヤホンをつけ時間を確認しようとスマホを操作しており、進路前方にいた男性に気付かなかったという。
“1000回遊べるRPG”を4000回遊んだ男 「SFCトルネコの大冒険」に挑み続けるプレイヤーが語る「不思議のダンジョンには、まだ不思議がある」
1993年に登場したスーパーファミコン用ソフト「トルネコの大冒険 不思議のダンジョン」（チュンソフト／現スパイク・チュンソフト）。2018年に25周年を迎えるレトロゲームではありますが、遊んでいた方は今でも、あのキャッチコピーを覚えているのでは？ 「1000回遊べるRPG」 主人公トルネコが挑む「不思議のダンジョン」は、入るたびにダンジョンの形状が変化。また、いくらレベルを上げても、地上に戻るとレベル1に戻ってしまうという不思議な性質がありました。これらのゲームシステムのおかげで、何度でも新鮮な気持ちで遊べることから、「1000回遊べるRPG」というコピーが採用されていました。 一見、大胆と思えるこの表現、実際には“謙虚すぎた”かもしれません。というのも、今回取材した秋川さんは、同作を実機で4000回以上プレイ。現在もダンジョンに潜っては、Web上にプレイ日記を公開しつづけています。しかも
Androidエンジニア デザイン部 ＃2でありがたいUIへの思いをぶつけました | 山田航空ネットワーク2nd
表題のとおりです。本日は台風で早期の帰宅許可が出たこともあり、代わりにこの記事を書いています。 ちなみに当日は余裕をもって現地に到着して資料を修正しようと思ったら乗るバスを間違えてしまい、最終的にやや遅刻で到着するハメになりました。バス1本遅れることになっても、ちゃんと確認、しよう！ Androidエンジニア デザイン部 #2 - connpass 話した内容に関しては、すごいちゃんと噛み砕いてまとめてくださった記事があるので発表資料とともに紹介しつつ、この記事では当日話さなかった補足部分などについて書きます。 ありがたいUIをもっと大事にしたい - Speaker Deck Androidエンジニア デザイン部 #2に行ってきました | achanBlog Getting Over It with Bennett Foddy 左からPC、iOS、Android版の周回数です。最近ベストタ
怖くない！コンテナ初心者に送るやさしいKubernetes入門
OpenStack Days Tokyo 2018/Cloud Native Days Tokyo 2018で発表させていただいたスライドです。
空自F-2欠陥機論の顛末 大きく騒がれた主翼のヒビ、貧弱レーダーは結局どうなった？ | 乗りものニュース
空自F-2戦闘機は開発中、繰り返し何度も欠陥機であるという報道がなされましたが、実際に部隊配備がなされたのちは、そのような声もピタリと収まりました。あれほど騒がれた欠陥は、結局どうなったのでしょうか。 後継機が話題のF-2、開発当時は欠陥機だった？ 2018年現在、航空自衛隊が保有する戦闘機はF-4、F-15、F-2、F-35の4機種が存在します。このうちF-35はまだ戦力化されていないため、最も新しい機種は2000（平成12）年に配備が開始された国産のF-2となります。 急旋回する試作機カラーが施されたF-2 試作2号機。強度不足から高G旋回ができないともされるがデマである（関 賢太郎撮影）。 昨今ではF-2後継機の開発に関する報道が相次いでいますが、実際に代替されるのは2030年代から2040年代頃になるはずであり、F-2は少なくとも今後20年以上、貴重な航空戦力として日本の防空の一端
FluxにはModelがないのではないかと思った覚書 - ナカザンドットネット
Fluxを使い始めると「おっ、MV＊に比べて頭が悪くても状態が壊れないぞ？」という感想になる人が多いと思うんだけど、その理由がふたつあるような気がしてきた。 ModelやViewModelについてはコンテキストが違う人から「それ違くない？」と言われそうな書き方になるかもだけど、思いつきを書きなぐってるだけなので勘弁してください。 1. 単方向データフローが分かりやすく、コードの複雑さの低下に寄与している これは全くポジティブな要因。 2. FluxはMV＊のModel相当の要素が図に含まれていないので考えることが減った MV＊は「Modelって書いてあるからには何かをModelと呼んでデータを突っ込まなきゃいけない」という意識が生まれやすかった（その責務分割が適切だったかは別として）と思う。 でも、FluxにはStoreとかいうViewModel*1みたいなものしかない*2と私は思っていて
FluxのStoreがViewModelかって話からのMVWとかどうでもいいって話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
StoreがViewModel相当かどうかってことそれ自体はたぶんあんま本質じゃないんだけど。 blog.nkzn.info これについてです。 わかる。StoreがViewModelってのはちょっとだけ違和感あって、ぼくは ViewModelが読むためのクエリ用モデルくらいに思ってるけど、どちらにせよクリーンアーキテクチャ的な考えで言う「外側」のものだよねという点ではたぶん認識一致してると思う https://t.co/IMQADHGwUb— 猫型🐱蓄音機 (@shinpei0213) 2018年5月15日 べつにStoreが ViewModel相当なのかクエリモデル相当なのかってのはじつはどうでもよくて、あのクリーンアーキテクチャの同心円の外側に位置するものだってことがたぶんこの記事の本質。で、クリーンアーキテクチャは同心円の層の数を定義してなくて、— 猫型🐱蓄音機 (@shinp
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
