「クエリ」を含む日記

■センスの無い未経験が年収300万強のプログラマとして就職して必要だったこと

学歴がよくなくて、就職が困難だったので中小 SIer で働いていた。 (プライム案件を取ってこれる分マシらしい)

レキサルティ、レクサプロ、デパスのお世話になって続けてたけど、結局は薬でどうにかできず、辞めてしまった。

参考程度だけど、未経験の人が 300万 をもらうために、どのようなスキルが必要かを、まとめておく。

ちなみにどれくらいプログラムが書けなかったかというと、競技プログラミングで努力しても AtCoder の黄色になれず青色のままってくらい。

AtCoder でいう、初心者から抜け出せないという、要するにセンスがないということなのだけど、そういう人も居そうなので、参考までに。

要するに

未経験のプログラマに対して、これだけ要求されるのだから、未経験の人は覚悟するようにという指針を提供したいので書いた。

入社時に覚悟しておかなければならない事

誓約書

基本的に、損害を与えた場合には、それを作業者が補填するという誓約書を結ぶ。

要するに、捨て駒として扱って、失敗したら賠償しろ、という事になる。

このことを認識して、失敗しないように振舞ないと、連帯保証人含めて迷惑をかける事になる。

要するに、低賃金で未経験プログラマを案件にノーリスクで送りこんで、稼ぐための手段です。

必要だったスキル

ディレクション

基本的に PL (夢想家) → PM (御用聞き) → プログラマ という環境なので、プログラマが自分でディレクションして意思決定する必要がある。

例えば、下請けの場合は、PM の御用聞きの結果の WBS に合わせないと、顧客から DM で 瑕疵担保責任がどうとか言われる。

社内開発の場合は、PL の方から直接、長時間の叱責を受けなくてはならない。

そういう不幸を防ぐためにも、自分でディレクションして、PM の決めた実態を反映していない WBS に合わせて作業するスキルが要求される。

基本的に手戻りは個人の過失になってしまうため、手戻りしないように考え抜いて意思決定をする、というのが重要になる。

これこそ、ガクチカと呼ばれる、頑張れますというスキルなので、学生時代に頑張っておけばよかったなぁ。

デザイン

こう見せたい、こう表現したい、という事を伝えるには、必然的にデザインの知識が必要になる。

創造的思考とデザインは切っても切り離せない概念で、デザインとは創造なのだから、当たり前である。

ソフトウェアアーキテクチャも、ソフトウェア設計も、コーディングもデザインと言えるかもしれない。

言語技術 (言語化能力)

顧客と 1:1 で話す事が DM でもボイチャでも突発的に発生するので、いつ、いかなる時でも論理武装していなければならない。

まぁ、顧客であったり PL であったりはキレるのが仕事なので、それに対して理路整然と説明する必要がある。

なんとなく、では納得しないし、すぐ損害賠償請求とかそういう話にいくので、答えられないと持ち帰りますとお茶を濁して、エマージェンシーになる。

後述する設計能力においても、課題を把握するための言語技術(言語化能力)は重要なファクターだと思う。

ソフトウェア設計

C/C++ のシステムプログラムはフレームワークが基本的に無いので、自分で概念を整理して、どのような変更、拡張があるかを考えて設計する必要がある。

この能力が弱いと、手戻りが発生しやすくなり、瑕疵担保責任を問われることになる。

読んだ本の中だと、ボブおじさんの本が、やっぱりしっくりくるなという個人的な感想がある。

ネットワークプログラム (C)

UDP で送ってくるデータを受けて 24/365 で停止しない WebAPI への繋ぎ込みという簡単な作業があって、振られた。

リークしてはいけないという事で malloc は禁止で、グローバル変数を利用するという変なルールがあった。

Rust で書けばいいんじゃないかなと思ったけど、Rust 書くのもシンドイし、C/C++ で、しんどくて読みづらいコードを書いた。

あとで保守する人が大変そうだけど、そういうルールを決めたのは PL だしね。

システムプログラム (C++)

なんか、特殊な PCI Express のカードからベンダーが用意している SDK でデータ引っこ抜いて Web API へつなぎ込む部分をやった。

データの中の特殊な信号を取りたかったらしい。

一応、SDK の使い方をパラ見して 1 日で作ったので、別に負担じゃなかったけど、素人にやらせるんなとは思った。

Webバックエンド (Express/Fastify + PostgreSQL)

当たり前だが、DB 作って RestAPI を生やすのは現代のプログラマにとって自然にできなければならない。

なので、新規開発のサブモジュールのバックエンドを任せられた。

だが、ORM の癖を把握したり、発行されるクエリを確認したりするのは、疲れる。 SQL を直書きするのはシンドイ。

結局 SQL を直書きすることにしたけど、あまりいい決断ではなかったと思っている。

それ以外は フレームワーク に乗ってしまっていいので、書き捨てる分には楽だった。

最近だと、TypeScript で Prisma 使うのが、型安全でよさそうだなと思っている。

Nest.js が個人的には好み。

Linux の操作 (EC2 とか)

デプロイを EC2 直でやったり ECS にしたりとしていたので、ベアメタルの知識が必要になった。

要するに systemd のいじり方とか、死活監視の仕方とか。

個人的には、クラウド嫌いなので、ベアメタルの方が安心できる。

Bind で権威DNS を管理して、postfix で絶対止めてはいけないメールサーバを管理するとかもあったけど、出来て当然ではある事だし。

Webフロントエンド (React/Vue)

会社が Webアプリ の案件を取ってきたので突っ込まれた。

未経験プログラマでも、月単価 100 万以上で顧客に請求してるんだから、会社はそりゃ儲けるだろうと思った。

会社が一人前の経験N年のプログラマといったら、その通りに振舞う必要がある。顧客に責任はないのだから。

当たり前だが、Webディレクション、Webデザイン、Webプログラミング, Webマークアップ は、全て作業者であるプログラマの仕事になる。

個人的には、これが分かれている理由が良く分からないけど、分けたい人がいるんだろう。

