なんかおすすめなテスト本ないですかねえ? と、某所で(テストをメインの業務にするのではなく)普通に開発をされている方に聞かれたので、 プログラミングは普通にできる テストについては学んだことはない とはいえテストエンジニアになるわけではなく、開発者としてテストが知りたい という人向けに、2021年現在で普通に入手できる本をいくつか挙げてみます。
調査対象者に、勤務先でおもにどのような開発プロセスを採用しているかを尋ねたところ、「ウォーターフォール型」が58.2%、「アジャイル型」が12.1%となった。 いずれかの開発プロセスに携わっていると回答した人に、開発プロセスに課題を感じたことがあるかを尋ねた質問では、66.3%が「感じたことがある」と答えている。 開発プロセスに課題を感じたことがあると回答した人に、具体的な課題の内容を尋ねたところ(複数回答)、「見積もった工程と実績に乖離がある」(75.5%)がもっとも多く、以下「仕様工程による手戻りが多い」(67.9%)、「テスト工程が削減できない」(30.2%)が続いた。 その他の課題としては、「スロースタートになりやすく、慢性的な遅延が発生する」「手戻りが多く、開発コストがかさむ」といった回答が寄せられている。 開発プロセスに課題を感じたことがあると回答した人に、勤務先が採用している
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます Amazon Web Services(AWS)は先週、AWSクラウド上でのサーバーレスアプリケーションの開発方法に関するライブストリーミング講座をTwitch経由で提供すると発表した。この講座は、全8回で週次の配信が予定されている。米国時間1月28日に第1回目が配信された。 開発者はこの「AWS Dev Hour:Building Modern Applications」(AWS開発アワー:モダンアプリケーションの構築)シリーズを通じて、AWSクラウド上でフルスタックのクラウドネイティブアプリケーションを構築する方法を段階を追って学ぶことができる。第1回目は、「AWS Cloud Development Kit」(AWS CDK)を用
はじめに あくまで一個人の意見なので絶対的な解ではないというのと、どっちをデフォルトに選んでも普通にアプリケーション開発してて困ることはほぼほぼないと思うので、そこまで気を揉むことでもない、ということだけ最初に述べておいて意見をしたためます。 TL;DR アプリケーション開発では基本的に type でおk Declaration merging したい時だけ interface ライブラリ開発のような使う側で拡張したい(Declaration merging したい)時は interface とりあえずチームでどっちをデフォルトにするかは統一しといた方が気持ちいい type と interface の違い 機能的にはそんなに大きな違いはなく、個人的に判断に関わるのは次の3つかなと思います。 interface では Declaration merging がされる。type ではされない
class: center, middle # 明日から使える<br/><strong>実践</strong><br/>エラーハンドリング Scala関西Summit 2018 11/10 --- class: left, middle ## 自己紹介 * 中村 学(Nakamura Manabu) * [@gakuzzzz](https://twitter.com/gakuzzzz) * Tech to Value 代表取締役 * Opt Technologies 技術顧問 <img src="../images/opt_logo_1.jpg" alt="Opt Technologies" width="450" style="margin-left: 0px" /> * F-CODE CTO <img src="../images/f-code_logo.png" alt="f-cod
しっかりとした正しい知識を基礎から学び、長く電子工作を楽しむことができるようになることを目的とした今回の連載。分かりやすく解説してくれるのは、金沢大学電子情報通信学類教授の秋田純一先生です。記念すべき第1弾はセンサの仕組みを解説。 第1回となる今回は数あるセンサの中から、ToF距離センサについて解説をしていただきます。 目次 いろいろな距離の計測方法 ToFセンサと使い方 ToF距離センサの原理 カメラとToF距離センサ まとめ 1. いろいろな距離の計測方法 みなさん、こんにちは。金沢大学の秋田純一と申します。よろしくお願いいたします。 早速ですが、マイコンを使って何か作るとき、距離を測りたいことって、よくありますよね? 例えば障害物をよけて進むロボットとか、手を近づけたらアルコール消毒液を出す、といった場合です。こういうときは、いわゆる「距離センサ」を使うことになります。 対象物までの
ライブラリの紹介ページや GitHub のリポジトリで登場する「割と見るけど意味はよくわからない単語」をまとめてみました 誤りがあればガンガン指摘してもらえると助かります opinionated 意味をググると「[形容詞] 自説を固執する」という謎の和訳が出てきて理解を諦める方もいるんじゃないでしょうか opinionated については色々な記事で紹介されています https://qiita.com/baby-degu/items/7dc4548bf7befc2671f4#opinionated%E3%81%A8un-opinionated https://stackoverflow.com/questions/802050/what-is-opinionated-software プログラミングの文脈に落とし込むと「ライブラリやフレームワークが定義したやり方に利用者(プログラマ)を従わ
プログラミングをする上で、コメントをきちんと残したり、わかりやすい変数名をつけたりして「読みやすいコード」を目指す作業は重要です。しかし、「読みやすいコード」と「優れたコード」の間には、時として構造上の大きな違いがあるのも事実。そんな「優れたコード」に対するLinuxの開発者リーナス・トーバルズ氏の考え方について、エンジニアのmkirchner氏が説明しています。 mkirchner/linked-list-good-taste: Linus Torvalds' linked list argument for good taste, explained https://github.com/mkirchner/linked-list-good-taste Linus Torvalds: The mind behind Linux | TED Talk https://www.ted.co
今回も誰も興味ないシリーズなので今まで書いてこなかったのですが、Semantic Versioningに関して幻想を抱いている人がいる可能性があり、そういう方にどうしても現実を知っておいて欲しかったので書きました。3行要約(と可能なら余談)だけでも読んでいただけると幸いです。 3行要約 Semantic Versioning 2.0.0にはバージョン"比較"の定義はあるが、バージョン"制約"(>= 2.1.3みたいなやつ)の定義がない その結果、同じsemver準拠ライブラリでも制約の解釈が異なり結果が真逆になる というかそもそもsemver使ってるエコシステムが少なすぎる 背景 セキュリティアドバイザリでは特定のバージョンが脆弱であることを示すためにバージョン制約が使われることが多いです。例えば >=1.2.0 <1.2.6みたいなやつです。この場合、1.2.5は脆弱だが1.2.6は修正
Why embed developer tools in an editor? Visual Studio Code has a lot of features that make our lives as developers easier, but rightfully sticks to what it does best – being a light-weight programming environment. When we build products for the web, though, programming them is often not enough. A big part of our workflow consists of tweaking the look and feel of our products. This is where the dev
ふだんの開発でPRを出すときに考えていること - 私が歌川です の続編です。小さなPRを出す、という話がありましたが、どうやって小さくしているのか、というのを書きます。 どういうメソッドが欲しいか考える Aという情報をBという画面に出したい Aを取得するメソッドがないので、それを作る必要がある (メソッドCとする) というときに、メソッドCを作るPRをまず先に出して、マージされたら続いてCを使って得られる情報Aを画面Bに出すPRを出す、というのをやります。 実装方針を考えて既存実装を眺めてからそういう作戦を立てることもあれば、実装しているうちにメソッドCが足りないな、と気づいて別ブランチでPRを作ってそちらを先に出す、ということもあります。 このとき、1つのPRで両方やろうとすると、メソッドCの実装のレビューと、情報Aを画面Bに出す実装のレビューが同じPRで行われることになります。メソッド
最初にマイルストーンを切って、この週で設計、この週で実装、みたいなことをやるのはおすすめできない。 設計に使える時間を最初に決めた時間までしか使わないということは、どうすればいいか、考えきれてなくても作り始めているということ。 コードは書けていくので、進んでいるようにも見えるけど、問題を先送りしているだけなので、じっくり設計や作戦を詰めていれば気付ける問題に、あとのほうで直面することになる。 この問題を回避するためにはこのように作るべきであった、ということにあとで気づくと手戻りが大きくなり、こんなことをするくらいなら最初に決めておけばよかった、となることが多いと思う。 家を建てることをイメージすると、設計フェーズはここで打ち切って、手を出せるところから始めよう、といきなり柱を建てることをイメージしてほしい。 先のことを見据えると、4本の柱は長方形になっているべきという制約があるけど、そのこ
Rust 1.39 からは async/await が安定化され、非同期処理がぐっと書きやすくなりました。 Futureトレイトを自分で実装したり、loop_fnで所有権を取り回したりmap_errでエラー型を魔改造したり することはもうありません! おもむろに await していきましょう この記事は Rust 1.46 と tokio 0.2.22 に基づいています Rust での非同期処理 Rust では、非同期な計算は Future トレイトとして抽象化されています。JavaScript などでは Promise と呼ばれるものです。以前は非同期処理を扱うときに、場合によっては Future トレイトを実装する必要があることがありましたが、現在では async キーワードを使うことで簡潔に記述することができるようになりました。 async キーワードを使い、 非同期関数 async
基盤チーム所属の沖中( @okinaka )です。 「リファクタリング」という言葉、エンジニアのみなさんならご存知でしょう。 システムの振る舞いを変えずに内部を改善することを指す言葉です。 一般的に、コードの修正を指すことがほとんどですが、今回はデータベース設計のリファクタリングについてお話ししたいと思います。 絶版になってしまいましたが、データベース・リファクタリング という書籍に様々な手法が紹介されていて参考になります。英語で良ければ 原書 はまだ入手可能ですね。 データベース・リファクタリング 作者:スコット W アンブラー,ピラモド・サダラージ発売日: 2008/03/26メディア: 単行本 Refactoring Databases: Evolutionary Database Design (Addison-Wesley Signature Series (Fowler)) (
AWS Toolkit for VS Codeに、CloudWatch Logsの直近ログデータを表示できる機能が追加されました! Amazon CloudWatch Logs features now available in the AWS Toolkit for Visual Studio Code VSCodeでLambdaのプログラムを書きつつ、Lambdaをデプロイして実行。CloudWatch Logsで実行結果を確認。なんて、場面で便利に使えるんじゃないかと思います。 こんな感じでVSCodeの画面でCloudWatch Logsのログを表示できます。さっそく試してみました! 環境 VERSION Visual Studio Code: 1.48.1 AWS Toolkit for VS Code: 1.13.0 前提 本ブログではAWS Toolkitのインストール、AW
Google Best Practices for Java Libraries Google Best Practices for Java Libraries are rules that minimize problems for consumers of interconnected Java libraries. These practices come from decades of aggregated experience in maintaining open source Java libraries and are informed by many hard-learned lessons from mistakes that have been made. We have found that following these rules results in hig
Skip to the content. Geolonia 住所データ 全国の町丁目、大字、小字レベルの住所データ(277,543件)をオープンデータとして公開いたします。 本データは、国土交通省位置参照情報ダウンロードサービスで配布されている「大字・町丁目レベル位置参照情報」をベースとしていますが、「大字・町丁目レベル位置参照情報」データは年に一回更新であるのに対して、本リポジトリで配布するデータは毎月更新しています。 latest.csvをダウンロード latest.dbをダウンロード リリースノート 住所データ仕様 ファイルフォーマット latest.csv: CSV latest.db: SQLite3で読み込めるバイナリ形式 列 都道府県コード 都道府県名 都道府県名カナ 都道府県名ローマ字 市区町村コード 市区町村名 市区町村名カナ 市区町村名ローマ字 大字町丁目名 大字町丁目
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く