タグ

ブックマーク / qiita.com (1,114)

  • RoRやLaravelなどのフレームワークを使ってきた人がScalaを導入した時に引っかかる点とその解決策 - Qiita

    はじめに 僕が代表をしている株式会社KOSKAでは製造業の原価管理をIoTで自動化するGenkanというサービスを提供しております。 そんな弊社では半年前、バックエンドをRoRからScalaに移行したのですが、これが素晴らしく効果が高かったので以下の記事を書きました。 スタートアップである弊社が全員ほぼ未経験でRoRをScalaに移行した理由、その効果と苦労点 しかし、最後に書いたのですが、苦労する点もとても多いです。 弊社CPOが苦労する点を抽象的な部分に関しては以下の記事で書いてくれてはいます。 0からScala番導入して感じたこと・考えたこと - Qiita ただ、実際にコードを書き始めた時に引っかかりやすい点をできるだけ詳しくあげておくことで、導入しようと考えた人がなるべく簡単に導入できるという状況を作りたかったので、書きました。 それではスタートです。 RubyPHP、Py

    RoRやLaravelなどのフレームワークを使ってきた人がScalaを導入した時に引っかかる点とその解決策 - Qiita
  • 『まず触ってみて』Vueで使えるCSSアニメーションまとめ110選!【完全オリジナルだからコピペOK】 - Qiita

    『まず触ってみて』Vueで使えるCSSアニメーションまとめ110選!【完全オリジナルだからコピペOK】CSSアニメーション初心者Vue.jsフロントエンド コピペだけで作れるマテリアルデザインを個ご紹介します。 box-shadow, filter, transform,などをふんだんに使っており、transitionで滑らかな動きが表されています コードには説明もわかりやすく書いてあるのでかなり参考になります Webデザイン初心者の方はもちろんですが、バックエンドエンジニアの方にもとても助かる内容になっています 1. シンプルなスライダーマテリアルデザイン3選 そのまま使えるスライダーアニメーションのマテリアルデザインとなっています transition-durationを使っていてわかりやすく説明もされているのでかなり重宝します 2. filterとopacityを使いこなすスライダー

    『まず触ってみて』Vueで使えるCSSアニメーションまとめ110選!【完全オリジナルだからコピペOK】 - Qiita
  • DIコンテナのテスト以外での利点について (7/15修正) - Qiita

    概要 Martin Fowler氏によってDependency Injection (以下DI) と DIコンテナについての概念が2004年に発表されて約16年。 Java だけでなく JS や Swift、C# と言った様々な言語に実装されてきて基的な設計概念として定着してきた。 だが、DIコンテナの利点、なぜDIコンテナを使うのかという話になってくると テスト容易性をあげる、という話ばかりが多くそれ以外のメリットについて説明されることが少ないと感じてる。 Java開発を変える最新の設計思想「Dependency Injection(DI)」とは DI (依存性注入) って何のためにするのかわからない人向けに頑張って説明してみる そこでこの記事ではテスト容易性の向上以外のDIコンテナのメリットについて書いていきたいと思う。 まぁまぁ長いので面倒だったら結論を先に読むでいいと思う 当初、

    DIコンテナのテスト以外での利点について (7/15修正) - Qiita
  • ご主人様、小難しいDDDやクリーンアーキテクチャはお忘れになって、”削除しやすい設計”から始められてはいかが? - Qiita

    ご主人様、小難しいDDDやクリーンアーキテクチャはお忘れになって、”削除しやすい設計”から始められてはいかが?LaravelDDD設計アーキテクチャCleanArchitecture ある日夢の中で設計に詳しい悪役令嬢が現れてこんなことを言い放ったので、考察してみましたという設定のポエムです。 問題提起 ドメイン駆動設計、オニオンアーキテクチャ、クリーンアーキテクチャといった考え方はもちろん重要なものの、僕は難しく考えずに「削除しやすいように機能を作る」のが第一歩として重要ではないかと考えています。 記事では「削除しやすい設計」について持論を展開してみます。 ※議論のスコープはWebサービスに限定し、例示としてPHPのフレームワークであるLaravelを用います 削除しやすいことがなぜ重要か 一度開発した機能は、それで終わりではなく、改修、改善を繰り返し、そして場合によっては仕様が廃止さ

    ご主人様、小難しいDDDやクリーンアーキテクチャはお忘れになって、”削除しやすい設計”から始められてはいかが? - Qiita
  • めくるめくLinuxカーネルじゃないLinux実装の世界 - Qiita

    EDIT^7: blink と box86、FEX。 EDIT^6: Unikraft 。 EDIT^5: Tilck 。 EDIT^4: コメント。gVisor はすっかり忘れていました!Linuxを拡張するためにLinuxを実装した良い例だと思います。LINE有りましたね。。 SF.netのCVSはもう死んでしまったので除外にしました。。 OSvのバイナリ互換 はPIEであることが要求なので。。といっても世間的にはもうLinux = Debian/Ubuntu で良いですかね。。表現を調整しました。 EDIT^3: Noah忘れてた! EDIT^2: Cygwinは 下書き段階で削ってしまった 。。 qemuを移植したとき に互換性がイマイチだったので。。特殊fdやprocfsの充実ぶりとかを考えると "かなりLinux" と言って良いとは思うけど、 mmap 等でLinuxとWind

    めくるめくLinuxカーネルじゃないLinux実装の世界 - Qiita
    y_yuki
    y_yuki 2020/07/16
  • 【VS Code + Marp】Markdownから爆速・自由自在なデザインで、プレゼンスライドを作る - Qiita

    【VS Code + Marp】Markdownから爆速・自由自在なデザインで、プレゼンスライドを作るMarkdownVisualStudioCodeDraw.ioMarpvega TL;DR Visual Studio Code上で、Markdownから、こんな感じのデッキを生成できるようにします。 使用したファイル類は、GitHub tomo-makes/marp-styles にまとめました。 きっかけ 叩き台となる資料がなく、急ぎプレゼンをする機会があり、Marpで作成した 内輪では使っていたが、多くの目に触れるのは初めてで、もう少しデザインを調整したいと思った 今後も使いまわせるものを、スニペット、およびサンプルテーマ化しておこうと思い立った ついでにいろいろな図表の生成とデッキへの入れ方、必要そうな配色、素材のリンクをまとめておきたい Marpとは Marp: Markdown

    【VS Code + Marp】Markdownから爆速・自由自在なデザインで、プレゼンスライドを作る - Qiita
  • Dockerで未使用オブジェクトを消す「prune」オプションの整理 - Qiita

    概要 Docker で不要なものを消すガベージコレクション(garbage collection )は、prune 系のオプションを使う。 prune 系オプションを使うと、使っていない Docker オブジェクト(コンテナ、イメージ、ネットワーク、ボリューム)をまとめて削除できる。コンテナが停止してからの時間を指定できる --filter "until=24h" の指定で、更に活用しやすくなる。あるいは --filter "until=2020-06-01" のように、日時の指定も可能。 なお「prune」の意味とは、不要なものや余分なものを、削る、刈り取る、取り除くといったもの。 停止して24時間経過したコンテナと、使っていないイメージおよびネットワークを消す $ docker system prune -a --filter "until=24h" ... Are you sure

    Dockerで未使用オブジェクトを消す「prune」オプションの整理 - Qiita
  • 【Vue.js】Composition API時代の便利ライブラリ「VueUse」を使ってみた - Qiita

    Vue Composition API によって Vue.js にも React Hooks のようなロジックの再利用性の高い開発体験がもたらされようとしています。 しかし、まだ「Composition API の良さをわかっていない」という方や「Composition API をうまく利用した書き方がわからない」という方も多いかと思います。 記事では Composition API 時代の便利ライブラリ VueUse を用いた実装例や、 VueUse 自体の実装がどのようなものか紹介します。 Composition API の良さや雰囲気もキャッチアップしていただければ幸いです。 VueUse とは? VueUse は Anthony Fu さん1が中心に開発しているライブラリで、Composition API を用いた便利系関数を数多く集めたライブラリです。 例えば、ブラウザ上のマウ

    【Vue.js】Composition API時代の便利ライブラリ「VueUse」を使ってみた - Qiita
    y_yuki
    y_yuki 2020/06/22
  • AWSサービスのログまとめ - Qiita

    はじめに 業務でAWSの各サービスログを使って、ログ分析基盤を構築することが多く その都度、AWS公式サイトやクラスメソッドさんのDevelopers.IOのお世話になっているので その情報を一覧性のある表にまとめてみました。 ストックついでに、テレずに、ぜひLGTMも(*´ω`) AWSサービスログ一覧 サービス名 取得可否 ログの内容 CloudWatch Logs S3 CloudTrail 公式サイト 参考情報

    AWSサービスのログまとめ - Qiita
  • Nuxt.js+Firebaseの認証・認可を実装した雛形プロジェクトを公開しました - Qiita

    この記事について NuxtとFirebaseを使って、これまでいくつかサービス開発をしていますが、認証/認可の実装はどのサービスでも毎回同じようなコードを書いている気がします。 サービスとしてのコア部分ではないですが、センシティブな部分なのでしっかりと調べながら実装すると結構大変ですよね(毎回時間がかかってしまいます)。 ここ最近のサービスはNuxt +Firebaseで開発することが多く、認証 / 認可のコードベースのTipsが貯まってきたので公開したら需要あったりするのかな? サンプルになりそうなプロジェクト見当たらないし、コアな部分ではないのであまり楽しくないし...。 雛形のプロジェクトとして需要あれば公開します👍 — フジワラユウタ | SlideLive▶️ (@Fujiyama_Yuta) June 7, 2020 自分だけではなく、いろんな人が同じような課題感を感じている

    Nuxt.js+Firebaseの認証・認可を実装した雛形プロジェクトを公開しました - Qiita
  • WEBサーバのTCPコネクション数に上限はあるのか? - Qiita

    はじめに アクセス数がすごい環境は大抵高負荷環境でもあるので対策としてApacheの設定やサーバ構成のセオリーをすぐ見つけられて実際試しても目に見えて良くなります。 アクセス数の多さで起こる問題は実際に負荷をかけてみないと表面化しません。 問題が分かったら設定やパラメータを調整して現状がましになるようにするだけです。 ですが限りあるリソースの中でTCPセッションを十分にコントロールしようとするとすぐ手詰まりです。 WEBサーバがしているやりとりの基礎が足りていないそんな気がしていたのでTCPに目を向けてみました。 行き着いた結果は 待ち受け側とリクエスト側ではボトルネックが違う リクエスト時はTCPのエフェメラルポートが上限 待ち受け時はTCPよりもファイルディスクリプタが上限 になりやすい という良く見かける設定を見直すということになりましたが、どうやってそうなっているのかが今回の成果だ

    WEBサーバのTCPコネクション数に上限はあるのか? - Qiita
  • DDDを意識しながらレイヤードアーキテクチャとGoでAPIサーバーを構築する - Qiita

    今の現場で初めてDDDに触れたので、よく採用されるアーキテクチャとしてレイヤードアーキテクチャを自分で0から実装してみました。 言語もよくセットで採用されているGoを採用してみました。 この記事の目的 0から実装して体系的にDDDとレイヤードアーキテクチャを学ぶ DDDに触れたことがない方にもわかりやすく説明する そもそもDDD(ドメイン駆動設計)とは 要約(引用)すると「ドメインの知識に焦点を当てた設計手法」です。 たとえば電子カルテのシステムを例に取ってみます。 電子カルテには患者情報や手術の予定、入院ベッドの空き具合などの概念があると考えられます。 医療関係者ではないソフトウェアエンジニアは実際につかうユーザー(医療関係者)が直面している問題やドメイン(領域)の概念、事象を理解することが必要です。 それらを理解し、ソフトウェアに落とし込む。落とし込み続けることを実践する開発手法です

    DDDを意識しながらレイヤードアーキテクチャとGoでAPIサーバーを構築する - Qiita
  • サーバーレスの理解とメリット・デメリット(2020年版) - Qiita

    (出典:ガートナー) CNCF(Cloud Native Computing Foundation)におけるサーバーレスの定義 CNCFでは、サーバーレス・コンピューティングのホワイトペーパーを公開しています(2018年)。 ここでは、以下のように定義されています。 A serverless computing platform may provide one or both of the following: Functions-as-a-Service (FaaS), which typically provides event-driven computing. Developers run and manage application code with functions that are triggered by events or HTTP requests. Develop

    サーバーレスの理解とメリット・デメリット(2020年版) - Qiita
  • go generate のベストプラクティス - Qiita

    概要 Go 言語におけるコード生成 (go generate) について、自分の中でベストプラクティスと思えるものが増えてきたので、ここでまとめて紹介してみたいと思います。 2020/05/30 初版 2020/06/03 次の節を追加 マップを元データとするときは要素の出力順をソートする 使用するコードジェネレータのバージョンをモジュールに記録する 2020/06/03 次の資料を公開 go generate 完全入門 (プログラミング言語Go完全入門 質問会 発表資料) wtz.go と time について go generate のベストプラクティスを説明するにあたり、この記事では wtz.go と time の 2 つのライブラリを実例としてとりあげます。 wtz.go は筆者が Go 標準ライブラリの time の Windows ランタイム部分を参考にして作成したもので、 Wi

    go generate のベストプラクティス - Qiita
  • Google社のテクニカルライティングの基礎教育資料がとても良かったので紹介したい - Qiita

    はじめに エンジニアにとって、仕様書などの技術的な文章を書くこと(テクニカルライティングとも言います)は避けて通れません。ただ20年来多くのエンジニアの方々と同僚として接してきて思うことは、エンジニアの方の中には「文章を書く」ということに苦手意識がある方が一定数いるということです。 でもこの「テクニカルライティング」のスキルは、才能というよりは一種の「技能」だと思うんです。ある一定の原理原則を理解して実践を繰り返すことで、必ず一定レベルで習得できるものだと著者は信じています。 もしこのテクニカルライティングの原理原則をまだ体系的に学習したことがない、または過去学習したが改めて再学習したいという方に、お勧めのコンテンツを見つけたのでご紹介します。 https://developers.google.com/tech-writing Every engineer is also a write

    Google社のテクニカルライティングの基礎教育資料がとても良かったので紹介したい - Qiita
  • リーンスタートアップで個人開発の成功率を上げる - Qiita

    失敗してしまう個人開発 趣味個人開発で過去にいくつものプロダクトを作ってきました。 ユーザがたくさんついて、ゆくゆくは収益化したいななどと思いながら作っていましたが、残念ながらどれも一瞬だけ少人数の人に使われるだけで、そのさきを描けずにいました。 「いいアイディアが思いついたからいきなり作り始めた」とか「顧客が不在のままとにかく作ってしまった」とかは個人開発でやりがちです。最初にアイディアや顧客について詰めていなかったために誰にも使われないで終わってしまう、というのはよくある失敗なのではないかと思っています。 趣味の開発や、技術力向上という意味ではそれでもいいのですが、あわよくばビジネスにしていきたいという思いがある時は一旦考え直す必要があるかもしれません。 誰も課題だと感じていない領域を攻めていたり、自分の解決策がユーザにとってお金を払いたいほど魅力的でない場合はユーザを定着させること

    リーンスタートアップで個人開発の成功率を上げる - Qiita
  • すべてのエディタでSQLの自動補完をするためにSQL Language Server(sqls)を作った - Qiita

    sqlsとは sqlsとは、いま私が開発中のSQL用Language Serverです。SQLをエディタで編集するときの支援機能を実装したサーバとなっており、主な特徴は以下です。 Language ServerなのでLSクライアントが存在するエディタであればどんなエディタでも利用可能 SQL編集支援機能 自動補完(テーブル名、カラム名など) 定義参照 SQL実行 複数のRDSMSに対応 MySQL PostgreSQL SQLite3 Language Serverとは Language Server(あるいはLanguage Server Protocol)とは、プログラム言語の開発支援機能をエディタに提供するサーバ、およびその通信内容を規定したプロトコルです。ただしサーバといってもほとんどの場合ローカル内にホスティングしてローカルのエディタと通信をします。 ここでは主題ではないので詳し

    すべてのエディタでSQLの自動補完をするためにSQL Language Server(sqls)を作った - Qiita
    y_yuki
    y_yuki 2020/05/16
  • ESLint v7.0.0 の変更点まとめ - Qiita

    overrides: - files: "*.js" extends: my-config-js - files: "*.ts" extends: my-config-ts のような設定がある場合、eslint lib コマンドは lib ディレクトリ内の *.ts ファイルもチェックします。 なお、eslint lib/** のように Glob パターンを指定した場合は今まで通りに動作しますのでご注意ください。overrides 設定にかかわらず Glob パターンにマッチする全てのファイルをチェックします。 プラグイン開発者へ: あなたが管理するプラグインが *.js 以外のファイルを対象にするルールを提供する場合、recommended設定に overrides を追加すると利用者は便利かもしれません。 動作を元に戻したい場合: 今まで通り overrides 設定にかかわらず *.

    ESLint v7.0.0 の変更点まとめ - Qiita
  • REST APIを簡単にMockできるツールSmopeckの紹介 - Qiita

    はじめに 最近のウェブアプリではバックエンドをREST-APIとして用意し、 フロントエンドはREST-APIから引っ張ってきたデータをReactVueといったフレームワークで描画することが多いと思います。 このようなウェブアプリを開発する際に問題となるのはバックエンドとフロントエンドを並行して開発しにくいということです。バックエンドができなければフロントエンドはどんなデータが来るのかわからず描画できませんし、バックエンドもフロントエンドからどのようなリクエストが来るか決まらないと実装ができません。 そのため、最初にREST-APIの仕様を定めて、その仕様に沿ったモックサーバを作成し、 フロントエンドはバックエンドが完成するまでそれを用いて開発を進めるということが行われます。 さてそのREST-APIの仕様とはどのように記述されるのでしょうか? 1. 自然言語で記述する 一番よくある場合

    REST APIを簡単にMockできるツールSmopeckの紹介 - Qiita
  • SPAのログイン認証のベストプラクティスがわからなかったのでわりと網羅的に研究してみた〜JWT or Session どっち?〜 - Qiita

    SPAのログイン認証のベストプラクティスがわからなかったのでわりと網羅的に研究してみた〜JWT or Session どっち?〜JavaScriptRailsJWT認証React SPAのログイン周りについて、「これがベストプラクティスだ!」という情報があまり見当たらないので、様々な可能性を模索してみました。 いろいろな状況が想定され、今回記載する内容に考慮の漏れや不備などがありましたら是非コメントでご指摘いただきたいです!特に「おすすめ度:○」と記載しているものに対しての批判をどしどしお待ちしております! この記事でおすすめしているものであっても、ご自身の責任で十分な検討・検証の上で選択されてください。 前提 想定しているAPIは、 ログイン外のAPIにはPOST/PUT/DELETEのものがなく、GETのみ GETのAPIにはDBを更新するなどの操作がない とし、そのためログイン外では

    SPAのログイン認証のベストプラクティスがわからなかったのでわりと網羅的に研究してみた〜JWT or Session どっち?〜 - Qiita