デザインで、CSSフレームワークを使うと、その色が出るという事で、全部 CSS は手書きしていた。

tailwind が出た現在では使っていればよかったなと思う。

結局、全く分からない中、手探りでデザインし、コードを書いて、顧客に 1 日 5 ~ 10 回リリースするという行為をした。

顧客は大手企業だったので、自社のエンジニアならもっと出来る、と叱責されまくったけど、だったら自社でやればいいじゃんと思った。

一応、今でもサービスは生きていて、ユニークユーザ数は上がっているらしい。

そして、焼き付け刃だったので、 WAI-ARIA を知らず、アクセシビリティへの配慮が足りない事が問題になってしまった。

これはなんとか保守対応にねじ込めたのでトラブルにならなかったけど、瑕疵担保責任と綱渡りだなと思った。

CI/CD 構築 (Azure Pipelines)

当たり前だが、リリースサイクルを短くしないと顧客はキレてしまうので、CI/CD を整えないといけない。

今は Github Actions とかあるけど、昔は無くて Bitrise が高いからみたいな理由で Azure Pipelines で CI/CD フローを構築した。

もう Multi Stage Pipeline になってるだろうけど、Release Pipeline が GUI からしか設定できないのが辛みだった。

IaC (Terraform)

当然だが、デプロイするためには IaC を整える必要がある。

これを知らずに、コンソールでポチポチしていたので、 IaC 出来てない事がバレた時に色々怒られてしまった。

今は CDK とか便利なものが出来てるんだなぁ。

自動テスト

本来はテストも自動テストを整えて、質保証をしてバグを減らさなければならない。

だが、テストを書くという手間を払えなかったので、人力テストしかできなかった。

一応、リグレッションテストを人力でやりまくったので、バグ発見曲線が結合テストでの IF 不一致しかない、という結果にはなったけど

自動化できれば費用が必要じゃなかったから、怠慢だと、責められてしまった。

同じような未経験の人へ

未経験でも誓約書を盾に、振られた事全部を出来なくてはならない慣習があるので、プログラマはそんなに良い職業じゃないよ。

甘い考えで、プログラマになろうと思っているのなら、考え直した方がいいです。

Permalink | 記事への反応(3) | 00:18

ツイートシェア

■anond:20220813223721

書式なしテキストとして貼り付け

「csvを読み込んで～、該当列を指定してsumifs関数を使ったんですけど～、０になるんですよ～」

新人がエクセルの使い方を隣の席の同僚に聞いているようだった

「ああ、たぶん金額のところがテキストになっているから、csvを読み込みなおして、数値に変換するか、クエリ自体をコピペして別のシートに書式なしテキストとして張り付けて、該当行をvalue関数で変換してからsumifsをつかってやるといいよ」

わたしは聞くに堪えないと思い、説明している最中の同僚の胸倉をつかみ、頬を2回叩いた

「round関数が～」、「マクロで～」、「ピボットを～」、それでも同僚は話すのを止めないので、同僚の髪の後ろの主電源を切ったのち、電源を入れなおす

蛍光灯が明滅し、セミの鳴き声が逆再生され、私の思考も溶けていく

「あたいが読み込まれる～」と新人がつまんねえことを言いながら窓を突き破り、宙へ飲み込まれていく

世界は再起動され、０と1が書き込まれ、新世界が想像されていく

わたしは消えゆく思考の中で願った

次の世界は薄っぺらい有体の駄文を切ってつないで張り付けたような世界でないことを

※お題からエクセルしか浮かばなかった

Permalink | 記事への反応(1) | 23:03

ツイートシェア

■anond:20220710234300

これたぶんアクセスが来た時に新着順の検索クエリ投げてRSS作ってるな…

普通は定期的にファイルに出力しておく（ヨドバシクラスならCDNに流しておく）もんだけど

利用者が少なくて分からんのだろうな

Permalink | 記事への反応(1) | 23:46

ツイートシェア

■ジェイ・クエリ「僕が一番ドムをうまく使えるんだ！」

そう言い残してジェイ・クエリが戦死した一方でヴュ・ジェイエスとリアクトは仮想ドムを使った。

Permalink | 記事への反応(0) | 12:19

ツイートシェア

■HTTP Cookieは命名で失敗したのか

趣旨

次のツイートにブクマが集まっていたが、論点が整理されていないようなので、主にCookieの出自について記述する。

※元ツイートとブクマ

• https://twitter.com/koba0367/status/1532861948152680448
• https://b.hatena.ne.jp/entry/s/twitter.com/koba0367/status/1532861948152680448

cookieは命名で失敗し「魔術的な」技術と勘違いされてる。実際はすごくシンプル。①サーバがSet-CookieヘッダでIDを通知する、②クライアントは以降CookieヘッダにそのIDを設定する、③それによりサーバはクライアントを区別できるようになる。ただそれだけ。もったいぶってる説明はほぼ間違ってる。

TL; DR

Cookieという単語に「魔術的な」意味など元々なかったし、本来単なるデータストアである(ゆえにセッションIDも格納できる)。元ツイートの主張はおかしいし、元ツイートが腐しているspeakerdeckの内容はそんなに間違っていない。

結論として、元ツイが「現在のCookie」の話しかしていないから論点がずれている。歴史的なCookieの在り方はデータストアだった。また、現在でも一部でデータストア的に使用されている

元ツイートの主張

• Cookieの機能はクライアントIDを指定・保存することだけ。他の機能はない
• ブコメの指摘もあたらない(データストアではない)
• Cookie(正確にはHTTP Cookie、以下同)は命名に失敗している
• speakerdeckは嘘と間違いだらけの有害コンテンツ

なるほどね。それでは1つずつ見ていこう。

CookieはクライアントIDを保存するだけのもの

現在にフォーカスを当てれば、Cookieは「基本的にセッションIDを格納する場所」と説明すれば良いが(Slideもそう書いてるよ？)、元々はデータストアである。元ツイは歴史的ファクトと現代的実装のスタンダードを混同しているように感じる。2022年に「Cookieっていうのはー、ユーザ名とか個人情報を保存しておける便利なデータストアだよ」っていうと単なるやべー奴だが、1997年から2000年ごろまでは普通にそういった実装がなされていた。性善説の時代だったのである。

