タグ

Pythonに関するYassLabのブックマーク (10)

  • GoogleがFlutter・Dart・Python開発チームの一部従業員を解雇

    Googleが2024年4月、FlutterDartPythonチームで働く一部のエンジニア解雇しました。Googleによると解雇理由は組織再編のためだそうです。 Google lays off staff from Flutter, Dart and Python teams weeks before its developer conference | TechCrunch https://techcrunch.com/2024/04/29/google-lays-off-staff-from-flutter-dart-python-weeks-before-its-developer-conference/ Google layoffs hit Python and Flutter teams • The Register https://www.theregister.com

    GoogleがFlutter・Dart・Python開発チームの一部従業員を解雇
    YassLab
    YassLab 2024/05/04
    "今回の従業員削減によって私たちの多くのチームに影響が生じました。多くの優秀な人材が悪い知らせを受け、多くの素晴らしいプロジェクトで貴重な人材が失われました / FlutterとDartのチームも人員削減の影響を受けた"
  • RubyとPythonの開発者コミュニティを比較してみた - Qiita

    RubyPythonの開発者コミュニティを比較してみた。 Rubyの他の可視化としてgemの依存関係ネットワークを描画してみたも公開しています。よければこちらもご覧になってみてください。 2019/01/04 23時頃 追記 Qiitaへのコメントからご指摘をいただいた通り、各言語の開発を開始した時期と公開を開始した時期が必ずしも一致していない、各言語のコミット粒度が異なる、などに注意が必要なようです。これらの点を念頭に置いた上でご覧いただきますようお願いいたします。 各コミッター毎のコミット数の経年推移 下記の追いかけグラフでは、RubyPythonのそれぞれで、全期間でのトータルコミット数が多い順から10名を選び、グラフにプロットしています。 集計上の注意点 集計に利用したデータは ruby.csv / python.csv に置いてあります コミットの集計はGithubのリポジト

    RubyとPythonの開発者コミュニティを比較してみた - Qiita
    YassLab
    YassLab 2024/02/28
    “RubyとPythonのそれぞれで、開発を開始した時期と公開を開始した時期が異なる可能性があります。そのため、「言語の開発を開始してから○年で〜」というRubyとPythonの比較に意味が無い点にご注意ください。”
  • What it was like working for GitLab

    I joined GitLab in October 2015, and left in December 2021 after working there for a little more than six years. While I previously wrote about leaving GitLab to work on Inko, I never discussed what it was like working for GitLab between 2015 and 2021. There are two reasons for this: I was suffering from burnout, and didn't have the energy to revisit the last six years of my life (at that time)I w

    YassLab
    YassLab 2024/02/10
    "Languages such as Go, Rust or Node.js might be more efficient than Ruby, but none have a framework as capable as Ruby on Rails. Python/Django might be an option, but I suspect you'll run into similar problems as Ruby/Rails...don't have any regrets working for GitLab, and would do it all over again"
  • Pythonがグローバルインタプリタロックの解消へ、マルチスレッド処理の高速化実現

    Python Software Foundationのステアリングカウンシル(Steering Council)は、Pythonのグローバルインタプリタロック(Global Interpreter Lock)を解消する方向で開発を進めていくことを明らかにしました。 グローバルインタプリタロックとは? グローバルインタプリタロックとは、その名前が示すとおりインタープリタ全体で1つのロックを持つことです。 これによりシングルスレッドのプログラムにおいては細かなロック制御が不要となって速度の向上がはかれる一方、マルチスレッドの平行性は制限されるという欠点があります。 また、スレッドセーフではないC言語などによるライブラリとの結合が容易となっています。 Pythonの標準実装であるCPythonでは、以前からグローバルインタプリタロックが採用されていました。 グローバルインタプリタロックを解消する

    Pythonがグローバルインタプリタロックの解消へ、マルチスレッド処理の高速化実現
    YassLab
    YassLab 2023/08/03
    “今後はこれらを前提にしつつ、まずは実験的なビルドモードとしてPython 3.13でno-GILビルドを追加 / ただし、ステアリングカウンシルはこの段階に達するまでに5年はかかると考えていることも明らかにしています。”
  • ChatGPTのCode Interpreterはどこまでできるのか

    この記事は2023/07/09時点での内容になります。今後のChatGPTのアップデートによってこの記事での検証結果は変化する可能性があります。 先日(2023/07/07)、OpenAIの公式Twitterアカウントから以下のアナウンスがあった。 そこで自分のアカウントの設定画面を見てみると、どうもすでにCode Interpreterがすでに利用できるようだったので、何ができて何が出来ないのか遊んでみた。 ChatGPTのCode Interpreterとは そもそもこのCode Interpreterは何ができるのか、さきほどのツイートには以下のように書かれている。 It lets ChatGPT run code, optionally with access to files you've uploaded. You can ask ChatGPT to analyze data

    ChatGPTのCode Interpreterはどこまでできるのか
    YassLab
    YassLab 2023/07/14
    “Code Interpreterは外部のネットワークから隔離されたサンドボックス環境 / そのため、以下のような処理が必要なPythonのソースコードは実行出来ない / pip installなど外部ライブラリのインストール / Web APIを呼び出す”
  • Mojoは「C言語のように速いPython」なのか - k0kubun's blog

    LLVMやSwiftを作ったChris LattnerがCEOをやっている会社が、Pythonの使用感とC言語並の性能を併せ持つ言語としてMojoをアナウンスした。 まだ手元で試せる状態でリリースされてはいないが、最大35000倍Pythonより速いという。 Mojo🔥 combines the usability of Python with the performance of C, unlocking unparalleled programmability of AI hardware and extensibility of AI models. Also, it's up to 35000x faster than Python 🤯 and … deploys 🏎 pic.twitter.com/tjT09U4F80— Modular (@Modular_AI) May

    Mojoは「C言語のように速いPython」なのか - k0kubun's blog
    YassLab
    YassLab 2023/05/06
    “AI開発のために高速なコードが書けるというのはいいものだと思うし、何よりLLVMやSwiftを作ったChris Lattnerがやっているというのがアツいところなので、正式リリースに期待”
  • 話題の ChatGPT + LangChain で、膨大な PDF ドキュメントの内容を爆速で把握する - Qiita

    話題の ChatGPT + LangChain で、膨大な PDF ドキュメントの内容を爆速で把握するPDFOpenAIChatGPTlangchain記事投稿キャンペーン_ChatGPT はじめに 記事では、ChatGPT と LangChain の API を使用して、PDF ドキュメントの内容を自然言語で問い合わせる方法を紹介します。 具体的には、PDF ドキュメントに対して自然言語で問い合わせをすると、自然言語で結果が返ってくる、というものです。 ChatGPT と LangChain を使用することで、下記のような複数ステップの仕事を非常に簡単に実行させることができます。 PDF ドキュメントからテキストを抽出して複数に分割する 分割したテキストからテキスト間の関連を表すベクターデータを作成する 作成したベクターデータをベクターストアに格納しておく ChatGPT に外部から与

    話題の ChatGPT + LangChain で、膨大な PDF ドキュメントの内容を爆速で把握する - Qiita
    YassLab
    YassLab 2023/04/23
    “本記事では、ChatGPT と LangChain の API を使用して、PDF ドキュメントの内容を自然言語で問い合わせる方法を紹介 / 具体的には、PDF ドキュメントに対して自然言語で問い合わせをすると、自然言語で結果が返ってくる”
  • pipとpipenvとpoetryの技術的・歴史的背景とその展望 - Stimulator

    - はじめに - Pythonのパッケージ管理ツールは、長らく乱世にあると言える。 特にpip、pipenv、poetryというツールの登場シーン前後では、多くの変革がもたらされた。 記事は、Pythonパッケージ管理ツールであるpip、pipenv、poetryの3つに着目し、それぞれのツールに対してフラットな背景、技術的な説明を示しながら、所属企業内にてpoetry移行大臣として1年活動した上での経験、移行の意図について綴り、今後のPythonパッケージ管理の展望について妄想するものである。 注意:記事はPythonパッケージ管理のベストプラクティスを主張する記事ではありません。背景を理解し自らの開発環境や状態に応じて適切に技術選定できるソフトウェアエンジニアこそ良いソフトウェアエンジニアであると筆者は考えています。 重要なポイントのみ把握したい場合は、各章の最後のまとめを読んで頂

    pipとpipenvとpoetryの技術的・歴史的背景とその展望 - Stimulator
    YassLab
    YassLab 2023/04/08
    “安定した状態とも言えないため今後どうなるかは定かではない / ベストプラクティスといった言葉に惑わされず、より丁寧な技術選定の上で今の自分たちにあった選択が出来るようにすべき、ということがよく分かる”
  • 近似最近傍探索の最前線

    MIRU 2019 チュートリアル http://cvim.ipsj.or.jp/MIRU2019/index.php?id=tutorial 松井 勇佑(東京大学生産技術研究所)http://yusukematsui.me/index_jp.html ベクトルの集合を前にして新たにクエリベクトルが与えられたとき、そのクエリに最も似ているベクトルを高速に探す処理を近似最近傍探索という。近似最近傍探索は画像検索をはじめ様々な文脈で用いられる基的な操作であり、速度・メモリ使用量・精度のトレードオフの中で様々な手法が提案されている。チュートリアルでは、アプローチや対象とするデータの規模に応じて近年の手法を分類し、その概観を示す。また、各手法に対応するライブラリを紹介し、大規模データに対する探索を行いたい場合にどのように手法を選択すべきかの道筋を示す。

    近似最近傍探索の最前線
    YassLab
    YassLab 2023/04/03
    “近似最近傍探索は画像検索をはじめ様々な文脈で用いられる基本的な操作 / 本チュートリアルでは、アプローチや対象とするデータの規模に応じて近年の手法を分類し、その概観を示す”
  • Some thoughts around the "is Perl code maintainable" discussion

    YassLab
    YassLab 2022/05/27
    “Note that Python's ideal/philosophy is not TIOWTDI (as is too-often straw-manned) but "There should be one-- and preferably only one --obvious way to do it.".”
  • 1