NeovimでDenoを開発するときにめっちゃ効率上げるコマンドを作った
追記ここから 本記事の内容はNeovim専用です。 以下の記事で紹介しているものは、エディタを問わず、便利な機能が追加されています。 今後はこちらをご利用ください。 追記ここまで 最近、いろいろとDenoで開発しています。 以下のような制作物をZennで紹介しています。 Deno Deploy専用のSSG Diplodocus DenoでGitHubの草を取得できる github-contributions-api Deno Deployに自己紹介ページを作れる Denote DenoでHTMLタグを書ける markup-tag Deno Deployで使えるログモジュール tl-log 開発を続けていくうち、サンプルやテストを書いて、確認のために手動で何度も実行するのが億劫になってきました。 そんな中、こちらの記事にインスパイアされ、変更を自動検出して確認できる環境があると良いなと認識し
Node/Deno でソースコードにテストを書く
tl;dr ファイルをそれ単独で単体テストとして実行するボイラープレートを編み出した そのヘルパとして mizchi/test という実装を作った なぜソースコードにテストを書きたいか Rust や Python の doctest ではソースコードにテストを書く方法があります。 ソースコードにテストを書けると、コードとテストの心理的な距離が近くなってテストが書きやすくなる、という肌感があります。(諸説あります) 実装とテストが混ざって汚れるのが嫌という意見も理解できますが、それはありつつ認めた上で、あとでリファクタする前提で最初の一歩をその実装に書けると嬉しい、という気持ちがあります。 現状の Node だととりあえず assert するだけという単純なテストを書くことは可能ですが、構造化する方法がないので、簡単なスクラッチの時ぐらいしか行われません。 // test.js import
SpringBootで動的な条件をもとにDIしたい | フューチャー技術ブログ
SpringBootのDependency Injection（DI）は便利ですよね？利用する側にコンストラクタインジェクションやら、フィールドインジェクションやらセッターインジェクションやらの形式で書いておくと、DIコンテナが勝手に実行時に対象となるクラスをもってきてインスタンスの生成をしてくれますし、インスタンスのライフサイクルをインジェクションされるクラス側に書けます。 @Component public class UseDI { private final MyService myService; @Autowired public UseDI(MyService myService) { this.myService = myService; } } @Service public class MyService { public MyService() { System.ou
大規模サービスのUIデザインを管理する工夫｜たまい
2022年7月27日にFigma Japan Community Event「Figmaの活用策をシェアしよう！」でLTを行いましたので、その発表内容を公開します。 以下、書き起こし内容です👇 たまい（@tmi_1064）です。現在はクックパッドにてレシピサービスアプリの体験設計・UIデザインに取り組んでいます。 クックパッドのデザイン体制現在クックパッドでは、「毎日の料理を楽しみにする」ことを目標に料理に関する課題を解決できるプロダクトを3部署、合計9人のデザイナー体制で開発しています。 1サービスにこれだけのデザイナーが関わるとなると、様々な課題が出てきてしまいます。 今回はそんな課題に対してどんな方法で解決したかをいくつかご紹介させていただきます。 課題1：施策/デザイナーが複数関係していてトンマナ管理・仕様の把握が大変まず1つ目は「施策/デザイナーが複数関係していてトンマナ管理・
文化シヤッターのシステム開発頓挫で、日本IBMが19.8億円の賠償を命ぜられた理由
システム開発の頓挫を巡る、文化シヤッターと日本IBMとの間の裁判で、東京地方裁判所は日本IBM側に19億8000万円の支払いを命じた。米セールスフォースのPaaSを用いた販売管理システムの構築を目指し、2015年に始めた開発プロジェクトだったが、2017年にストップしていた。東京地裁は開発失敗の原因をどう認定したのか。裁判記録をもとに読み解く。 文化シヤッターが、20年以上前から使用していた販売管理システムを刷新するプロジェクトを本格的に始動させたのは2015年1月のことだ。日本IBMに提案依頼書（RFP）の作成を委託。そのRFPを基に複数ベンダーから提案を受けた上で、日本IBMを開発委託先として選定した。 日本IBMの提案はシステム構築に米セールスフォースのPaaS（プラットフォーム・アズ・ア・サービス）である「Salesforce1 Platform」を用いるものだった。RFPでは標準
Autify ブログ - Autify(オーティファイ)
About Autify 無料トライアルをはじめる 2024年03月30日 QA業務に役立つおすすめ資格とは？必要な知識やスキル、向いている人の特徴などをわかりやすく解説！ Autify, Inc. 2024年03月30日 ソフトウェアにおけるQA(Quality Assurance)とは？品質保証の考え方 Autify, Inc. 2024年02月05日 Autifyのテスト実行を20%高速にした話 Autify, Inc. Autify, Engineering 2024年02月05日 AutifyのHackathon、名付けてAutifyathon! Autify, Inc. Engineering, Event 2023年12月25日 テスト自動化プラットフォームAutifyはどのようにAutify自身を自動テストしているか – テストシナリオ作成編 Autify, Inc. Ev
Pythonバックエンドエンジニアが1ヶ月でフロントエンドを学んだ話
この記事について Pythonバックエンドエンジニアが1ヶ月でフロントエンドを学んだ話を共有する。 どういう勉強をしたかのラーニングパスを某所で話したら興味があるというコメントがあったので、自分の振り返りも兼ねて共有することにした。 TL;DR 学習期間は1ヶ月、30時間程度 TypeScript → Next.js → MDNでHTML+CSS → TailwindCSS の順に勉強した JavaScript、React.jsはほぼすっ飛ばした(というより上記ラーニングパスの中で派生して習得した) できるようになったこと: 簡単な処理であればテストつきでTypeScriptのコードが書けるようになり、UIの基本的な設計ができるようになった DISCLAIMER 筆者の経験を記したものであり、ベストプラクティスではありません。 筆者の開発スキルセット（勉強前時点） バックエンドが得意領域
JavaScriptの非同期処理をじっくり理解する (1) 実行モデルとタスクキュー
対象読者と目的 非同期処理の実装方法は知っているが、仕組みを詳しく知らないのでベストプラクティスがわからないときがある 実行順序の保証がよくわからないので自信をもってデプロイできない変更がある より詳しい仕組みを理解することでより計画的な実装をできるようになりたい という動機で書かれた記事です。同様の課題を抱える人を対象読者として想定しています。 目次 実行モデルとタスクキュー Promise async/await AbortSignal, Event, Async Context WHATWG Streams / Node.js Streams (執筆中) 未定 入門記事へのリンク プロミスの使用 - JavaScript | MDN Promise, async/await (現代の JavaScript チュートリアル) JSの初心者にPromiseとasync/awaitの使い方
Software Design連載 2021年9月号 「テストが無い」からの脱却 - MonotaRO Tech Blog
こんにちは、鈴木です。 「テストが無い」状態を脱却しました。 「いつの時代かよ！」と突っ込まれるかもしれませんが、モノタロウは創業から 20 年ほど EC をやっています。昨日書いたコードも、15 年前に書いたコードも、元気にビジネスを支えています。 本記事ではモノタロウの EC を支える API の話をします。「テストが無い」状態がスタートラインでした。そこから、CI を導入して、ローカル開発環境の整備して、テストコードを書いて、リリースマネジメントを導入しました。 目新しいことは書きません。長寿の大規模システムであっても、愚直に数年取り組むことで、「前進できる！」「変えられる！」という実例を書きます。 ※本記事の初出は、 Software Design2021年9月号「Pythonモダン化計画（第2回）」になります。第1回の記事は「Software Design連載 2021年8月号
アジャイル生誕20年──平鍋氏と及部氏が、エンジニアとアジャイル開発の関係を考えてみた【デブサミ夏2021】
日本におけるアジャイル開発の第一人者であり、ソフトウェア開発手法の必読書『アジャイル開発とスクラム』の共著者である平鍋健児氏と及部敬雄氏。2001年の「アジャイルソフトウェア開発宣言から20年を迎える2021年は、アジャイル開発歴10年の及部氏とアジャイル開発歴20年の平鍋氏にとっても、節目の年である。そこで、今回のセッションはアジャイル開発生誕20周年を記念し、両者のこれまでの軌跡とともに、なぜ自分がアジャイル開発と関わっているのか、その熱い想いが語られた。 株式会社永和システムマネジメント 代表取締役社長 平鍋健児氏（左上）、株式会社デンソー デジタルイノベーション室 及部敬雄氏（右下） アジャイル開発に「もっとよい世界があるかもしれない」と気づかされた 及部氏が楽天に新卒で入社したのは、2009年。エンジニアとして初めて書いたコードや最初のプロジェクト、初リリースで感動し、やりがいを
ローコード開発ツール「AWS Step Functions」が大幅拡充、200以上のAWSサービスを組み合わせたクラウドアプリ開発が容易に
ローコード開発ツール「AWS Step Functions」が大幅拡充、200以上のAWSサービスを組み合わせたクラウドアプリ開発が容易に Amazon Web Services（AWS）は、同社のクラウドサービスとして提供しているローコード開発ツール「AWS Step Functions」で、200以上のAWSのサービスを新たにサポートしたことを発表しました。 ICYMI: AWS Step Functions expanded the number of supported AWS services from 17 to over 200, and AWS API Actions from 46 to over 9,000! https://t.co/Azq1LlAt3u — AWS Developers (@awsdevelopers) October 11, 2021 これまではA
単一責任の原則（Single responsibility principle）について、もう一度考える | オブジェクトの広場
単一責任の原則（Single responsibility principle）について、もう一度考える はじめに オブジェクトの広場をご覧の皆様ならば、「SOLID原則」という言葉を聞いたことがあるかもしれません。 SOLIDとは、以下の5つのソフトウェア設計原則を並べたバクロニムです。 Single Responsibility Principle：単一責任の原則 Open/closed principle：オープン/クロースドの原則 Liskov substitution principle：リスコフの置換原則 Interface segregation principle：インターフェース分離の原則 Dependency inversion principle：依存性逆転の原則 ソフトウェアエンジニアが知っておくべき設計原則のセットとして、Clean Architecture や
細かいことは理解せずにpythonのコードをマルチプロセスで高速化する方法 - Qiita
はじめに pythonでいろいろプログラムを実行していると、もっと高速に実行することはできないかなと思うことがあります。 特に性能のいいパソコンなどを持っている人だと、タスクマネージャーを開いてCPUの使用率を眺めていると1スレッドしか使われていないじゃん、と思うことがあると思います。 何とかしてすべてのcpuコアを使用して高速化できないかな、というときに少し調べたらこんな記事が出てきました。 私もこれを参考にいろいろ高速化に成功しましたが、いろいろ落とし穴などがあったため、並列化のやり方を1から解説しようと思います。 どんなコードなら高速化できるか なんでもかんでも高速化することができるわけではありません。 大前提として、___forを使用したループ___がある場合、並列化によって高速化ができる可能性があります。 可能性といったのは、中には難しい場合もあるからで後に解説します。 実際どう
第5回 リモート化で加速するモブプログラミングとアジャイルの精神 | gihyo.jp
テックコミュニティの運営側で、その技術分野を常に追いかけているエンジニアの方々にお話をうかがうインタビュー企画。ホストは関満徳が務めます。コロナ禍のさなか対面での取材を避け、リモートで行います。第5回目のゲストとしてお迎えしたのは、シニアアジャイルコーチとして活躍する川口恭伸氏です。 川口氏は、現職にアジャイルコーチとして従事する傍（かたわ）ら、一般社団法人スクラムギャザリング東京実行委員会 代表理事、一般社団法人DevOpsDaysTokyo代表理事などの活動を精力的にされています。 川口 恭伸（KAWAGUCHI Yasunobu）さん得意とするIT分野は、アジャイル開発のプロセスやチームマネジメント、プロダクトオーナーシップ（要件定義や絞り込み）、モブプログラミング。現在は、なにかするときにJavaScriptを選択することが多い。 Twitter：@kawaguti URL：h
Effective Java輪読会をやってみた｜金丸翔 @TxTo CTO
はじめにこんにちは！株式会社POLでエンジニアをやっている @show_kanamaru です！ POLは「研究者の可能性を最大化するプラットフォームを創造する」をビジョンに、理系学生に特化した採用サービス、および研究開発者・技術者に特化した転職/採用サービスの2サービスを運営しています。 今回はチームで毎週実施している「Effective Java輪読会」について書きたいと思います！ 輪読会とは人々が集まって、同じ教科書などの本を読み、その内容について意見を交わすことを意味する語。事前に決められた担当者が、本の内容を訳したりまとめたりしてから、他の参加者が理解できるように発表する形式がとられることも多い。 Weblio辞書より引用 輪読会の存在は知っていましたが、今までやったことがありませんでした。 始めてみてちょうど1ヶ月くらい経つので、今回は輪読会をやってみて良かったことをまとめた
モックは必要悪で、しないにこしたことはない - blog.8-p.info
Mockito や gomock が使いやすいせいか、単体テストというのはモックするものである、という思い込みがあるのか、人々がモックしすぎているのを時折みかける。 モックは必要悪で、しないにこしたことはない。外部の API サーバーとかはガンガン叩くわけにもいかないけれど、ファイル読み書きくらいは、実際にファイルを作ったり消したりしてしまっていい。/etc/passwd を消すとか、1GB のファイルを作るとかだと難しいかもしれないけれど、その場合でも、パスのプレフィックスを指定できるようにして、一時ディレクトリの中の etc/passwd を使うとか、ファイルサイズを指定できるようにするとか、逃げ道はいくつもある。そこを飛ばして「ファイル操作は一律モックしましょう」とか頑張りだすと辛いことになりがちだ。 モックの一番の問題は、本番とテストで違うコードが走ることで、これは自動テストの価値
勉強会「リーダブルなテストコードについて考えよう」に参加した
勉強会「リーダブルなテストコードについて考えよう」に参加してきたので気づきや感想をアウトプット 勉強会の資料 勉強会で発表されたお三方がスライドを公開してくださった、ありがたい 気づき プログラムを書くというよりはドキュメントを書くつもりで テストは仕様書という言葉はよく聞くと思うしそのとおりだと思う。 非エンジニアが見ても理解できるように書かれてのが理想形だ。（もちろん完全には難しいが） 過度にDRYにしない 変数展開少なく上から下へ読める方が脳内メモリ消費少ない APIドキュメントとかが参考になる DRYにしてはいけないというのではなく、過度に DRYにしてはいけないというのが重要 Shared examples とか無意味に乱発して、オレかっこいいやってない？ シナリオテストでは想像をなるべく減らす 参照元 画面遷移などを伴うので、今どこのページにいるのか、どのケースなのかという文脈
テスト工程の可視化や自動化に向けた取り組みのご紹介 - Mirrativ Tech Blog
こんにちは、エンジニアの千吉良（ちぎら）@_naru_jpn です。ここ最近 QA に関して考える機会があり、Systematic Software Testing という本を読んでいたところ、色々と刺激を受けるところがありました。計画書の作成やリスク管理などテストの実施以外の領域についても多く書かれていましたが、まずはミラティブの現状に基づいた改善を行うべきだろうと考えました。今回は特にメトリクスの取得などに関して、GAS（Google Apps Script）を活用してミラティブの業務に応用してみたことについてまとめてみました。 以下では細かいことにも触れているので、3行まとめをおいておきます。 手動テストの進捗を見えるようにしたよ GAS（Google Apps Script）で実装したよ ついでに関連業務を自動化したよ ミラティブにおける QA と解決できそうと感じた課題 ミラティ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
もうつまらないとは言わせない！「わかりやすい」プレゼンを作るために気をつけたいこと
[記事下書き] MySQL/Postgres におけるトランザクション分離レベルの実際![[記事下書き] MySQL/Postgres におけるトランザクション分離レベルの実際](https://cdn-ak-scissors.b.st-hatena.com/image/square/be4a7bfbb640d53daec1dd96b5f2f8f4b120ea01/height=288;version=1;width=512/https%3A%2F%2Fstorage.googleapis.com%2Fzenn-user-upload%2Favatar%2F94ec78e846.jpeg){kind=avatar}