「嘘だろ」と言われそうなので、1997年のRFC2109を引用する

https://datatracker.ietf.org/doc/html/rfc2109

         POST /acme/shipping HTTP/1.1
         Cookie: $Version="1";
                 Customer="WILE_E_COYOTE"; $Path="/acme";
                 Part_Number="Rocket_Launcher_0001"; $Path="/acme"
         [form data]

普通にユーザー名とか買い物かごの中身をCookieに保存している。今この実装をする奴はヤベーが、1997年はそういう時代だったのである。

         Cookie: $Version="1";
                         session_id="1234";
                         session_id="1111"; $Domain=".cracker.edu"

セッションIDの例もあるが、なんと数字4桁である。今こんなことをしたら確実に徳丸本の角で頭を殴られる。当時のインターネットがいかに性善説の上に成り立っていたか分かるだろう。

とにかく今はデータストアじゃないんだよ

この主張も誤りである。例えばja.wikipedia.orgでは、アカウント名や利用者のおおよその住所などをCookieに仕込んでいる。セキュリティ的にザルだと思うなら、ぜひ直接殴り合って欲しい。

Cookieという命名がダメ

元ツイではMagic Cookieを「魔術的なクッキー」と解釈している(なんでも魔法のようにできる多機能な……って感じ？)ようだが、ここでいうMagicとは魔術のことではないだろう。Magic NumberとかMagic WordのMagic(利用者が理解していなくても有効なもの)と考えた方が意味が通る。これはMagic Cookieの語源となったfotune cookieの語義に通じるところもある。

fortune cookieとは。文字が書かれた紙片を封入した焼き菓子である。HTTP Cookieはクライアント・サーバとも内容について問わない(紙片に何を書いてもいい)し、捨てても無視しても構わない(食べなくても割らなくても良い)ためにこの名前がついたのだろう。任意の情報をラップしたものというメタファーとして適切に思えるし、Magicという形容詞も適切であると考える。

1つあたり容量が4kBしかないのも可愛らしい。クッキーでいいんじゃないか。逆に何だったら良かったのか。

speakerdeckの内容は有害。デタラメ

そんなに間違ったことは書いていない気がするが……。現在ほとんど使われない技術が書いてあったとして、それが何……？とはなる。Slideはaxiosの使い方を示してるだけだし、2年前の記事に対して「情報が古い」ってツッコミも微妙ではある。

総括

結局何に怒って何を否定しているのかよく分からなかった。SunのX端末を使っていたということなので、最近の事情しか知らないというわけでもなさそうなのだが。

ツリーを眺めているとあまり期待はできなさそうだが、元ツイの人はもう少し丁寧な議論をして欲しいところだ。

余談

• fseekやXの実装におけるMagic Cookieについては、調べる余裕がなかった
• Cookieが実装される前のAmazon(1993～)はたしかクエリ文字列でセッションIDを引き回していた

Permalink | 記事への反応(0) | 12:35

ツイートシェア

■anond:20220521220951

参考URL続き

API編（後日投稿）に続く予定

追記・返信

今回書いた増田にも多くのブクマが付き、有難く思う。以下返信。

これは詳しい

ブクマしておく

誰得の詳しいまとめ

おつおつ！！

コメ有難う。おかげで次も書こうという気になる。

RSSがあれば、エクセルではてブが見れる

有用なツール紹介感謝（ぐぬぬ、向こうのブコメの方が多いと思いつつ）。

あとRSS一覧でいつも思うのが知ってて当然という感じでカテゴリの一覧が無い

参考ページ[FAQ]はてなブックマークの「総合」カテゴリーと「一般」カテゴリーの違いはどこにある?を載せたから大丈夫だろ、という不親切な態度は許されなかった。

はてな社員「新人くん、これ分かりやすいから見ておいて」

はてな社内の仕様書Wiki（存在するのか知らない）より詳しそう

どうもはてブ担当新しく入ったらしい

門外漢によく知ってるねと褒める時に使う言い方の事例集だ。俺は詳しいんだ。

カラースターの値段が

紫スターすごい

ギブミーカラースターとか言われたら、青1個投げるとちょうど良さそう。

全然使いこなせてなかったことを思い知る

なんかよくわからんけど参考になりそう

業務中のブクマが捗るから助かる

まだAPIの解説も残っているんじゃ（すぐに投稿できるとは言っていない）。

GitHubにでも書いたほうが良いのでは

増田への愛（執）着が勝ったが、外部リンクを数件しか貼れず注釈機能が無く字数制限も厳しい環境に投稿して良いのかという葛藤もある。

「錯綜」の解釈を間違っていて一対多の意味を取り違えた。「分散」かな。 & は予約文字というよりも値が途切れ # はブラウザの機能としてサーバに送信されない。 1d. は {2} ではなく {1} (%enc)

素人特有の、用語等への鈍感さが浮き彫りに。申し訳ない。

指摘を参考に"エントリページ"の章等を修正。URLと引数については、修正後の内容なら以下のようになることを読取っていただけるかなと。

1a例 https://b.hatena.ne.jp/entry/s/anond.hatelabo.jp/20220521220951

1d例 https://b.hatena.ne.jp/entry?url=https%3A%2F%2Fanond.hatelabo.jp%2F20220521220951

API編も期待してる

善処する（GitHubに投稿する方に気持ちが傾いてるが全く触ったことがない上に、VSCodeとWSLとgitを導入してはてなのウィジェットスクリプト解読環境も整えようなどと考えてるので、いつになるか定かでない）。

「はてなフィルター」というウェブサービスも加えて

公式のページを対象としたので含めなかった（新参で情弱なので知らなかったとは言えない）。

Permalink | 記事への反応(1) | 22:11

ツイートシェア

■[はてブ]関連ページ・RSS一覧

はてブについて、情報検索したりクエリを投げたりして調べてまとめてみた。自分用メモとして書いたもので、極少数の人しか興味を持たない内容かと思うが、読んでいただければ幸い。

