タグ

開発に関するrightgo09のブックマーク (126)

  • もっと使いやすいコマンドラインツール10選

    背景 ls、cd、psなどのコマンド。 いずれも30年前のもので、今でも毎日使っていますが、"オープンソースの世界には、これらの「古い」Linuxコマンドに代わり、より優れたコマンドラインツールがあるのだろうか?"と思いました。 記事では、Linuxのコマンドと同じことができるだけでなく、より使いやすいパラメータ、一目でわかる表示、クロスプラットフォーム対応など、使い方、パフォーマンス、表示の面でより優れた新機能を追加したオープンソースのコマンドラインツールを10個まとめてみました。 1. dust(du) 開発言語: Rust Github: https://github.com/bootandy/dust スター数: 4.4k 代替コマンド: du 使用方法: dust プラットフォーム: WindowsLinuxmacOS 説明: ディレクトリやファイルのサイズを一目でわかるよ

    もっと使いやすいコマンドラインツール10選
  • フロントエンド開発のためのセキュリティ入門

    Developers Summit 2023 10-A-4 「フロントエンド開発のためのセキュリティ入門」の発表資料です。 https://event.shoeisha.jp/devsumi/20230209/session/4176/ 「HTTPS化」「CORS」「XSS」「脆弱なライブラリのチェック」について説明しています。

    フロントエンド開発のためのセキュリティ入門
  • わかりやすいシステム構成図の書き方 - Qiita

    わかりにくいシステム構成図とは こんなシステム構成図を書いてないでしょうか? このシステム構成図のわかりにくい点が3つあります。それは 製品名は書いてあるが「役割」が書いていない データと処理が区別できない データの流れと制御の流れが区別できない の3つです。 わかりやすいシステム構成図 これら3つのわかりにくい点を改善したわかりやすいシステム構成図が↓です ポイントを解説していきます ポイント1. 製品名称ではなく「役割」を書く システム構成図には製品名称ではなくシステムコンポーネントの「役割」を書きます。 役割とは、例えば〇〇データや〇〇処理といったことであり、それを読むだけでシステムの動きを理解できる文字列です。役割をかかずに製品名称のみを書いてしまうと、その製品を知らない人が見たときに理解できません。例えば「Cloud Pub/Sub」という製品はGCPというパブリッククラウドの分

    わかりやすいシステム構成図の書き方 - Qiita
  • 見通しの悪いコードができあがってしまう、その理由 - Magnolia Tech

    クソコードができあがるのは「影響の及ぼすコンポーネント量を最小にする」という個別最適の価値観が支配的になった時、です 影響の及ぶ範囲を小さくするために、巨大で複雑なコードの塊を一箇所に追加し始めたりするのです そうした方が関心の範囲が限定できるから...だけど、全体最適ではない— magnoliak🍧 (@magnolia_k_) 2022年3月12日 でも悪気はないんです 真面目に巨大で見通しの悪いコードを作り上げていくけど、影響範囲が最小になる方が常に正しい、という価値観は「わかりやすい」んですよ— magnoliak🍧 (@magnolia_k_) 2022年3月12日 「変更量が最小になる」「影響が最小になる」...目の前のタスクをこなすためには、それが一番良いことに見えるんですよね でも、「継続的に同じペースが保てるか?」「スケールするか?」というと、そんなことは無いけど、そ

    見通しの悪いコードができあがってしまう、その理由 - Magnolia Tech
  • Amazon SQSとShoryukenを使ったバックグラウンド処理を検討してみる - ユニファ開発者ブログ

    Webエンジニアのほんまです。 弊社ではインフラの管理コストを極力減らすため、AWSのマネージドサービスへの利用を推奨しています。(例:RDS -> Aurora) その中の一つに「バックグラウンドジョブに使うキューストアに Amazon SQS を使う」というものがあります。 SQSを使うことで急な負荷増減やデータ消失への対応といった悩ましい問題から解放されます。 Ruby on RailsAmazon SQSをストアとするバックグラウンドジョブフレームワークだと Shoryuken がよく使われている印象です。 今回、Amazon SQS と Shoryuken でバッググラウンド処理を動かす方法、そして番運用を見据えて検討が必要な事項を調査したのでシェアしたいと思います。 動かしてみる キューの作成 Railsアプリケーションの作成 ワーカープロセスの起動 エラー処理の確認

    Amazon SQSとShoryukenを使ったバックグラウンド処理を検討してみる - ユニファ開発者ブログ
  • Laravel+Nuxt.jsでDocker開発環境構築からHerokuデプロイまで - Qiita

    はじめに 記事では「フレームワークをインストールして、それをインターネットに公開する」という0から1までのフェーズについて、Laravel+Nuxt.jsによって「蔵書管理」システムを構築して解説したいと思います。 また、実際に構築したシステムは下記になります。 - Heroku: https://frozen-castle-47874.herokuapp.com/ - Github: https://github.com/kon-shou/bcm-qiita-example 目次 システムアーキテクチャ Laravel/Nuxt.jsインストール Docker環境構築 Nginx設定 Typescript対応 サーバーでのモデル/ビジネスロジック実装 フロントでのモデル/ビジネスロジック実装 Heroku設定 システムアーキテクチャ 下記の技術スタックを用います。 サーバーサイド: L

    Laravel+Nuxt.jsでDocker開発環境構築からHerokuデプロイまで - Qiita
  • 責任ある開発者のためのHTTPヘッダー | Yakst

    安全で、誰にも手頃でアクセスしやすく、ユーザーを尊重したWebを作るためのHTTPヘッダーのプラクティス [UI/UX]原文 HTTP headers for the responsible developer - Twilio (English) 原文著者 Stefan Judis 原文公開日 2019-04-23 翻訳依頼者 翻訳者 meiq 翻訳レビュアー doublemarket msh5 原著者への翻訳報告 1821日前 メールで報告済み 編集 This article was originally published on twilio.com, and translated with the permission of Twilio and the author. 当記事の原文はtwilio.comにて公開されたものであり、Twilio社および原著者の許可を得て翻訳しています

  • Webアプリケーションのベンチマークをとるときに気をつけている10のこと - たごもりすメモ

    10もないかも、と思いながら項目を書き出してみたら10以上余裕であってキリがないので10で収めた。いやあ、あるなあ。 仕事柄よくベンチマークを実行したりしてて色々と思うところが溜まっていたところ、以下のような記事を見掛けたのでなんか書こうと思った。ところでこの記事はベンチマークを実行するための準備作業がループを回して2時間かかるところの待ち時間に書かれている。 sfujiwara.hatenablog.com ISUCONといえば多少縁があるコンテストで、文中でISUCON5のことについても言及されているので、それも含めて。 自分が業務でいじっているのは "Webアプリケーション" というとちょっと違うんじゃないのというものばかりだが、いやー、最近なんでもHTTPで外部APIを作るからベンチマークのコツとしては大体変わんなかったりするよね。 なおこの記事でベンチマークはどのようなものかとか

    Webアプリケーションのベンチマークをとるときに気をつけている10のこと - たごもりすメモ
  • ECSのバックエンドをEC2からFargateに変更するにあたり知っておくとよさそうな事 - コネヒト開発者ブログ

    こんにちは。インフラエンジニアの永井(shnagai)です。 これまでEC2バックエンドでECSを運用してきたが、Fargateを採用するにあたり、EC2バックエンド時と比べた差分についてまとめてみました。 内容は、ざっくり下記5項目について。 NW(awsvpc) タスク定義 サービス AutoScalling メトリクス/ログ Fargateをやってみたというのは出たての頃にやったので、今回は番運用を考えるにあたり知っておいたほうがよさそうな点についてまとめてます。 tech.connehito.com NW(awsvpc) アーキテクチャ的に一番大きく変わるのは、NWの部分だと思う。 EC2上で、タスクを動かすときはデフォルトだと「bridge」が指定されるので、ホスト経由で外部と通信を行っていた。同一タスク(コンテナのリッスンポートが同じもの)を効率的にEC2上で動かすために、動

    ECSのバックエンドをEC2からFargateに変更するにあたり知っておくとよさそうな事 - コネヒト開発者ブログ
  • 「Vue.js + Go言語 + PAY.JP 」でクレジットカード決済できるWEBアプリケーション実装ハンズオン - Qiita

    そろそろカード決済の実装経験しとくかと思い、PAY.JPを眺めたらかなりドキュメントが充実してたので使いやすかった。今後、カード決済するサービスを作るのを見越して決済サービスをgRPCでマイクロサービス化してみた。そのまま Vue.js と Go言語を使い、カード決済できるWEBサービスのサンプルを試しに作ってみた。その実装を簡略化してハンズオン形式で紹介します。 全コードは GitHub にあげてます。 (こちらの画像は僕がVue.js+Goで作ったサービスで運用されています。https://ghlinkcard.com/) 得られるもの Vue.js + Go言語で簡易的なSPAをつくる経験 gRPC で簡単なマイクロサービスをつくる経験 PAY.JP を使ったカード決済の流れの理解 今回使う技術スタック フロントエンドVue.js。サーバーサイドは Go言語で実装します。それ以外

    「Vue.js + Go言語 + PAY.JP 」でクレジットカード決済できるWEBアプリケーション実装ハンズオン - Qiita
  • Goのコマンドラインツールをセルフアップデートするためのライブラリつくった - はやくプログラムになりたい

    突然ですが,Goでコマンドラインツールを書く時,ツールの配布はどうしているでしょうか? go get でインストールできるようにする GitHub 上にリリースして,ダウンロードして使ってもらう システムのパッケージマネージャ(Homebrew など)を使う などがメジャーかと思います. ただ,これらの選択肢はどれも問題があります. go get -u は常にリポジトリの HEAD をインストールしてしまうため,ユーザがインストールしたタイミングに依存したバイナリができてしまいます.これを避けるには dev ブランチを切ってそっちで開発する必要がありますが,Go のツールはそうなってないものが多く,どのタイミングで go get -u したら良いかユーザには容易に判断できません.また,仮に dev ブランチ運用したとしても依存ライブラリの更新のタイミングは制御できず,vendoring な

  • golang のレイヤ構造において、他のコードに影響なくインフラレイヤのデータソース実装を差し替えることは可能か? - pospomeのプログラミング日記

    最近、golang のレイヤ構造において、他のコードに影響なくインフラレイヤのデータソース実装を差し替えることは可能か? という質問を受けた。 回答時間が限られている中で質問を受けたので、 「現実的には難しい」という雑な回答しかできなかった。 さすがに雑すぎるなと思ったので、 自分なりの回答をちゃんと残そうと思う。 影響を受ける対象となるコードは? MySQL -> PostgresSQL への差し替え MySQL -> WebAPI への差し替え インフラレイヤにDB依存のコードをまるっと実装してしまう DDDの場合 独自の接続オブジェクトを作る DDD & IDDDのサンプルはどうなっているか? 差し替える必要はあるのか? まとめ 影響を受ける対象となるコードは?golang のレイヤ構造において、他のコードに影響なくインフラレイヤのデータソース実装を差し替えることは可能か? とい

    golang のレイヤ構造において、他のコードに影響なくインフラレイヤのデータソース実装を差し替えることは可能か? - pospomeのプログラミング日記
  • iTerm2でSSHログイン先別にプロファイルを自動的に切替えて事故防止する方法

    「俺は知らなかったんだ… そのターミナルが番環境に接続していたなんて… 知っていたらrm -rf /なんて、流さなかった…」 想像しただけで前世に帰りたくなりますね。((((;゚Д゚))))ガクガクブルブル 上のは超極端な例ですが、ITエンジニアなら、SSHログイン先の環境を勘違いして危ない目にあったこと、一度や二度あると思います。 そんなSSHを普段使いしている全エンジニアに向けて、iTerm2を利用して、お手軽簡単にSSHログイン先別に、iTerm2のプロファイル(ターミナルの全体的な見た目)を切替える方法をお伝えいたします。 この記事により、全国で一つでも不幸な事故が減れば、筆者望でございます。 __ (祭) ∧ ∧ Y  ( ゚Д゚) Φ[_ソ__y_l〉 SSHダ ワッショイ |_|_| し'´J ほな、いってみよ。 この記事を読んだらできるようになること 冒頭のG

    iTerm2でSSHログイン先別にプロファイルを自動的に切替えて事故防止する方法
  • All posts

    今年も GitHub トレンドから 2022 年の JavaScript/TypeScript を振り返ります。去年の記事はこちらです。 — GitHub のトレンドで振り返る 2021 年の JavaScript | WEB EGG 集計方法 記事の集計期間は 2022/0…

  • ツリー型タブのWebExtensionsへの移行のおはなし - Qiita

    Here is the English version of this article. この投稿は個人サイトとのクロスポストです。 2017年の8月下旬に思い立って、ツリー型タブのWebExtensions版を作り始め、去る9月26日にバージョン2.0としてリリースしました。 重い腰を上げて取り組む気になれたのは、必須と目していたAPIが一通り実装されてきて、Firefox 57でようやく技術的に作れる目処が立ってきたからでした。 関係者の皆さんの尽力に改めて感謝の意を表明します。 やっている事自体はそう難しい話ではなく、技術的に目新しいトピックは無いのですが、主に歴史的資料としてレガシーなアドオンの移行の一事例の記録を残しておこうと思います。 ツリー型タブとは? 一言でいうと、ツリー型タブ(Tree Style Tab、略してTST)は「Firefox用の、タブ同士の来歴・関係をツリー

    ツリー型タブのWebExtensionsへの移行のおはなし - Qiita
  • ブラウザのキャッシュ - Carpe Diem

    概要 Webフロントのパフォーマンス診断 - Carpe Diem で指摘されたブラウザキャッシュの対応をするため調べてみました。 大きく分けて強いキャッシュと弱いキャッシュの2種類のキャッシュがあります。 強いキャッシュ ブラウザ側でリソースを保持し、期限が切れるまでサーバにHTTPリクエストを発行しません。 なので一度ブラウザにキャッシュされるとサーバ側からハンドリングすることができなくなります。 これを設定する方法は Cache-Controlヘッダー Expiresヘッダー の2つがあります。 Cache-Control: max-age サーバからのレスポンスで以下のようにCache-Controlヘッダーを付けます。 Cache-Control: max-age=3600 このヘッダーが付いたリソースはブラウザ上では強いキャッシュとして残ります。 max-ageは秒数なので、こ

    ブラウザのキャッシュ - Carpe Diem
  • だんだん開発スピードが遅くなっていくのをどうやってとめたら良かったんだろう? - Mitsuyuki.Shiiba

    先日、モブプロをやってきた。その中で、モブプロとは別で、いくつか感じたことがあって、今日はその中のひとつを思い浮かんだままにメモ。 bufferings.hatenablog.com 要件を満たすプロダクトをより早く出す モブプロでTDDしながら、要件を満たすプロダクトをより早く出すことに集中してみた。例えば、第2ラウンドのお題はTDDBCなどでお馴染みの「自販機」。 「100円を入れてボタンを押すとコーラが1買えること」 最初に「100円を入れてボタンを押すとコーラが1買えること」と言われ。 assertThat(get(100), is("コーラ")); みたいなテストを書いて。 String get(int money) { return "コーラ"; } みたいな実装を書いた。爆速! 「200円を入れてボタンを押すとオレンジジュースが1買えること」 次に「200円を入れてボタ

    だんだん開発スピードが遅くなっていくのをどうやってとめたら良かったんだろう? - Mitsuyuki.Shiiba
  • CodeIQについてのお知らせ

    2018年4月25日をもちまして、 『CodeIQ』のプログラミング腕試しサービス、年収確約スカウトサービスは、 ITエンジニアのための年収確約スカウトサービス『moffers by CodeIQ』https://moffers.jp/ へ一化いたしました。 これまで多くのITエンジニアの方に『CodeIQ』をご利用いただきまして、 改めて心より深く御礼申し上げます。 また、エンジニアのためのWebマガジン「CodeIQ MAGAZINE」は、 リクナビNEXTジャーナル( https://next.rikunabi.com/journal/ )に一部の記事の移行を予定しております。 今後は『moffers by CodeIQ』にて、 ITエンジニアの皆様のより良い転職をサポートするために、より一層努めてまいりますので、 引き続きご愛顧のほど何卒よろしくお願い申し上げます。 また、Cod

    CodeIQについてのお知らせ
  • Microservices Meetup Vol.5 (API Gateway & BFF) を開催しました

    概要 株式会社FiNC主催による、マイクロサービスに関する勉強会です。 今回は、「API Gateway & BFF (Backends for Frontends)」がテーマとなります。 # テーマについて API Gateway … 毎回サブのテーマを変えておりますが、今回は API Gateway & BFF (Backends For Frontends) をテーマにしました。これらがどんなものかは、特に前半2つの早川さん・古川さんの資料にも多く触れられていますので、初見の方はぜひご参照ください。 ご登壇していただいたのは、以下の四人の方々です。 早川さん (twitter: charlier_shoe, 日オラクル株式会社)古川さん (twitter: yosuke_furukawa, 株式会社リクルートテクノロジーズ, Node.js日ユーザーグループ代表)高松さん (tw

  • 新卒1年目がバッチサーバーにECSを使ってDockerを導入した話 | feedforce Story

    こんにちは!株式会社フィードフォース新卒エンジニアの@kielzeです。最近は会社から支給されたMacBookProのTouchBarにsushiを流したりしています。 フィードフォースには新しい技術に積極的に挑戦できるような環境があります。そして、挑戦した結果がよいものであれば、番環境でもガンガン使われます。 若手も新卒も関係無く、全てのエンジニアがその挑戦権を持っています。 今回は、先輩エンジニアである@tsubさんが、当時新卒1年目で社内で使われているバッチサーバーのDocker化に挑戦した話をしようと思います。 ちなみにtsubさんはとても知識が豊富で何を聞いても答えてくれるので、とても頼もしい先輩です! Dockerを導入した経緯フィードフォースでは、データフィードマネージメントサービス「DF PLUS」を提供しています。 このサービスの裏側では、お客様から頂いた商品データなど

    新卒1年目がバッチサーバーにECSを使ってDockerを導入した話 | feedforce Story