「CIのためのテスト自動化」というテーマで第17回QUESに招待いただいた際の資料です。 - Agileチームにおけるテスト自動化の試行錯誤から得られたしくじり - Agile Testingの概要とその一つの取組みとしてのATDDの実践をテスト自動化目線で - システムレベルの自動E2Eテス…
初記事です。 あるフロントエンドの悩み プロジェクトの納期は決まっていて、すぐに着手しないといけない。 だけど、API はまだできていない... 早く着手したい...、ふぬぬ...。 今回はそんなフロントエンドがバックエンドのタスクの待ちにならないように、並行してアジャイルに開発していけるツールとしてmswをご紹介します。 mswとは? mswとはmock service workerの略で、簡単にモックのAPIを立てることができるライブラリです。 同様のことができるライブラリとしてJSON Serverもありますが、mswには以下の利点があります。 単純にJSONを返すのではなく、ロジックも書くことができる Expressのようにスッキリ書くことができる RESTだけでなく、GraphQLにも対応している 以下のようなケースに向いていると思います。 早く着手しないといけないけど、API
Women Developers Summit で登壇したときの資料です。
2021年11月18日 JavaScript いつも何気なく使っていたコードをふと調べ直してみると、知らないうちに「Deprecated(非推奨)」と書かれている…なんてこともありますよね。今回はJavaScriptを書いていて出くわした非推奨となったものをいくつか紹介します。 ↑私が10年以上利用している会計ソフト! document.write 画面にテキストを表示する document.write 。JavaScriptの勉強を始めて最初に書いたコードがこれだったという方もいるのではないでしょうか?これはブラウザーのレンダリングに悪影響が出たり、DOMへの影響などを考慮して「強く非推奨」とされています。 これまでの記述例: document.write('やっほーい'); 解決策1:textContent や innerHTML を使う 代わりに文字列を書き換える textConte
Hamee様 開発合宿 2021年(前半戦)の資料です。 # 参考リンク - https://speakerdeck.com/soudai/engineer-life-hack - https://www.shinryo.com/special/contents01_3.html - htt…
プログラミングとはコードを書くことだけではありません。どういった構造にするのか、データはどう扱うのか、どのライブラリを使うのか、いくつもの設計を踏まえてコードを書くのです。設計を表現したものがソースコードです。 設計の良し悪しは品質に影響します。では、良い設計を作るスキルは一体どうやって身につけることができるのでしょうか。プログラミング言語の文法は知識なので、独学でも学ぶことができますが、設計に関してはそうはいきません。 本稿では、プログラミングにおける設計力を高めるためにはどうすれば良いのかを考察します。ここで言う設計は、画面や仕様ではなく、ソフトウェア内部の設計ですが、抽象化するとクリエイティブな仕事全般に通じるかもしれません。 本稿の内容は「良い設計」について論じたものではなく、どうすれば身につくのかを考えたものになります。また、私たちソニックガーデンで行っている、良いコードを書ける
挨拶内海「どうもお願いします。ありがとうございます。今、NFTアートをいただきましたけどもね。ありがとうございます。こんなんなんぼあってもいいですからね」 駒場「いきなりなんですけどね、うちのおかんがね、好きなIT用語があるらしいんやけど」 内海「そうなんや」 駒場「その名前を忘れたらしいねん」 内海「IT用語の名前忘れてまうってどうなってんねん。あれやろ、IT用語ゆうたらどうせ、デザイン思考か、アジャイル開発か、リーンスタートアップやろ!」 駒場「俺もそう思ったんやけどちゃうらしくてな、いろいろ聞くんやけど、全然わからへんねん」 内海「そうなん?」 駒場「うん」 内海「ほんだら俺がね、おかんの好きなIT用語、一緒に考えてあげるから、どんな特徴言うてたかとか教えてみてよ」 定義駒場「おかんが言うには、製品やサービスとの関わりを通じて利用者が得る体験及びその印象の総体やって言うてた」 内海「
逃げるプログラマー、避けられない壁 Web系アプリケーション開発をするとなると、React, Angular, Vueといったフレームワークの話題は避けて通れないのだけど、面倒にかまけてみて見ぬふりをしているデヴェロッパー諸君は多いと思う。 自分もそういうダメグラマーの一人でした。 だが、Nodeベースでバックエンドを開発していると、どうしてもフロント側が必要だし、使いたいライブラリーや機能、操作性を組み込むためには、フロント側のフレームワークからは逃げられず、立派なフルスタックデベロッパーになる為に、重いけつを上げ、学習することにしたのであります。 React, Angular, Vueの3大フレームワークをざっと調べてみた際に、一番取っつきやすそうだったReactをチョイス。 しょせんはHTMLとCSSとJavascript で、結局Reactは何をやっているかというと、しょせんはHT
こんにちは、@kaa_a_zu です。私は、今までいくつかの組織でフロントエンドのパフォーマンス改善に取り組んできました。パフォーマンスが劇的に改善したこともあれば、改善点の洗い出しで終わったこともありました。この記事では、それらの経験に基づいて、どのようにしたらチームがパフォーマンスに意識を向けることができるのか、改善を習慣化できるのかについて基本的なことを紹介させていただきます。少しでも参考になったらありがたいです。また、ご指摘や感想も随時お待ちしております。 ※この記事はWebフロントエンド領域を対象にしています。 なぜパフォーマンス改善をするのか パフォーマンスを改善する目的には、大きく3つあると考えています。 ユーザー体験の質を向上させるため(追記: この動画はパフォーマンスの重要性を説いています) SEO対策のため 将来的にリッチな機能を導入するため(既にTWA化の基準にはパフ
Storybook・テストに関して「メンテナンス工数に見合うだけのメリットがあるか?」という議論を、経験したことはないでしょうか。フロントエンドは、とにかく動くものを作ることが優先され、Storybook・テストが二の次になっている現場も少なくないと思います。 限りある工数を割きチームで取り組むものですから、導入するためには「どういったメリットがあるのか?」という具体的な例をチームに示す必要があります。これは今年、筆者が体験した実メリットのお話です。導入を躊躇している現場にむけ、参考になればと思い書きました。 【Storybook】不要な Global CSS を削除できた きちんとコンポーネント設計され、コンポーネントに閉じた指定をしていたとしても、どこかに必ず Global な CSS があると思います。何かしらの資材を受け継ぎ立ち上げたプロジェクトに関しては、Global な CSS
コンテンツブロックが有効であることを検知しました。 このサイトを利用するには、コンテンツブロック機能(広告ブロック機能を持つ拡張機能等)を無効にしてページを再読み込みしてください。 ✕
2. 徳丸浩の自己紹介 • 経歴 – 1985年 京セラ株式会社入社 – 1995年 京セラコミュニケーションシステム株式会社(KCCS)に出向・転籍 – 2008年 KCCS退職、HASHコンサルティング株式会社(現社名:EGセキュアソリューションズ株式会社)設立 • 経験したこと – 京セラ入社当時はCAD、計算幾何学、数値シミュレーションなどを担当 – その後、企業向けパッケージソフトの企画・開発・事業化を担当 – 1999年から、携帯電話向けインフラ、プラットフォームの企画・開発を担当 Webアプリケーションのセキュリティ問題に直面、研究、社内展開、寄稿などを開始 – 2004年にKCCS社内ベンチャーとしてWebアプリケーションセキュリティ事業を立ち上げ • 現在 – EGセキュアソリューションズ株式会社取締役CTO https://www.eg-secure.co.jp/ –
対象読者と目的 非同期処理の実装方法は知っているが、仕組みを詳しく知らないのでベストプラクティスがわからないときがある 実行順序の保証がよくわからないので自信をもってデプロイできない変更がある より詳しい仕組みを理解することでより計画的な実装をできるようになりたい という動機で書かれた記事です。同様の課題を抱える人を対象読者として想定しています。 目次 実行モデルとタスクキュー Promise async/await AbortSignal, Event, Async Context WHATWG Streams / Node.js Streams (執筆中) 未定 用語に関する注意 前回定義した以下の用語を今回も使います。 1 tick ... タスクキューが1周すること。 1 microtick ... マイクロタスクキューが1周すること。 これらの単位は非同期処理の間の相対的な優先順
昨日「動いたけどチームメンバーを説得するのが面倒で、秘蔵のブランチになってしまう」って言ったけど、この気持ちはどこから出てくるのか。 分かりやすい Cons があると、反発が予想できて、その反発を解決するところまで労力を割くほどの気持ちが無いので困る。「直ちに問題になるわけじゃないが、どちらかというとやった方がいい、でもリスクもある」という選択肢を選べずにズルズルと現状維持に向かう圧力は、ある。チームの同質性が高いうちはほとんど困らないんだが、人数が増えたり、別の職種が増えたりするごとに「面倒」さはどうしても増していく。 我々の信念として以下を持ってはいるが、現状維持に向かう圧力がある中で変化を加えるのはそこそこ労力が要り、閾値を超えると変化が発生しなくなってしまう。 業務・開発フローは「変えることは無条件に正しい」くらいに思って良いと思っています。 素早く変えてもし仮にダメだったら素早く
はじめに 非常に有り触れたタイトルになっていますが、最近私の周辺で Flutter を始める方が増えてきており(推奨している影響もある)、その都度同じリンクを貼るのが億劫になってきたのでまとめることとしました。ただこの手の内容だと「ただリンクを貼るだけ」みたいな記事も散見されますが、それだけだとつまらないのでそのリンク先で何が学べたか、どう感じたかも一言添えて紹介します。私も1年半前から Flutter に出会い1から学習した身ですので、これから Flutter を始める方とも感覚的には近いと認識しています。より再現性が高くなるよう、私が実際に学習で使用した内容を中心に取り扱っておりますので参考にして頂ければと思います。 対象となる読者 Flutter SDK も最近インストールした正にこれから始める人 学習するか迷っているが全体像を把握したい人 自分で手を動かしてものを作るのがはじめてな
私がソフトウェア開発において心がけていることの一つに「設計に悩み始めたらとりあえず手を動かす」というものがあります。今まで深く考えずにそう心がけていましたが、この記事で自分がなぜそうしているのか整理して言語化してみたいと思います。 話のスコープ ここでいう「手を動かす」とは「コードを書く」ことです。設計と聞いて人によって思い浮かべるものが違いますが、ここでは「一人のソフトウェアエンジニアが四半期程度かけて開発する規模の機能の設計」を想定しています。何人ものソフトウェアエンジニアが長期に渡って行うような大規模開発には当てはまらないです。 本題 次のような経験はないでしょうか? 設計を考えながらデザインドキュメントを書いていたら細部の粗が見えてきて無限に悩み続けてしまった。考えなきゃいけないことがどんどん膨らんでいって、いつまでも実装に手を付けられなかった。 これに対して私は「設計に悩み始めた
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く