公式等[1・2（参照したページURLを最後に記載。以下同様）]で詳細を確かめられず素人の憶測で説明した箇所がいくつもあり、簡潔明瞭でも網羅的でもない解説だがご容赦を。

トップページ

ホットエントリと新着エントリの一覧への導線がある。

URL

1. https://b.hatena.ne.jp/

1a. https://b.hatena.ne.jp/hotentry/{1}（引数に"all"を入力した場合、1のエイリアス）

1b. https://b.hatena.ne.jp/ctop/{1}（カテゴリトップ[3]が過去に存在していた場合、1aにリダイレクト）

1c. https://b.hatena.ne.jp/hotentry/{1}/{2}

1d. https://b.hatena.ne.jp/hotentry/{1}/daily（1cにリダイレクト。前々日か前日の分が表示される）

1e. https://b.hatena.ne.jp/hotentry/{1}/{3}(?page={4})（()内のパラメータは省略可。以下同様）

1f. https://b.hatena.ne.jp/hotentry/{1}/{3}(?of={5})

2a. https://b.hatena.ne.jp/hotentry.rss

2b. https://b.hatena.ne.jp/hotentry/{1}.rss（"all"を入力した場合、2aのエイリアス）

2c. https://b.hatena.ne.jp/hotentry?mode=rss（2aのエイリアス）

2d. https://feeds.feedburner.com/hatena/b/hotentry（2aのエイリアス）[4]

3. https://b.hatena.ne.jp/entrylist/{1}(/{3}?page={4})（ブクマ登録数の閾値を設定するオプションがあったが、2018年3月に廃止された[5]）

4a. https://b.hatena.ne.jp/entrylist.rss

4b. https://b.hatena.ne.jp/entrylist/{1}.rss（"all"を入力した場合、4aのエイリアス）

4c. https://b.hatena.ne.jp/entrylist?mode=rss（4aのエイリアス）

カテゴリ

エントリは、8種類あるカテゴリ[7]のどれか1つに自動で区分される。そのアルゴリズムは不定期に更新されているようだ[8]。区分に異議がある場合、ユーザが変更申請することもできる[8・9]。

カテゴリは2013年2月に現在の名称・分類になった[10]。分類が現在と同じ8種類になったのは、2008年11月[11]。

なお、2011年以前のエントリはほぼ全て「暮らし」カテゴリに区分されている[12]。2017年から2019年の間に何らかの障害が起きたためと思われる[13・14・15]。

エントリページ

別名、ブックマークコメント一覧ページ[16]。

なお「（ブックマーク）エントリ」という呼称は、一般的用法、はてブに登録されたURLとその付帯情報、エントリページの情報等、多様な意味で使われる。

URL等

1a. https://b.hatena.ne.jp/entry/(s/){1}（"s/"はセキュアサイトのエントリページURLに付加される[16]）

1b. https://b.hatena.ne.jp/entry/{2}（正しく処理された場合、1aにリダイレクト）

1c. https://b.hatena.ne.jp/entry/{3}（1aにリダイレクト）

1d. https://b.hatena.ne.jp/entry?url={2}（1aのエイリアス）

1e. https://b.hatena.ne.jp/entry?eid={3}（1aのエイリアス）

2. (b:)id:entry:{3}（はてな記法[17・18]）

エントリID

はてブに登録されたURLはIDと1対1対応する。IDは、当初は1から始まる連番だったが、2018年12月頃から62bit以上の乱数値になった[20]。

余談だが、かつては番号が桁繰上りするたびにキリ番ゲッターがブクマしに集っていたようだ。理由は不明だが、欠番になったキリ番もある（キリ番と前後のエントリページ参照）。

エントリ統合

URLとwebページは1対1対応するとは限らない[21][22]ため、エントリ・ブコメは容易に分散する。

その改善のため2019年2月にはてブの仕様が変更され、一定の規則でエントリが収斂されるようになった[23]。現在エントリページは、複数のエントリと1対多対応していて、対応するどのID・URLを引数にしてもアクセスできる。

1対多対応の例

参考[1]のエントリページに対応するIDを昇順にし、各IDの確認できる最古のエントリをまとめた。非公開や削除済のブクマがあるせいか、完全な日付昇順ではない。

IDが正しく認識されない場合

以下に該当するIDやURLを引数として入力すると、エントリの一部または全ての情報の取得に失敗する

• 登録されたことが無いもの
• 登録されたブクマが全て削除されたもの
• 非公開ブクマしか登録されていないもの
• 特定文字（"&"[24]"#"[25]等）を含むURL文字列
• アクセス不能になったもの[26・27・28]

ブックマークコメントページ

コメントと、それに付けられたスターの情報が表示される。

URL

1. https://b.hatena.ne.jp/{1}/{2}#bookmark-{3}

2. https://b.hatena.ne.jp/entry/{4}/comment/{1}

検索ページ

はてブの全エントリから検索可能[29]。ただし単語の区切の判定が完璧でないため、連語や複合語等が関わると上手く動かない場合がある（例えば、「更年」で検索したら「更年期障害で欠勤、認められず」というタイトルがヒットしなかった）。

URL

1a. https://b.hatena.ne.jp/search/{1}?q={2}(&sort={3}&users={4}&safe={5}&date_begin={6}&date_end={7}&page={8}&mode={9})

1b. https://b.hatena.ne.jp/t/{2}（1aにリダイレクト）

2a. https://b.hatena.ne.jp/site/{10}(?sort={11}&page={8})

2b. https://b.hatena.ne.jp/entrylist?url={10}（2aにリダイレクト）

ユーザブックマークページ

各ユーザがブクマしたエントリが一覧表示される。

URL等

1a. https://b.hatena.ne.jp/{1}/(?page={2})

1b. https://b.hatena.ne.jp/{1}/?tag={3}(&tag={3}&page={2})

1c. https://b.hatena.ne.jp/{1}/{3}(/{3})（1bのエイリアス）

1d. https://b.hatena.ne.jp/{1}/{4}

