Adds a toolbar button with various web developer tools.
Adds a toolbar button with various web developer tools.
突然ですが、git-pr-releaseのなんちゃってコラボレーターである私が僭越ながら、その王道の使い方を皆様に伝授していきます。何番煎じかの記事ではありますが、現代の、特にGitHub Actions出現以降の使い方をまとめたいというのが動機です。 https://github.com/x-motemen/git-pr-release https://rubygems.org/gems/git-pr-release git-pr-releaseはGitHubを業務開発で利用している場合に便利なツールで、デフォルトブランチにマージされたpull requestをリリース項目として一覧し、それをpull request化してくれるものです。これにより以下のことが実現できます。 リリース項目が一覧されることによるリリース内容の明確化 マージボタンによる明快なワンクリックデプロイの実現 pul
前提 ここで言っているドキュメントは仕様書ではなく、顧客向け製品ドキュメント。 ミドルウェア製品を開発 小さなチーム パッケージ製品とパッケージ製品のクラウド版 そのため顧客に提供するドキュメントが必ず必要 GitHub を利用 自分で開発する場合のフロー 作りたい機能をぼんやりでいいので GitHub Issue に追加する feature ブランチを切る デザインドキュメントをリポジトリの doc/ 以下に書く デザインドキュメントに合わせてコーディングを進めてなんとなく動くところまで作る 動かなくてもいいのでイメージを膨らませるためにコードを書いてみる デザインドキュメントは書き捨て前提で、とにかくメモを書く 製品ドキュメントを書き始めて、一旦書き終える ブランチマージに向けてコーディングを進める 書ける範囲でテストを書く ドキュメントを平行して修正する プルリクエストをだしてレビュ
さくらのクラウドでバックエンドを担当しております、@townewgokgok と申します(記事はフロントエンド寄りの記事になります)。これは さくらインターネット Advent Calendar 2018 11日目の記事です。 JSONのように階層化された値をURLに埋め込みたいことってありませんか? たとえば 価格.com の商品検索結果ページ のように、リンクを開いたら検索フォームの内容が復元されて、URLのコピー時に見ていたものがそのまま表示されて欲しい。 これを実現するには、従来なら文字列のキーバリューとしてごく一般的な application/x-www-form-urlencoded 形式でURLにパラメータを埋め込むところです(上記の価格.comの例でもやはりそうなっています)。ただ、そこそこ複雑な検索フォームの値をいちいちこの形式にまとめたり復元したりするのはわりと面倒です
Gyazo Extensionの開発を主に担当しているid:Pasta-Kです。 Gyazo Extensionは日本時間の2020年5月21日〜2020年7月29日の間、Chrome Web Storeから取り下げられていました。いくつかの変更をExtensionに加えることで審査を経て本日遂に再公開となりました。同様にGyazo Teams向けのExtensionも引き続き非公開になっていますが、今回のGyazo Extensionの再公開を受け、数日中に再公開できる見込みです。 この件に関する、経緯と対応に関する具体的な内容について、主にChrome Extensionの開発に関わる皆さんに向けて共有しようと思います。もし同じような事象に遭遇している方の参考になれば幸いです。 経緯について Chrome Web Store側からはUse of Permissions*1に関する違反が
ブログ以外での活動をみていただければ理解いただけるかと思うが、私は普段はフロントエンドの界隈にいる。 そのなかで、ちかごろ界隈のインターネットが非常につらいと感じることが多々ある。 他の界隈でもそれなりは見られるが、特にフロントエンドで顕著にみられるその「つらい」傾向を完結にまとめてみた。 フロントエンド地獄インターネットのメカニズム 現状のフロントエンドをみていて複雑な気持ちになるパターンはおおよそ以下である。 全体的な地獄フロー 何かしら新しい技術が出てくる Qiitaはてブロ辺りでイケハヤみたいなタイトルの技術系エントリが投稿される バズる 使ってもいない人間がニコニコ動画のコメントみたいな発言をする 地獄になる 誰しもこういう流れをみたことはあるだろう。本当に複雑な気持ちになる人間が多いであろうと思っているため、この「気持ち悪さ」の何が悪いか、どうして起きるのかを自分なりにまとめて
GmailにはGoogleドライブのファイルをポップアップ上で検索してGmail本文に貼り付ける機能が用意されています。 以下の様な画面です。 実はこのGoogleドライブからファイルを選ぶという機能をjavascriptを少し書くだけで 自分のWebサイトに簡単に埋め込むことが可能です。 それを行うための機能をGoogleが提供しています。それがGoogle Pickerです。 またGoogle Pickerはドライブのファイルだけではなく Googleマップから住所を選択、Googleフォトから写真を選択など様々なピッカーが用意されています。 <input type="file">のクラウド版みたいなものです。 実際に試してもらったほうが理解しやすいと思います。デモページを用意しました。 @本記事は前半に機能の紹介、後半に開発向けの解説を記載しています。 機能の紹介 デモページを開いて
webpackとは いろんなファイルをtranspileしてES5のJavaScriptに変換してくれるやつ AMDかCommonJSの形式でファイルをロード(CommonJSならrequire)すると、transpileしたファイルをロードしてくれる クライアント側のjsコードでもrequireを使用することができる assetとしてビルドして配布するイメージ コードが共用の場合、設定を変えることで素のrequireを利用するサーバー用コードと、webpackがpolyfillしたrequireを利用するクライアントコードとを別々に生成できる 全てがJavaScriptになる、画像やCSSも 画像は「Base64かFilePath」に CSSは「headにstyleを挿入するjsコード」に 特定のファイルをどのようにtranspileするかはpathマッチングでプラグイン形式で設定する
本連載は、パフォーマンスを主な対象としてシステム開発・運用の改善や設計を行うNTTデータのコンサルタントチーム「まかせいのう」のメンバーが、業務での体験やそこから得た知見を共有する『週刊まかせいのう』の記事を編集し転載するものです。今回は、クライアントサイド(Webブラウザ)の処理性能を劣化させるパターンと、それを改善し性能を向上させるチューニング方法を紹介します。 遅延原因がクライアント側にある場合の2つのパターン いわゆる「性能が出ない」「画面がもっさりして処理が遅い」という性能問題が発生した場合、必ずどこかに遅延を発生させているコンポーネント、いわゆる「ボトルネック」が存在します。それはWebサーバであったり、DBサーバであったり、はたまたネットワークやストレージであったりします。 一般的に、こうした遅延箇所の多くはサーバサイドに集中しています。サーバサイドでは、多くのユーザリクエス
広告事業部の鈴木達矢です。コーディングをしてると変数やメソッド名の付け方に悩むことって多々ありますよね。逆にコードを読んでいると単語の選択がこれでいいのかなという時や、動詞の活用形が間違っていてよく意味がわからない、時に潔く日本語の変数名になっていることも見かけます。でもプログラミング言語の単語が英語をベースにしていますし、Railsを使っている場合は日本語が規約(Convention)に合わなかったりします(複数形が無いなど)。それから動詞の活用形が違っていると主語(動作の主体)が変わってしまい、意味が変わってしまいます。その結果コードの可読性が落ち混乱を招きやすくなります。 いくつかの基本的な法則だけおさえておけばコーディング中に可読性の高い単語の選択ができるようになります。今回はそれを目的に、英語の扱いに都度時間を費やしてしまうような方に向けていくつかの法則をご紹介します。*1 変数
Web based on Standards Web は誰のものでもありません。 だれかプロダクトオーナーがいてその人が意思決定するとか、そういうのとは真逆の成り立ちをしています。 標準的な仕様を決めて、その仕様に則って Web の世界は成り立っている。 政府が作るサイトも、 Twitter も、学生が作ったブログも、全部同じルールで作られている。だから繋がる。 これって結構凄いことだと、自分は思っています。 Standarization このルールの決め方にもルールがあって、ちょっと敷居は高いかもしれないけど、誰でも自由に参加して、自由に意見を述べることができる場があります。 標準化団体ってやつですね。 なんか一部の人たちが勝手にやっているように思えるかもしれないけど、それは選挙に行かない人の理論と同じです。 あなたが仕様について意見を持ってて、それが妥当であるならば、その発言は仕様を根
Oktavilla では、私たちは定期的に新規プロジェクトを立ち上げています。数年にわたって、私たちはこうしたプロジェクトを通してベストプラクティスを見つけ出してきました。そのおかげで、新規メンバーがスムーズにプロジェクトに参加できるようになり、エラーを減らすこともできました。こうしたベストプラクティスを、組織内部、クライアントを問わず大半のプロジェクトに活用しています。結果として、私たちは高品質のWebプロジェクトを実現しています。ここでお伝えするのは、そのプロセスの一部です。 このブログ記事では、技術面に関わるベストプラクティスに焦点を絞りたいと思います。例えばセットアップや、プロジェクトのツールやプロセスを選択する際に考慮すべきことなどについてお伝えします。各プラクティスの文末に、詳細な情報へのリンクをいくつか貼っています。 READMEファイル まずは、プロジェクトで最も重要なファ
こんにちは。デザイナーの王です。 Webアプリはデスクトップアプリとは違い、まだまだ発展途上の技術のため、色んな所でまだ未熟な部分があります。デスクトップアプリでは当たり前のことでもWebアプリではできなかったりすることも多いのです。中でも、UIのコンポーネント化問題が以前から指摘されてきました。 通販サイトにある「購入ボタン」を例に説明すると分かりやすいと思います。 この手のボタンを作るには以下の手続きを要すると考えられます。 外観を整える CSS HTMLマークアップ クリックした際の挙動 JavaScript 何が厄介かというと、「再利用」が難しいというところなんですね。 例えば、同サイトの別のページで同じボタンを使いたい場合、js、CSS、HTMLを再度記述しなければなりません。しかも場合によってはHTMLのマークアップが非常に冗長化していることもある。 「購入ボタン」はあくまで一
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く