Gradle の dependencies で指定する compile, api, implementation についての勉強メモ。 compile は非推奨 Gradle 3.4 で Java Library Plugin が追加されたことで、 dependencies で compile を使用することは非推奨となってたらしい(runtime, testCompile, testRuntime も)。 4.7 の Java Plugin の説明では、ガッツリ Deprecated と書かれている。 （4.6 のドキュメントだと Deprecated って書いてないけど、明確に非推奨となったのは最近？） 代わりに implementation と api を使用することが推奨されている。 compile と implementation の違い compile の場合 実装 |-set

Haskellのデファクトスタンダードな処理系であるGHCには，Haskellの言語仕様を補うような形で，GHC拡張と呼ばれる言語拡張を用意している．これらはちょっとした便利な糖衣構文を用意するようなものから型システムに深刻な影響を及ぼすもの，次期仕様策定までの前準備のものまで様々ある．いくつかの拡張はデフォルトで有効になっている． 言語拡張は，次の3つの方法で制御できる． すべての言語オプションは，コマンドラインフラグ-X ...（たとえば，-XTemplateHaskell）でオンになり、フラグ -XNo ...でオフになる．（たとえば，-XNoTemplateHaskell） GHCによって認識されている言語オプションは，LANGUAGEプラグマ(たとえば，{-# LANGUAGE TemplateHaskell #-})を使用して有効にすることもできる． stack (hpack)

この画像は本家リポジトリのスクリーンショットを引用しています。 現在の最新バージョンは v0.13.0.0 です。この記事は以下のリビジョンで動作確認しています。 λ git clone https://github.com/haskell/haskell-ide-engine --recurse-submodules λ cd haskell-ide-engine λ git rev-parse HEAD 7cf1295a2804a527381331bb7b73d58255721edc v0.13.0.0 の変更点 また、vscode-hie-server の最新バージョンは 0.0.30 です。 haskell-ide-engine のビルド時間めちゃ長い問題について 現状、公式からビルド済みのバイナリは配布されていません。 「Nix で Haskell IDE Engine をシュッ

今DL for NLP界で、BERTというモデルが話題です。PyTorchによる実装が公開されていたので、日本語Wikipediaコーパスに適用してみました。 コードはこちらに公開しております。 2018/11/27 作成したBERTのモデルを使って内部動作の観察とその考察を行いました。単語の潜在表現獲得の部分で感動的な結果を見せてくれました。ご興味あればご覧ください↓ https://qiita.com/Kosuke-Szk/items/d49e2127bf95a1a8e19f この記事ではBERTのポイントの解説と、ポイントごとの実装を紹介します。 尚、記事の執筆にあたってこちらのリポジトリを参考にさせていただきました。 https://github.com/codertimo/BERT-pytorch 本記事は以下の4つで構成されています。 ・BERTとは ・BERTのキモ ・BER

ScalaでDIコンテナというとGoogle Guiceを使っている人が多いと思うけど、僕は最近airframeを使い始めました。 何がどう違うのというのは以下の記事を読んで欲しい。個人的には、Scalaで使うための設計が前提になっているかが大きいと思っています。Guiceでもいいけど、無邪気に使っているとJava前提のライブラリはハマることもあるし、Scalaの独自機能に対するケアもないので…。 使い方はQuick Startを読んでください。たけぞえさんのブログ記事 「Scala用のDIライブラリAirframeを試してみた」 でも紹介されています。1 以上、終了でもよかったのですが、日本語で簡単に解説しておきます。 最低限知っておくとよいのは、Design, Sessionです。あとは、DIコンテナがサポートするLife Cycleはドキュメントをみてください。DesignとSess

Note: JWT の仕様やそもそも論の話は触れません。どう使うか、何が出来るかしか書いていません。 JSON Web Token? JSON Web Token とは、ざっくりいって署名の出来る JSON を含んだ URL Safe なトークンです。 署名とは、署名時に使った鍵を用いて、JSON が改ざんされていないかをチェック出来るようにすることです。 URL Safe とは、文字通り、URL に含めることの出来ない文字を含まないことです。 これだけだとよくわかりませんが、触り心地としては次のような性質があります。 発行者だけが、鍵を使ってトークンが正しいことを検証出来る。 暗号化ではないので、JSON の中身は誰でも見られる。 仕様的には、暗号化のオプションもあります。 しかしながら、JSON の変更は出来ない。（改ざんをすると、検証時に失敗するので。） 全体的には、なんか変更できな

DIを使わない状態ではUserRepositoryというインターフェースが定義されているのにもかかわらず、UserServiceはUserRepositoryImplの参照も持っていました。 これではせっかくインターフェースを分離した意味がありません。 UserServiceがUserRepositoryインターフェースだけを参照(依存)するようにすれば、具体的な実装であるUserRepositoryImplの変更に影響されることはありません。 この問題を解決するのがDIの目的です。 それではDIのインジェクタを加えて、上記のクラス図を修正しましょう。 謎のインジェクタの登場によりUserServiceからUserRepositoryImplへの参照がなくなりました。 おそらくインジェクタは何らかの手段でサービスであるUserRepositoryImpl(Dependency)をクライアン

MailHogについて 簡易SMTPサーバーの１種で開発時のメールテストに活用できます。 Docker Hubでコンテナ公開もされているため 導入も非常に簡単です。 GitHub Docker Hub 今回はあくまで既存dockerプロジェクトにSMTPサーバを追加する形でいきます docker runにて挙動確認をしたい方は配布元のドキュメントを確認してください 導入方法 docker-compose.ymlへコンテナを追記

両者の特徴についてはOur Keycaps - ErgoDox EZにて説明されています。以下に、両者の特徴を引用します。 Blankキーキャップ Blankについては次のように説明されています。 ErgoDox EZ Blank DCS keycaps The professional name for these keycaps is DCS, and they are made by Signature Plastics. There are a few things you should know about them: They are sculptured, which means each row of keys is differently shaped. If you carefully look at the image above, you will see this

継続モナドを使ってPlay FrameworkのActionを作るという話をします。 Play FrameworkはScalaのWebアプリケーションフレームワークであり、Actionはそのコントローラー部分になります。 この記事を読むにあたって継続モナドの知識は前提としませんが、 ある程度のモナドの知識(Scalaのfor構文の使い方、ScalaのモナドがflatMapメソッドで合成できることなど) Play Frameworkの使い方(PlayのActionがどのようなものであるかなど) などの知識は前提とし、説明を省略させていただきます。 話の流れとしては以下のようになります。 コントローラーで継続モナドを使いたい動機 継続モナドとは？ なぜコントローラーで継続モナドを使うと便利なのか？ 継続モナドとFutureを組み合わせることでエラー処理を整理する 継続モナドを使ったAction

概要 以前紹介したバグだらけのWebアプリケーション「EasyBuggy」のDjango 2.0ベースのクローンをつくってみました(「EasyBuggy Django」)。 以下のコマンドでダウンロードから起動までできます。 $ git clone https://github.com/k-tamura/easybuggy4django.git $ cd easybuggy4django/ $ pip install -r requirements.txt $ python manage.py runserver

Figma：https://www.figma.com/ （2019 年 12 月 1 日 ： 古くなって意味消失してた部分を編集しました） Figma とは デザインツール、Figma をご存知でしょうか。 一言で表すならば、コラボレーション機能満載の Sketch です。 本記事を公開した 2017 年時点では、あまり知名度が高くなかったものの、2019 年時点ではだいぶユーザーが増えたように感じます。Google Trends で、Sketch と XD、そして Figma の今と昔を比較してみます。 2017 年 2019 年 （純粋には比較できませんが）2 年前は Sketch と Figma に約 25 倍も開きがありました。ですが現時点では約 10 倍くらいでしょうか。日本ではなんと逆転しています。（タイトルの通り！） そこでもう少し Figma に頑張ってもらうべく、本記事

@see <https://qiita.com/1ed873c7e9a8edd9c695d2fa438cc1ed/items/eeb0b42a1ecbba0c49e3/revisions/13> Register as a new user and use Qiita more conveniently You get articles that match your needsYou can efficiently read back useful informationWhat you can do with signing up

はじめに 設計がしっかりしていないまま開発をしてしまうとビジネスロジックとライブラリが密結合となりがちです。 密結合度が高いほど修正が困難となり、継続的な開発の難易度が上がっていきます。（技術的負債） またプロジェクトが大きくなってくると扱うデータ量も多くなり処理速度もデータ量に比例するため、計算量オーダーの影響を受けます。 プロジェクトのそれぞれの機能に対して 1. 再利用可能 2. テストしやすい 3. 機能追加しやすい 4. ビジネスロジックとライブラリ、REST API（+マスターデータ）を分離できる となっていれば継続的な開発がしやすいです。 最近ではクライアントサイドではクリーンアーキテクチャ、Atomic Design、バックエンドではマイクロサービス化という設計方法があります。 この設計が良いと感じているのはビジネスロジックと機能の責務を分離し、 ライブラリとREST AP

dev.to を見ていたら、 #impostorsyndrome というタグがあり、 #shecoded でもけっこうみんな Impostor Syndrome に苦しんでいたという記述がありました。 調べてみたら、 Impostor Syndrome （詐欺師症候群） に陥っている方は多いんじゃないかと思い、というか自分がまさに当てはまった気がしたので、エンジニアの視点でまとめてみます。 Impostor Syndrome とは wikipedia によると インポスター症候群またはインポスター・シンドローム(英: Impostor syndrome) は、自分の達成を内面的に肯定できず、自分は詐欺師であると感じる傾向であり、一般的には、社会的に成功した人たちの中に多く見られる。 能力の高い人々は、自分が偽物であると人から思われたくないがために、熱心に働く傾向がある。その勤勉さの結果、人

元記事: http://tadeuzagallo.com/blog/react-native-bridge/ 翻訳については https://github.com/januswel/react-native-bridge-ja で管理している。 また、元記事では文字で説明されている部分も含めて実行時の簡単なフローを描いてみた。ここで bundle というのは React Native packager によって bundle されたファイルのこと。 というわけで、以下翻訳。 この投稿では React Native の基礎を知っている方を対象に、ネイティブと JavaScript の通信時における内部の動作へ焦点をあてます。 メインスレッド 何よりも先に、 React Native では 3 つの主要なスレッド1があることを覚えておいてください。 シャドウキュー コンポーネント再配置時に使用

概要 趣味で作るアプリでgRPCを使った通信をしてみようと思い設定した時のメモです。 build.gradleで何を設定する必要があるかについて主に書いています。 Kotlin、SpringBoot、gRPCについては、細かく説明しません。 こちらの設定についてのメモです。 技術選択の気持ち なぜKotlin? Java8のOptionalは手に馴染まない。isPresentとか書くの面倒くさい。 最近周りで流行している。 かわいい。 サイバーエージェントでは、Androidだけでなく、サーバーサイドでもKotlin使っているところがある。(※1　関連資料) なぜSpringBoot? Javaでアプリケーション書く時のデファクトスタンダード(だと思ってる)。 なぜgRPC? 触ってみたいから。 趣味で作るアプリなので使ったことがないものを使いたい。 メルカリのバックエンドでも利用されてい

async/awaitのエラーハンドリングはtry/catchで行うのが一般的です。 しかし、これは複数のawaitを使い、それぞれ別のエラーハンドリングを行いたい場合など、冗長になりがちです。 そして、特に気に入らないのが、tryのスコープ外で非同期関数の戻り値を使う場合、letを使う必要があるところです。

$ kubectl config use-context docker-for-desktop Switched to context "docker-for-desktop". $ kubectl config get-contexts CURRENT NAME CLUSTER AUTHINFO NAMESPACE * docker-for-desktop docker-for-desktop-cluster docker-for-desktop gke_xxxxxxxx_asia-northeast1-a_sasaki-cluster-1 gke_xxxxxxxx_asia-northeast1-a_sasaki-cluster-1 gke_xxxxxxxx_asia-northeast1-a_sasaki-cluster-1 gke_xxxxxxxx_asia-northeast1-

今回から数回（全7回を予定）にわけて、2017/7月リリース予定で2017/5/8にRC1がリリースされたSpring Framework 5.0の主な変更点（新機能や改善点など）を紹介していきたいと思います。 本エントリーは「New Features and Enhancements in Spring Framework 5.0」で紹介されている内容を、サンプルコードなどを交えて具体的に説明していく予定です。（逆にいうと、「New Features and Enhancements in Spring Framework 5.0」にのっていない変更点は紹介しないので、あしからず・・・ ） なお、初回である今回は簡単な概要説明(日本語化+α)にとどめておき、次回から具体的な説明を行っていきます。 トピック 本エントリーでは、Spring Framework 5.0の主な変更点を以下の8つ