1e. https://b.hatena.ne.jp/{1}/?url={5}(&page={2})

1f. https://b.hatena.ne.jp/{1}/bookmark（1aのエイリアス）

2a. https://b.hatena.ne.jp/{1}/bookmark.rss(?page={2})

2b. https://b.hatena.ne.jp/{1}/bookmark.rss?tag={3}(&tag={3}&page={2})

2c. https://b.hatena.ne.jp/{1}/bookmark.rss?date={4}

2d. https://b.hatena.ne.jp/{1}/bookmark.rss?url={5}(&page={2})

2e. https://b.hatena.ne.jp/{1}/rss（2aにリダイレクト）

3. https://b.hatena.ne.jp/{1}/search.data(?limit={6}&offset={7}) [31]

4. (b:)id:{1}(:{4}) [17]

マイブックマークページ

前節とほぼ同様だが、利用可能なオプションが多い[32・33]。

はてなスター

ログインすると、スター情報を閲覧できる。

余談だが、カラースターの価値は緑5円・赤12円・青110円・紫890円程度のようだ[34]。

URL

1. https://s.hatena.ne.jp/

2. https://s.hatena.com/（1のエイリアス）

3. https://s.st-hatena.com/（1にリダイレクト）

参考URL

ブクマされてるURLにはIDを付記。

anond:20220521221139 に続く

Permalink | 記事への反応(2) | 22:09

ツイートシェア

■anond:20220521112442

Kindleでセールで安くなってたパワークエリの本使ってる。

分からないどころはググる精神で(割といい感じのblog記事とか出てくる)。

M言語はMicrosoftにリファレンスマニュアルがあるので、それを見てるよ。

Permalink | 記事への反応(0) | 11:36

ツイートシェア

■Excel学んでる途中

普通のVLookupやら詳しくなる前に、パワークエリ(M言語)に詳しくなってしもた。

Permalink | 記事への反応(1) | 11:21

ツイートシェア

■

Excelのパワークエリとパワーピボットを学ぼうと思ったけど、やる気がでないので洗濯することにした。

なんか、ずっと洗濯してる気がする。

Permalink | 記事への反応(1) | 08:28

ツイートシェア

■ポカリとアクエリがfusionしたら

ポカリアス

アクエリスエット

アカリ

ポクエリ

Permalink | 記事への反応(0) | 21:57

ツイートシェア

■anond:20220218165313

帳票系だったら「エクセルのお供アテンダント」ってやつが有償だけど45日は無償で使える。

2016以降だったらパワークエリってやつが使えるけど習得がそこそこ難しい

VBA使える人なら問題ないと思う

Permalink | 記事への反応(0) | 12:08

ツイートシェア

■毎日日報を２時間くらい書いてる

中小企業によくある社内SE(a.k.a マクロ屋)兼PC周り雑用をやってるんだけど、新しい上司が「全部日報に書け」とうるさい。

総務「プリンターが動かない」→用紙サイズがおかしかっただけ

上司「経緯と解決策を日報に書け」

営業「先方にメールが届かない」→先方でフィルタリングされていた

上司「経緯と解決策を日報に書け」

工場「PCの電源が入らない」→電源プラグが抜けていた

上司「経緯と解決策を日報に書け」

いや、わからんじゃない部分はあるんよ。

俺以外の人のために事例を積み上げていくのは大事だと思うよ。

でもそれも最初の１回でよくね？

溜まってきたら事例集作ってもいいしさ。

毎日毎日毎日毎日細かい細かい細かい雑用の日報書いてる暇があったら

他部署から頼まれてるマクロ作ったりクエリ書いたりしたいんじゃが。

そりゃ、お前は中途で入ってきたのに人事で無能すぎて

１年で何もわからんシステムに回されたのは気の毒だと思うよ。

なんもわからんからせめて日報いっぱい書いての見せて「ちゃんと仕事させてます」したいのもわかるよ。

でもさ、読む人が読んだら「こいつ雑用ばっかりしてるやんけ」ってなると思うよ。

日報ばっかり更新するのしんどいんだよ。

もう辞表書いて家帰って寝てろ、な？

Permalink | 記事への反応(2) | 10:50

ツイートシェア

■anond:20211204145749

後編

プログラミングを学ぼうと思い立つ

行列はVBAなんかじゃ無理っぽいし、なんかプログラミング言語を覚えようと決める。

なんでも、統計やるならRという言語がいいらしい。

最近じゃPythonというのも人気らしい。

とりあえず両方試そうということで、RのためにRとRstudioをインストール。

Pythonはanaconda

プログラミングはなんかを製作する目標がないと挫折すると聞いていたので。

深層学習というものが流行ってると聞いて、ちょっと触りを勉強したくなる。

「Excelでわかるディープラーニング超入門」

https://www.amazon.co.jp/Excel%E3%81%A7%E3%82%8F%E3%81%8B%E3%82%8B%E3%83%87%E3%82%A3%E3%83%BC%E3%83%97%E3%83%A9%E3%83%BC%E3%83%8B%E3%83%B3%E3%82%B0%E8%B6%85%E5%85%A5%E9%96%80-%E6%B6%8C%E4%BA%95-%E8%89%AF%E5%B9%B8/dp/4774194743/ref=sr_1_1?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&keywords=Excel+%E6%B7%B1%E5%B1%A4%E5%AD%A6%E7%BF%92&qid=1637482610&s=books&sr=1-1

この本は面白かったので、深層学習を目標にプログラミングを覚えよう！

後になって、これはとんでもない間違いだったことに気づく。深層学習と機械学習の違いも判らないまま、RよりPythonを先に触ることに。

教本にしたのはこちら。

「ゼロから作るDeep Learning ―Pythonで学ぶディープラーニングの理論と実装」

