はじめに 開発部の tasaki です。 6 月の記事(「Pythonのパッケージングのベストプラクティスについて考える2018」)では setuptools, pip, venv を使ったパッケージングのフローについて考えました。 techblog.asahi-net.co.jp 今回はモダンな開発用ツールチェーンを持つ他の言語(具体的には JavaScript (Node.js), Go, Rust あたりを意識)と似たような開発フローを Python において構築するにはどうすればよいかということを考えていきます。 はじめに 対象バージョン 備考 TL;DR (結論) pip と virtualenv の統合 (Pipenv) 概要 使い方 インストール Pipenv プロジェクトの新規作成 setup.py との併用 静的な型の検査 (mypy) 概要 設定例 使い方 Lintin
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社のコーポレートサイトはこちらです。 当ページに記載されている情報は、2023年9月30日時点の情報です。 OpenMessaging ウェブサイト(外部リンク) ヤフー株式会社(以下、ヤフー)は、異なるメッセージングシステムを統合するオープンソースソフトウェア(以下、OSS)「OpenMessaging」の開発に、2019年1月より参画します。 「OpenMessaging」は、「Apache Pulsar」「Apache Kafka」といったOSSなど、さまざまなメッセージングシステムを統合するミドルウェアとしてオープンに開発されています。異なるアプリケーション間のデータ連携を行う際、メッセージングシステムが異なると、互換のための実装コストがかかり、システムも複雑化してしまいます。「Open
この記事には、Microsoft Office Access データベースのパフォーマンスを向上させるヒントが含まれています。 これらのヒントに従うことで、レポートの実行や複雑なクエリに基づくフォームの開き方など、多くのデータベース操作の高速化に役立ちます。 データベースのパフォーマンスを向上させる最良の方法の 1 つは、一般的に使用されるフィールドのインデックスを作成することです。 インデックスを作成することで、この記事のヒントを使用して、パフォーマンスを向上させることができます。 Access によってインデックスが自動的に作成されますが、追加のインデックスによってパフォーマンスが向上するかどうかを慎重に検討する必要があります。 この記事では、インデックスの作成など、特定のデータベース オブジェクトのパフォーマンスを最適化する方法については説明しません。 詳細については、Create記
Accessの「外部データ取り込み」機能を使って、テキストデータ(CSV)をインポートする処理がかなり遅くて困っています。 インポート対象のテキストファイルサイズは約60.000KB レコード数は66,000件ほどです。 同スペックの別端末(W7 32bit)のAccess2003でインポートした場合は15秒もかからず完了していたのですが、2010でインポートすると5分ほどかかります。 インポート処理を速くする改善方法があれば教えてください。 環境 W7(32bit)、Access2010 操作手順 ・メニューから、「外部データ取り込み」画面を表示 ・ファイル名にファイル(.txt)パスを指定 ・「レコードのコピーを次のテーブルに追加する」を選択し、コンボボックスで既存テーブルを選択 事象 ・右下に「インポートしています」コメントとプログレスバーが表示され、時間はかかるが、 プログレスバー
第3回はバージョン管理システムとバージョン管理システムを利用した開発フローについて扱いました。 第4回では継続的インテグレーション・継続的デリバリーについて扱います。 継続的インテグレーションとは 継続的インテグレーションとは、コードの変更を(中央の)リポジトリに頻繁にマージし、かつ「定期的・自動的」に「ビルド・テスト」を行うという手法です。リポジトリに頻繁にマージすることで複数人での作業の衝突や競合を早期に発見し、自動化しておくことでリリースまでの時間を短縮できるといった効果があります。CI(continuous integration)と略して呼ばれることも多いです。 対象はアプリケーションだけでなく、Infrastructure as Codeといった手法(以降の連載で扱う予定)でインフラの構成をコード化している場合などでは、リポジトリから構成情報を取得してマシンイメージをビルドし、
継続的インテグレーション(けいぞくてきインテグレーション、英: continuous integration、CI)とは、すべての開発者の作業コピーを定期的に共有されたメインラインにマージすることである。1日複数回行われるのが一般的である[1]。グラディ・ブーチは1991年のメソッド[2]でCIという用語を最初に提案したが、彼は1日に数回の統合を提唱していなかった。エクストリームプログラミング(XP)ではCIの概念を採用し、1日に1回以上、おそらく1日に何十回も統合することを提唱した[3]。 開発者は変更に着手するとき、現在のコードベースのコピーを取って作業する。他の開発者が変更したコードをソースコードリポジトリに提出すると、このコピーは徐々にリポジトリのコードを反映しなくなる。既存のコードベースが変更されるだけでなく、新しいコードを追加したり、新しいライブラリやその他のリソースを追加した
デザインパターンのよさが分からない人は設計に自信が持てるようになるのか問題自分語りを少々。1 目の前にあった HTML と JavaScript と PHP と SQL が渾然一体となったコードと戦うことから始め、テスタブルなコードを自分が死なないように習得していった自分にとって、鬼門の一つは 再利用のためのデザインパターン だった。 何しろ再利用可能なコードなんてほとんど何もなかったのだ。そんなもの分かるわけがない。 ところが世の中の「ためになる本」はオブジェクト指向やデザインパターンの知識が前提になってしまっているところが結構あって、歯がゆい思いをすることもそれなりに多かった。 そんなところに、少ない設定、少ない知識でもプロダクティブな開発ができる Ruby on Rails というフレームワークが登場したことで、自分にできることが広がった。2 Rails の支援していないもののうち、
Originally written in: English • Русский (авторский перевод) Translated by readers into: Deutsch • Español • Français • Português do Brasil • Svenska • Tiếng Việt • తెలుగు • 日本語 • 简体中文 • 繁體中文 • 한국어 Read the original • Improve this translation • View all translated posts 多くの人は、私が実際に持っている知識量より遥かに多くのことを知っていると思い込んでいる。それは悪い事ではないので文句を言っているわけではない。(世の少数派の人達は、努力して資格を得ているにもかかわらず、逆の偏見に苦しめられている。それはイケてない。) この記
この記事は、社内向けに書いた資料を公開の許可を得て加筆修正したものです。 記事中の具体例やサンプルコードはJavaScript/TypeScriptで書かれていますが、内容自体は言語にかかわらず使えます。 同僚の @shisama にも手伝っていただきました。 はじめに 命名について 条件式について 関数について 変数・定数について コメントについて 2020/11/02 ついに完結! はじめに 読みやすいコードは、コメントがなくても文章を読むように理解できます。 逆に、読みにくいコードはコメントがあってもさっぱり意味がわかりません。 文章を読むように理解できるコードを書くために普段気をつけていることや、コードレビューの際に重点的に見ているところをまとめました。 普段から読みやすいコードを心がけている方にとっては何も目新しい物はなく、当たり前に意識しているであろうことばかりです。 特にプロ
Pythonで並列処理・並行処理を提供する標準モジュールは数多くあり、初めてだと違いを理解するのは困難です。この記事では、それぞれの違いについて調べました。 threadモジュール(Python 2), _threadモジュール(Python 3) かつてPython 2にはthreadモジュールという複数のスレッドを扱うためのモジュールが存在していましたが、Python 3でdeprecated扱いになりました。一応_threadモジュールという名前で残っています。公式でも述べられているように、一般には、thread/_threadモジュールではなく、より高レベルなthreadingモジュールの使用が推奨されるようです。 threadingモジュール threadingモジュールは、先述の通り、複数のスレッドを扱うためのモジュールです。thread/_threadモジュールより高レベルと
スクラム とは、最近、特にソフトウェア開発の分野でよく使われているバズワードです。この概念は、1995年のOOPSLAでJeff SutherlandとKen Schwaberにより提唱されました。自己組織的なチーム構成と短いスパンの持続可能な繰り返し作業に重点を置くもので、複雑なソフトウェア製品やプロジェクトを扱うためのすっきりとした軽量なフレームワークです。 シンプルで軽量な性質を強みとするスクラムですが、これを導入している企業の約半数が正しく実践できていないと思われます。では、一見すぐに使えそうな手法なのに、実践するのが非常に難しいのはなぜなのでしょうか。その理由と、これを確実に成功させるために講じるべき対策を見ていきましょう。 1. 組織の賛同が得られていない どういう タイプの企業であろうと、何かを変えようとすれば必ず直面する最大の課題であると言えるのが、これです。スクラムも例外
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは。言語サポート(Node.js)チームの伊藤(@koh110)です。 Node.js v10 も10月にLTSとなり async/await によるフロー制御は当たり前のように利用されるようになってきました。JavaScriptの非同期処理は async/await から覚える人も今後増えていくでしょう。今回はそんな非同期処理について、社内での事例を交えて記事を書いていこうと思います。 index Promise 化がなぜ重要なのか ユーザーに promisify をさせる落とし穴 Road to Promise まとめ Promise 化がなぜ重要なのか ちょうど3年前のアドベントカレンダーで、今後はいろいろなモジュー
リストボックスで複数の項目を選択可能にするには、リストボックスのMultiSelectプロパティを設定します。標準では「fmMultiSelectSingle」が設定されています。 fmMultiSelectSingle fmMultiSelectMulti fmMultiSelectExtended 標準のfmMultiSelectSingleは、単一選択です。fmMultiSelectMultiまたはfmMultiSelectExtendedを設定すると、複数の項目を選択可能になります。両者は複数の項目を選択する方法が異なります。 【fmMultiSelectMulti】 項目をクリックすると選択できます 別の項目を選択するときもクリックだけです CtrlキーやShiftキーは必要ありません すでに選択している項目を再度クリックすると 選択状態が解除されます 【fmMultiSelec
コードレビューを「コードの欠点を指摘する行為」だと無意識に思っている人を見かけるけども、そういうふうに認識しないほうがチームにとって良いですよ、という話。理由は以下。 レビュワーの方がレビュイーよりも実力が無いといけない、という認識と結びつきがち チームの若いメンバーがレビュワーになりづらくなる 古株のメンバーやリーダーの書いたコードがレビューされなくなる レビューで指摘された項目がない = (指摘された欠点が無いということなので)良いコードという図式になりやすい レビュワーが欠点を指摘するあまり攻撃的なレビューをしてしまうことがある 逆にレビュワーがレビュイーに遠慮してあまりレビューしなかったりする レビュワーが誰でもわかる間違いしか指摘できなくなり、建設的な議論が起こらなくなる コードレビューが機能不全に陥る原因の一つが、コードレビューに対する基本的な認識がずれていることだと思う。 じ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く