strlen() の深淵 - Qiita
あらまし strlen() という関数がある。御存知の通り、文字列の長さを算出する標準 C ライブラリの関数だ。 やってることは単純で、例えば以下のように実装できる。 size_t strlen_simple(const char* str) { const char* p = str; while (*p) ++p; return size_t(p - str); } '\0' が見つかるまでポインタを進め、初期位置との差分を返すだけだ。これで機能的には std::strlen() と同等である。 では、速度的にはどうだろう？適当にベンチマークを書いて MSVC 2022 でコンパイル＆実行するとこうなった。
ブルックスの法則 - Qiita
ブルックスの法則とは 遅れているソフトウェア開発プロジェクトに後から人員を追加しても、かえって遅らせることになる 外注に依存している企業が陥りがちなトラップではないでしょうか。 人員が増えてるのになぜ早くならないかと言うと、以下の問題があるからです。 新しい人員への教育 配置されてすぐに仕事できるわけではない。教育する人の工数もかかるので、その間開発が止まってします。 コミュニケーションコストの増大 人員が増えた分、全員の進捗把握や情報共有・意識共有に時間がかかるようになる タスクの分解には限度がある 1人だと100日かかるタスクに、99人追加したら1日で終わるかと言うとそうではないという話 人月の神話 多くの企業の工数計算で人月が使われていると思います。1人の人間が1ヶ月で完了できるなら1人月です。 この方式はもともとは建築業などの肉体労働の工数計算に使われていたところから来たと言われて
Data Version Control(DVC)でデータ分析のモデル作成を再現可能にする - Qiita
Data Version Control(DVC)とは？ データ分析や機械学習のコードを書いているときに遭遇する以下のような問題を解決してくれるツールです。 データセットの管理がつらい 例えば、Gitのリポジトリで大きい容量のデータセットを管理することは不便になりがち Githubには1ファイルのサイズ上限100MBで、それ以上はpushできない(https://help.github.com/articles/what-is-my-disk-quota/) 実験条件が微妙に異なるときのバージョン管理 ハイパパラメータ、前処理、データセットが異なるときバージョン管理は煩雑になりがち 実験を再現できるようにする工夫が必要 データセット、スクリプト、各種パラメータなどがそろっていないとモデル作成が再現できない 中間生成ファイルが階層的にあり、最終的にモデルが生成されるといった時の再現性の担保
ネットワークに基づく分散型SNS一覧(damus, nostr, Bluesky, AT Protocol, Mastodon, Misskey, Threads, ActivityPub ...) - Qiita
ネットワークに基づく分散型SNS一覧(damus, nostr, Bluesky, AT Protocol, Mastodon, Misskey, Threads, ActivityPub ...)mastodonmisskeythreadsnostrBluesky はじめに Twitterの動乱に巻き込まれ、移住先に選ばれつつある Threads が5日で1億人を突破した今日このごろ、皆様いかがお過ごしでしょうか。 Alt Twitterとしての各種サービスに注目が集まりつつありますが、それらに関しての解説記事も乱立しており、一方で、その正確性や内容には必ずしも正確ではないものもあります。 プロトコルとアプリとサービスの区別がついていなかったり、相互接続できないものが接続できると宣伝されていたり、その逆もあります。 本記事では、特にネットワークに基づいて、各種SNSを分類して説明します。
あの日見たLinuxのディレクトリやコマンドのフルネームを僕達はまだ知らない - Qiita
はじめに Linux利用歴はそこそこありますが、よく使うディレクトリやコマンドのフルネームを全て知っているかというと、そうでもないなと思ったので、今回はそれについてまとめてみました。 特にLinux初学者の方にとっては、各ディレクトリ名やコマンド名は何の略称かを知っておいた方が、覚えやすいと思うので、ぜひ参考にしていただければと思います。 注意事項 本記事では、よく使うディレクトリやコマンドの中で略称になっているもののみを取り上げています。すべてのディレクトリやコマンドを網羅しているわけではありません。 略称のフルネームがすべて明確に文書化されているわけではありません。これらの略称は、元々UNIXや他のプラットフォームで使用されていたものや、開発者やコミュニティの独自の規則や慣習に基づいています。 Linuxディストリビューションによっては、独自の命名規則や用途を持っている場合もあります。
エンジニアさん、正論ばっか吐いてないで相手を褒めてください - Qiita
昔、上司に言われた言葉 誰だって「できるだけいい仕事をしたい」と考えています。 その人なりに一生懸命コードを書いてプルリクエストを作っています。 あなたが放つ言葉は、周りの人間の心に影響を与えます。 相手のモチベーションを下げることも上げることもできます。 我々は互いに「環境」なんです。 誰かにとっての良い環境であってください。 フィードバックには信頼関係が大事 その上司は、コードレビューをする際に 以下のようなことを心がけているようです。 「ここを直してください」の前に「ここ、よく考えられてますね」を伝える できていない部分だけにフォーカスしない 「一緒に良いものを作っていこう」という気持ちでフィードバックする でも、急にそんなポジティブ人間になれない そこで、ChatGPTの力を借ります。 ネガティブなフィードバックを、ポジティブに言い換える 良いところを見つけて、褒める 冷たい敬語で
Apache Sparkの概要 - Qiita
はじめに Apache Sparkはデータの高速な処理能力や、汎用性の高さから、昨今ではクラウドのPaaS型のデータ処理エンジンに搭載されるようになってきた。たとえばAzureのサービスでは従来からAzure HDInsightにPure 100% OSSのSparkが以前から搭載されている。Azure DatabricksはSparkのクラスター管理を大幅にクラウド側に寄せ、Notebookやジョブのインターフェース等を提供する形態も出てきて多くのユーザーに利用されているようである。また、2019年のMicrosoft Igniteで発表されたAzure Synapse Analyticsは従来のAzure SQL Data Warehouseに、Sparkエンジンを搭載してオンデマンドクエリ機能を提供するとの事。さらには、Azure Data Factory内にMapping Data
半開区間の魅力 〜プログラミングでのスマートな区間の扱い方〜 - Qiita
はじめに こんにちは、kenです。 今回は「プログラミングで区間を扱いたいときは半開区間が良いよ」という話をします。 もしかしたら有名な事実かもしれませんが、友達にこの話をしたら知らなかったという顔をされたので、自分の理解を深めるためにも記事にすることにしました。 数学で区間を扱う際は実数上で考えることが多いかと思いますが、この記事では区間を考える際、整数全体の集合上での区間を考えることにします。 また以下ではleft（またはl）とright（またはr）という文字式を使って説明しますが、このときleft $ \leq $ rightという関係性は常に満たされているものとします。 半開区間とは？ 半開区間の前に、開区間と閉区間についておさらいしておきます。 開区間は(left,right)のように表され、両端点を含まないleftからrightまでの区間を表します。 一方で閉区間は[left,
配慮のできないエンジニアとの付き合い方 - Qiita
リモートワーク中ワイ ワイ「あーーー！！！」 ワイ「ストレスが溜まるんじゃ〜〜〜！！！」 ワイ「株式会社ゆめみで働くのは、ストレスが溜まるんじゃ〜〜〜！！！」 娘（7歳）「パパ、どうしたの？」 ワイ「いや、あのな？」 ワイ「パパの会社には、エンジニアが沢山おんねん」 娘「知ってるよ」 娘「社員の大半がエンジニアだもんね」 娘「200人以上いるよね」 ワイ「せやねん」 ワイ「そんで、エンジニアってのは、性格にクセのある奴が多いねん」 娘「へ〜」 娘「それで、何がストレスなの？」 ワイ「あのな？」 ズバズバ物を言うエンジニア ワイ「周囲への配慮をせずに、ズバズバ物を言う奴がおんねん」 ワイ「何人もおんねん」 ワイ「それで、周りの人たちは傷ついてると思うねん」 娘「なるほどね」 ワイ「そういうズバズバな奴らがムカつくねん」 ワイ「けしからんねん」 娘「でも、パパも昔はそんな感じだったよね」 娘「
Bashを使いこなすための必須コマンド71選 - Qiita
はじめに mkdir, ls, cp, touch, mv, rm以上のコマンドにあんまり触れていない。。。という方、もっとコマンドを使いこなしたい！という方。。。必見。 基本的だが全部網羅するには大変な基本コマンド及びショートカットを溢れんばかり71選お届けします。たくさんありますので、表題に何のコマンドか書いてあるのをご活用ください。 一部、macユーザー向けとなっていることをご了承ください。 弊社Nucoでは、他にも様々なお役立ち記事を公開しています。よかったら、Organizationのページも覗いてみてください。 また、Nucoでは一緒に働く仲間も募集しています！興味をお持ちいただける方は、こちらまで。 Ctrl を使ったショートカット 最初に、Ctrlを使ったショートカットを紹介します。 Ctrl-A 行頭移動 ↓ Ctrl-E 行末移動 ↓ Ctrl-W 直前一単語を削除 ↓
Vue3の衰退を招いたのは<script setup>とCompositionAPIかもしれない という考察 - Qiita
[6/8 12時頃追記] Vueは死んでないし殺すつもりもないし私はVueが大好きだ、誤解しないでほしい Vue3でOptions APIは消えてないし今後消えていく方向のAPIでもないし挫折した人もこっちつかって再挑戦してほしい [6/8 11時頃追記] 「俺はComposition API使えてるぞ！」「便利じゃん！何をいってるんだこいつは！」 あなたはすごい、でもVueを挫折した人の話を聞くに、Composition APIが「アタリマエでしょ？」の雰囲気の前にうまく馴染めず散っていったという話で、Composition API自体は好きです Vue3の衰退を招いたのは<script setup>かもしれないCompositionAPIという考察 ほとんど肌感であり、根拠のない妄言だと思ってもらって構わないのだが、Vue3のリリース以降Vueが流行から離れつつあり、その原因は<scr
1100万行・32GB超の巨大CSVファイルの基本統計量を4GBメモリマシンで算出する - Qiita
はじめに この記事は，Kaggle Advent Calendar 2022第6日目の記事になります。 本記事では、 32GB超のCSVデータの基本統計量を、小規模マシンでも省メモリかつ高速に計算するテクニック について解説します。 Kaggleコンペに限らず、 マシンスペックが低いため、大きなデータセットを満足に処理できず困っている 毎回行うファイル読み込みが遅いので、もっと高速化したい ⚡ といった悩みや課題を抱えている方の参考になれば幸いです。 モチベーション データ分析業務やKaggle等のコンペティションで初めてのデータセットを扱う場合、いきなり機械学習アルゴリズムを行うことはまず無く、最初にデータ観察を行うのが一般的です。 テーブルデータであれば、各カラムの基本統計量（最小値、最大値、平均、分散、四分位数）などを計算・可視化し、データクレンジングの要否や特徴量設計の方針などを検
歴代チャットボットと最近のLLMのまとめ - Qiita
LLMs The History of Chatbots ELIZA (1966) 初期の人工知能プログラムのひとつ。 ルールベースの簡単なパターンマッチングで返答していた。 心理療法士の会話を模したELIZA(DOCTOR)が有名。 PARRY (1972) PARRYは偏執病的統合失調症患者をシミュレートしようとしたもの。 ELIZA(DOCTOR)と通信し話題となった。 Jabberwacky (1982, 1988, 1997) ユーモラスな人間同士の自然な会話をシミュレートすることを目的としていた。 ユーザーとの会話の大規模なデータベースを構築し、言語と文脈を学習することができた。 プロジェクト自体は1982年から開始されていたが、当初は学習機能は有していなかった。 ローブナー賞を2005年(George)、2006年(Joan)に受賞している。 ローブナー賞(Loebner P
ChatGPTのコア技術「GPT」をざっくり理解する - Qiita
※本記事はOracleの下記Meetup「Oracle Big Data Jam Session」で実施予定の内容です。 ※セミナー実施済の動画に関しては以下をご参照ください。 本記事の対象者 これから機械学習を利用した開発をしていきたい方 機械学習のトレンド技術を知りたい方 なるべく初歩的な内容から学習したい方 はじめに Transformerの登場以降、著しい技術革新が続くここ数年、特にOpenAI社のChatGPTのサービス開始以降、おびただしい数の技術ブログや記事がインターネット上に存在する中、本記事に目を留めていただいてありがとうございます。 この勉強会では、専門用語や難解な公式を極力排除し、初学者の方々を対象に、「そもそも自然言語の機械学習ってどういうもの？」、「言語モデルって要するに何？」というところからGPTをざっくり理解することを目的としています。従って、本記事に記載のあ
pysparkでデータハンドリングする時によく使うやつメモ - Qiita
この記事について pysparkのデータハンドリングでよく使うものをスニペット的にまとめていく。随時追記中。 勉強しながら書いているので網羅的でないのはご容赦を。 Databricks上での実行、sparkは2.3.0以降, pythonは3.6以降を利用することを想定。 既存データからDataFrameの作成 # csvk形式1(spark DataFrameから書き出されたデータなど、データが複数にまたがっている場合) df = spark.read.csv("s3://my-backet/my-data/*.csv") # csv形式1(単一のファイルの場合。そもそもあまりない状況だと思うが…。状況にもよるが後にrepartion()実行を推奨) df = spark.read.csv("s3://my-backet/my-data/data.csv") # parquet形式 df
エンジニアのための刑事事件対策まとめ - Qiita
こんにちは。モロと申します。 実は数年前警察のお世話になり、数年裁判等をやって、昨年晴れて無罪放免となったのですが、そういえばその後どこにも情報をまとめていなかったことに気が付きました。 正直にいうとまったく気の進まない作業ですし、数年間これにかかりきりだったこともあり「わざわざまとめなくても誰でも知ってることでは……？」みたいな気持ちもあります。 とはいえ冷静に考えると大抵の人は一生関わり合いになることのない知識で、お世話になった界隈に対して何も残さないのも不義理という感じがしたため遅ればせながら筆を執らせていただきます。 はじめに 当記事は、実際に警察のお世話になり、数年間弁護士の方にご指導いただきはしたものの、あくまで法律の専門家でも何でもない一エンジニア（というか多少エンジニアリングをかじったデザイナー）によるもので、第三者による監修等もなされていません。 実体験に基づいて少しでも
Amazon EMRを整理してみた - Qiita
背景・目的 Amazon ERMは使用したことありますが、どのような機能があるか仕様など細かいところを把握してないため整理します。 まとめ 以下の特徴があります。 ビッグデータアプリケーション、PBスケールのデータ分析をオンプレの半分以下のコストで高速に実行できます。 カスタマイズされたEC2クラスタ、EKS、Outposts、EMR Serverlessで実行するオプションを備えた、最新のOSSフレームワークを使用してアプリケーションを構築する。 パフォーマンスが最適化されたOSSのAPI五感バージョンでSpark、Hive、Prestoを使用してインサイトを導き出すまでかかる時間を最大2倍高速 EMR NotebooksとEMR Studioの使い慣れたOSSを使用してアプリケーションを簡単に開發、視覚化、デバッグできる。 下記のユースケースで利用できます。 ビッグデータ分析 スケーラ
レガシーなインフラを改善するつもりが組織の悪者になる話 - Qiita
はじめに みなさんの職場に古いインフラはありますか？ありますよね。 SVN,CVS...ですらないファイル名駆動のバージョン管理 id/pass不明でログインできない稼働中のビルドサーバ WindowsServer200X アンタッチャブルな巨大シェルスクリプト ... 小規模の会社でサーバサイドを齧っていると、 「クラウドネイティブ」という言葉とは無縁の世界で仕事をすることがあります。 え、そんなこと一度もない？ これからもあなたの幸運が続きますように。 改善活動スタート さすがに辛いので、改善を視野に入れて地道に調査をするわけです。 えいやで滅ぼしたい気持ちをグッと抑えます。 予算確保（のためのリスクの整理） 利害関係者の洗い出し 業務のフローで必須なインフラのリストアップ いざ置き換える算段がついたら、工事の計画を練ります。 業務の影響確認 バックアップ 移行期間の周知 等々。 現実
【誰でも簡単ChatGPT、GPT-4 利用】Azure OpenAI Serviceを使ってみた with LINE Bot【Azureでより安心・安全にAI機能が使える】 - Qiita
【誰でも簡単ChatGPT、GPT-4 利用】Azure OpenAI Serviceを使ってみた with LINE Bot【Azureでより安心・安全にAI機能が使える】ChatGPTAzureOpenAIServiceGPT-4MicrosoftAIAOAI こんにちは、もっちゃんと申します。 今AIの快進撃が続いておりますね！2000年代に第三次AIブームが始まってからはや十数年、ここ数年の進化のスピードは眼を見張るものがあるのではないでしょうか。そしてその話題の中心となっているのがOpenAIやMicrosoftなどが開発を行っているChatGPT,GPT-4といった大規模言語モデルです。 特に今年に入ってからは本当にあまりにも各所でアップデートが巻き起こっていてついていくのに必死な状態ですよね（笑） また、情報を追うのと同時に実際に触っていくことも大事ですので、今回はAzure
2020年、20年前はこんな環境で開発をしていたぞ - Qiita
2020年になり、今の開発環境と筆者が社会人となった昔(2001年) の開発環境を比べてみた。 ※ 筆者が当時体験したことを元にしており、開発全てがこんな感じではないです。 ソースコード管理 今 = GitHub(Git)で管理 Gitが生まれたのは2005年 広まりだしたのは2010年くらいから(?) GitHubが生まれたのは2008年 広まりだしたのは2011年くらいから(?) 昔 = フォルダで管理 バージョンごとにフォルダを切る。。。 なので、誰がいつどんな変更をしたのかは全く分からない。。。 （ソースコードにコメントを書く） ソースコードレビュー 今 = プルリクエストでレビュー 昔 = 紙に印刷してレビュー ソースコードを印刷。 会議室に集まりコードを読み上げる。 会議室の予約が取れないと、レビューできない。 新規でなく、変更の場合、変更箇所に下線を引いてコピーする。 議事録
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