https://www.amazon.co.jp/%E3%82%BC%E3%83%AD%E3%81%8B%E3%82%89%E4%BD%9C%E3%82%8BDeep-Learning-%E2%80%95Python%E3%81%A7%E5%AD%A6%E3%81%B6%E3%83%87%E3%82%A3%E3%83%BC%E3%83%97%E3%83%A9%E3%83%BC%E3%83%8B%E3%83%B3%E3%82%B0%E3%81%AE%E7%90%86%E8%AB%96%E3%81%A8%E5%AE%9F%E8%A3%85-%E6%96%8E%E8%97%A4-%E5%BA%B7%E6%AF%85/dp/4873117585/ref=pd_lpo_2?pd_rd_i=4873117585&psc=1

途中まではまあなんとか。

微分って便利だな。行列計算できるの便利だなっていうところまでいったが、クラスという概念が理解できず、途中からハテナが浮かんで読み進められず。

うん、もうちょっと易しい本を探そうと思って手に取ったのが

「独学プログラマー Python言語の基本から仕事のやり方まで」

https://www.amazon.co.jp/%E7%8B%AC%E5%AD%A6%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9E%E3%83%BC-Python%E8%A8%80%E8%AA%9E%E3%81%AE%E5%9F%BA%E6%9C%AC%E3%81%8B%E3%82%89%E4%BB%95%E4%BA%8B%E3%81%AE%E3%82%84%E3%82%8A%E6%96%B9%E3%81%BE%E3%81%A7-%E3%82%B3%E3%83%BC%E3%83%AA%E3%83%BC%E3%83%BB%E3%82%A2%E3%83%AB%E3%82%BD%E3%83%95/dp/4822292274/ref=sr_1_1?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&crid=1T6BBXYJ16G6T&keywords=%E7%8B%AC%E7%BF%92%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9E%E3%83%BC&qid=1637483073&s=books&sprefix=%E7%8B%AC%E7%BF%92%2Cstripbooks%2C279&sr=1-1

なんとか読了。自信をつける。

しかし、Gitとかbashの章はさっぱり。

実は、いまだにコマンドプロンプトとパワーシェルとbashの違いが分かってない。

つづいてPyQに2か月くらい登録してみる。

https://pyq.jp/

とりあえずデータ分析コースを終わらせる。

なかなかPythonが楽しくなってきたが、クラス意味が今一つ掴めないままいったん中断。

この辺で、自分は統計に興味があってもプログラミングに興味がないんじゃないかということに気づく。

結局Excelへ戻り、PowerQueryとの出会って、再びPythonとRに回帰した話

なんだかんだもがきながら、PythonもRもモノにならず、日常のちょっとした計算やグラフを作ったりはExcelを使い続ける日々が続く。

あるいは、Excelで成形して、検定かけやすい形式にしてRで検定するとか。

Rに触れてなかったな、Rは完全に独学。「こんなことやりたいなぁ、ググってみるか、ほうなるほど」って感じ。

そんなさなか、放送大学で「Rで学ぶ確率統計」という講義があるのを知り、さっそく入学して受講。

なかなか面白かったし、PythonばっかりでRあんまり触ってなかったからいい刺激になった。

恥ずかしながら、負の二項分布やガンマ分布ってよう知らんかった。

しかし、講義は楽しかったがなにか書けるようになったかというとそんなことはなく、依然として基本はExcel。

まあ、実際csvじゃなく、手書きのデータとかをExcelに打ち込んだりする程度なんでPythonやRを使うまでもなかったというのもあるんだけど。

そんなときに出会ったのがこちら、パワークエリというもの

「Excelパワーピボット 7つのステップでデータ集計・分析を「自動化」する」

https://www.amazon.co.jp/Excel%E3%83%91%E3%83%AF%E3%83%BC%E3%83%94%E3%83%9C%E3%83%83%E3%83%88-7%E3%81%A4%E3%81%AE%E3%82%B9%E3%83%86%E3%83%83%E3%83%97%E3%81%A7%E3%83%87%E3%83%BC%E3%82%BF%E9%9B%86%E8%A8%88%E3%83%BB%E5%88%86%E6%9E%90%E3%82%92%E3%80%8C%E8%87%AA%E5%8B%95%E5%8C%96%E3%80%8D%E3%81%99%E3%82%8B%E6%9C%AC-%E9%B7%B9%E5%B0%BE-%E7%A5%A5-ebook/dp/B07SCK1ND9/ref=sr_1_2?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&keywords=%E3%83%91%E3%83%AF%E3%83%BC%E3%82%AF%E3%82%A8%E3%83%AA&qid=1637483953&s=books&sr=1-2

パワークエリを覚えたらピボット形式のExcelファイルとか、セルの結合が多用されたExcelファイルを、成形加工するのが非常に楽になった。

しかも、同じフォーマットで記録されてるデータならフォルダにぶち込んで一気にまとめ上げることも可能！

控えめにいって神！

としばらくパワークエリを礼賛してたのだけど、各ステップはPythonのpandasやRのdplyrでも出来ることに気づく。というか最初から気づけ。

こりゃ、一気に覚えちまおう、統計というより、データの前処理だなと思ってUdemyでRの動画を買ってみた。

AIエンジニアが教えるRとtidyverseによるデータの前処理講座

https://www.udemy.com/course/r-tidyverse-preprocess/

すっかりR信者になる。

それまで教本を呼んでもdplyrの便利さが今一つわからなかったのに、パワークエリで具体的にモノを作ると、dplyrに翻訳したら、すいすい。スピード10倍。

便利さにようやく気付く。

ハドリーウィッカムって神だな。

そんで、pandasに翻訳したらどうなんだろ？と思ったらもっと速いｗ

すごいなPython。

Rへの入信はたった数週間。再びPythonに興味。

機械学習へ

さて、ゼロから作るディープラーニングを再開しようと思ったけれども、そもそも、機械学習をすっ飛ばして深層学習って無茶だったと反省し、まずは機械学習に。

機械学習のエッセンス -実装しながら学ぶPython,数学,アルゴリズム- (Machine Learning)

https://www.amazon.co.jp/%E6%A9%9F%E6%A2%B0%E5%AD%A6%E7%BF%92%E3%81%AE%E3%82%A8%E3%83%83%E3%82%BB%E3%83%B3%E3%82%B9-%E5%AE%9F%E8%A3%85%E3%81%97%E3%81%AA%E3%81%8C%E3%82%89%E5%AD%A6%E3%81%B6Python-%E3%82%A2%E3%83%AB%E3%82%B4%E3%83%AA%E3%82%BA%E3%83%A0-Machine-Learning/dp/4797393963/ref=tmm_hrd_swatch_0?_encoding=UTF8&qid=1637485264&sr=1-1

で、この本がすごい。

5章あるんだけど、機械学習のアルゴリズムは5章だけなんだなｗ

それまでは何に割かれてるんだって？数式の証明とか、便利な計算法、例えばニュートン法とかラグランジュ未定乗数法とかｗ

こんだけ引っ張っておいて、いよいよ本番の第5章もゴリゴリ数式をスクリプトに落とし込んでいってるのに、「これは学習のためでscikit-learnっての使えばたった1行」っていう無慈悲ｗ

いや、ほんと数学の勉強になったし、こうやってゴリゴリやるとなんのためにクラスというものが存在するのかようやくわかった。

線形代数って便利なんだなと。行列をスカラー値のように何の気なしに扱えるようになると、あの頃苦しんでいた実験計画法、タグチメソッド、今読み直したら別の印象があるんじゃないかなと思うようになったり。

この本を読む途中、「マンガでわかる統計学因子分析編」で学んだことが理解の助けになった。

なんたる僥倖。

線形回帰、リッジ回帰、SVM、PCA、ｋ-means、クラスター分析、一気に手札が増えた。

ふたたび実験計画法

Ｐｙｔｈｏｎで学ぶ実験計画法入門　ベイズ最適化によるデータ解析

https://www.amazon.co.jp/%EF%BC%B0%EF%BD%99%EF%BD%94%EF%BD%88%EF%BD%8F%EF%BD%8E%E3%81%A7%E5%AD%A6%E3%81%B6%E5%AE%9F%E9%A8%93%E8%A8%88%E7%94%BB%E6%B3%95%E5%85%A5%E9%96%80-%E3%83%99%E3%82%A4%E3%82%BA%E6%9C%80%E9%81%A9%E5%8C%96%E3%81%AB%E3%82%88%E3%82%8B%E3%83%87%E3%83%BC%E3%82%BF%E8%A7%A3%E6%9E%90-%EF%BC%AB%EF%BC%B3%E6%83%85%E5%A0%B1%E7%A7%91%E5%AD%A6%E5%B0%82%E9%96%80%E6%9B%B8-%E9%87%91%E5%AD%90%E5%BC%98%E6%98%8C-ebook/dp/B09C89HZRV/ref=sr_1_1?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&keywords=python+%E5%AE%9F%E9%A8%93%E8%A8%88%E7%94%BB&qid=1637486019&s=books&sr=1-1

実験計画法って、fisherの古典的なやつ、ラテン方格に割り付けて、ってやつかと思ったら、線形代数使えればもうなんでもありなのな。

そこにきて、ベイズ、今まで避けてたのに出会ってしまった！！

結論から言うと、超面白い。

これ、すごいな。

Python万歳。

いいのかこんな便利分析個人でやれて。

機械学習と実験計画法がここでつながるとか、控えめにいって最高だな。

まだ読了してないので、また後日。

Permalink | 記事への反応(6) | 14:58

ツイートシェア

■anond:20211020231403

パワークエリってシングルスレッドでしか動かなかったと思うよ。

Permalink | 記事への反応(0) | 23:21

ツイートシェア

■エクセルと貧弱ノーパソ

2000名の顧客×365日のステータス管理というミッションがあり，

カレンダー形式で作ったこれをパワークエリにて

2000×365の730000行のデータに変換して管理しようとしたんだが

クエリ適用するたんびに3分ぐらい固まるのでキレそう。

i3-U7300とはいえ，タスクマネージャみたら30%しかCPU使ってないのね。

もっと使えよ。100%でもいいよ。なんで遠慮するんだよ。

Permalink | 記事への反応(3) | 23:14

ツイートシェア

■Excelに勝った気がする

数千名の顧客行×365日の列から成るデータをパワークエリでピボット解除して顧客1名ごと×365のリストを作成しようとしたのね。

そしたら上限の1,048,576 行を超えるんで一部しかできないわというメッセージが出た。

おれは勝った気がしたね。

※なんでわざわざリスト形式に変換するかというと、変換後にさらにピボットテーブルかけて月単位でグループ化することで月ごとの集計をしたいわけ。

最初からACCESSでシステム組んどけばって？

むつかしいのよ。

Permalink | 記事への反応(0) | 21:46

ツイートシェア

■anond:20211014174246

少なくとも今の日本の社会の制度は「家＝世帯」をベースに構築されていて、その「世帯」の名前が「姓」なんだ。結構根幹にかかわることなんだよ。

大した伝統じゃないとか言ったって、ちゃんとした社会制度が全国に広がった明治以降はそうなんだから、行政サービスとか公共教育とか福祉とかなんにもなく、曖昧でよかった時代とは違う。

賛成派は自分の姓が大事…というけれども、それだって親のどちらかが犠牲になって姓を統一して世帯として活動してきたから愛着が湧いたわけで、別姓後の次の世代にとってそもそも「家の名前＝姓」を大事にするという感覚はかなりロストするだろう。別姓派は、自分の姓を大事にしたかったから別姓にしたかったんじゃないのか？

姓がそもそも国家制度としてあまり重要じゃなくなれば、それこそ守る価値すらなくなると思っている。え？姓、変えたきゃ変えりゃいいやん。なんなら結婚も関係なく変えたきゃいつでも変えられる。それぐらいまで価値を落としたときに成功すると思うが、それは別姓推進派が描いているイメージじゃないと思うんだよな。

そのためには完全に個人ベースの住民データベースが構築され、それが世帯なのかどうかはその条件でクエリーしたときだけ出てくればOKぐらいまで意識と台帳を再構築しないといけない。で、おそらく賛成派はそこまで社会制度を再構築するという気概も意識もなければ知恵もビジョンもない。ただ自分の姓が大事。いや別姓OKにするってことは姓そのものを大事にする必要がないようにするってことなんだよ。たぶんそこがわかってない。それが透けて見えるからあんまり賛成できないんだよな。

もっとも反対派もそこまで反論できる人もいないし、なし崩し的に別姓にして、エイリアスもなんもない制度になってただボロボロになるんだろうなあ、って思う。

Permalink | 記事への反応(1) | 00:45

ツイートシェア

■クソプログラマーが増えてるんだが

昔からたまに話題になるクソ実装あるでしょ

例えばWebで自分のアカウント情報表示するような画面で

サーバから全員分のデータを引っこ抜いてきてブラウザ上でフィルターして自分の情報だけ表示するやつとか

引っこ抜いてきた情報にはパスワードまで含まれていてしかも平文保存されてるとか

まぁネタとしてよく盛り上がったりしたし、都市伝説だろうなぁと思ってたんだけど

最近はマジでそういう実装する奴がゴロゴロいてビックリしてる

例えばつい最近遭遇したのだと

「アカウント指定でデータ取りたいからそういうAPIよろしく」

っていうざっくりした注文すると普通にアカウントの氏名で検索して先頭の1つだけ返してくるようなAPI作りやがる

「クエリは何を投げたらいいの？」

って聞いたら

「氏名を入れてください！」

って自信満々で答えられて「はぁ？」ってなった

小学生でも「同姓同名の人いたらどうするんだろう」って思うだろうに何の疑問も抱いてない

おまけにそういう指摘したら「データベース上でアカウントの氏名をユニークにしました」とかいう対処を平気でやってくる

そりゃマジメにやるなら

「アカウントを一意に識別できるアカウントID（メールアドレスなど）で検索できるAPIをお願いします」

的な依頼をするのが正しいんだろうけど

こういう1から10まで全部指定しないといけなくなると単純にコストがかかりすぎるよね

これ1件だけなら別に良いけど、このレベルで共同作業とかになると苦痛でしか無い

自分が関わるプロダクトだとまだ品質管理できるけど、同じ社内でも発注側がそういうの分かってないままプロダクト化が進んでたりしてヤベーと思ってる

そして日本全体で考えてそういうヤバいシステムが結構あるんじゃないかっていう気がしてきてる

ちょっと前はIT土方とか揶揄されてたけどまだその頃の方が断然マシ

なんだかんだで設計する人がまともだったから上記のようなアホなことはやらないし

プログラマーもそういうまともな人の管理下にあって教育されたりもしてた

多分だけどあの頃のまともな人達はとっくに外資系なりに引き抜かれて

そういう人達が育てたIT土方のプログラマーも引き抜かれて

クソの役にも立たないIT土方のプログラマーが管理する側に回ってクソ設計して

プログラマーはプログラミングスクールで勉強してコピペ能力だけを身につけてて

そんで委託・派遣してるから教える人もいないっていうヤバい状況なんじゃないかな

土方で例えるならコンクリート混ぜるのにスマホでYoutuberのDIYを見ながら作って

その上にビル建ててるぐらいのヤバい感じ

（コンクリートって養生期間を適切に取らないといけないから天候や運搬時間に応じて水との混合比率変えたり温度管理したりとにかく大変らしいですよ）

悪いけどこれから出てくる日本製ITサービスって品質が恐ろしく低くなると思う

日本のIT系サービスは怖くて使う気になれんね

Permalink | 記事への反応(1) | 09:04

ツイートシェア

■anond:20210926192926

パワークエリでセル結合のクソシートを行列転換して克服してるサイトみて感動したわｗ

Permalink | 記事への反応(0) | 19:33

ツイートシェア

■anond:20210911135028

JSが jQuery を吸収した気がする。クエリセレクターをチョメチョメすりゃええんだろ、って思うなら

window.$ = (b, a = document) => a.querySelector(b);

window.$$ = (b, a = document) => a.querySelectorAll(b);

すりゃよくね？って思うのだけど。

https://www.buzzyvox.com/2017095496.html

Permalink | 記事への反応(0) | 17:16

ツイートシェア

■ ダミーの個人情報を作る「個人情報ジェネレーター」登場

　氏名・住所・クレカ情報など、無償で最大1万件

　ユーザーローカルが、ダミーの氏名・住所などの個人情報を自動生成するWebサービス「個人情報テストデータジェネレーター」の無償提供を始めた。最大1万行を生成し、CSV形式のファイルなどでダウンロードできる。システム開発時の動作テストやセキュリティチェックなどに使えるという。

　生成できるのは、氏名や年齢、生年月日、性別、血液型、メールアドレス、電話番号、郵便番号、住所、会社名、クレジットカード番号と期限、マイナンバーの情報。氏名は漢字・平仮名・片仮名・ローマ字などを選択でき、年齢は「20～80歳」など指定した範囲を基に日本の人口比に合わせて出力できる。

　データはCSV・TSV形式かExcelファイルでダウンロードできる。生成するデータ数は1件単位で設定できるが、1万行以上はユーザーローカルへの問い合わせが必要だ。

ユーザーローカルへの問い合わせ、ってなんかJSかなんかでローカル処理のクエリ必須、みたいに勘違いしてなんだそりゃと気になったがただの社名だった

Permalink | 記事への反応(1) | 20:54

ツイートシェア

■最近の銀行はVISAデビットの明細を口座の明細にしてくれるんだな

「なにいってんだコイツ？」と思われたかもしれないが、

銀行明細とVISAデビット明細ってこれまで20年くらい別枠扱いだったんだよ

だからExcelとかで明細を合わせる必要があったんだが、

たぶんほとんどの中小企業で今も経理のおばはんが手作業でやってるはず

Accessとかでクエリ化してるところはそこそこがんばってるとこやな

Permalink | 記事への反応(1) | 13:23

ツイートシェア

■anond:20210902202953

パワークエリを使おうという話やな

Permalink | 記事への反応(0) | 12:32

ツイートシェア

■anond:20210902202713

パワークエリやな

Permalink | 記事への反応(0) | 12:31

ツイートシェア