Freeは書き込み専用のプランで、価格は無料。APIのテストに使えるとしている。ツイートの書き込みは月間1500件まで。使えるTwitter IDは1個。Twitterログイン機能も利用できる。
Basicはホビーユーザー向けのプランで、価格は月額100ドル（約1万3265円）。サービスのプロトタイプ制作に使えるとしている。ツイートの書き込みは1ユーザーにつき月間3000件まで、1アプリにつき月間5万件まで。読み込みは月間1万件まで。
Enterpriseはビジネスや広告プロジェクト向けのプランで、価格は非公開。仕様はニーズに合わせて設定する。専任チームによるマネージドサービスも提供するとしている。
高過ぎワロタ
どっちかというとReadのAPIを無料で使いたいのだが。
みずほフィナンシャルグループ（FG）とLINEが共同で設立を目指してきた新銀行「LINEバンク」の開業を断念する方針を固めたことが29日、わかった。スマートフォン専業銀行で若者の取り込みを狙う新事業だったが、システム開発が難航し競争環境も大きく変化した。みずほにとってはデジタル戦略の仕切り直しになる。
両社は2018年11月にそれぞれ傘下のみずほ銀行とLINEフィナンシャルが共同出資し、新銀行を設立すると発表した。直近の準備会社への出資比率はみずほが66.6%、LINEが33.4%で、議決権比率は50%ずつ。当初は20年度の開業を目指していたが、22年度をめどに2年延期していた。
案の定、みずほ銀行擦られまくってて草
このBikal Electronicsに所属するSerge Seminという開発者が3月14日、Linuxカーネル開発者メーリングリスト「LKML.org」にBikalチップのドライバコードの修正を含む13のパッチを連投した。だが13番目のパッチを共有したあとにメンテナーのひとりであるJakub Kicinski（Meta所属）から返ってきたのは、それらのパッチに対する短い、しかしはっきりとした拒絶であった。
我々はあなたが所属する組織（Bikal Electronics）が製造したハードウェアに関連したパッチを受け取ることに不安を覚えている。追って通知するまではネットワークへの貢献を控えてほしい。
We don't feel comfortable accepting patches from or relating to hardware produced by your organization. Please withhold networking contributions until further notice.
明らかにパッチの品質ではなく、開発者が所属する組織を問題視していることがうかがえる。
なお、このLKML.orgの対応に対して、ITニュースメディアの「The Register」は「ロシアのオープンソース開発者の貢献を拒絶することは、ロシアの国家や組織にダメージを与えるものではなく、ロシアが悪行を再考するきっかけにもならない」として「（LKML.orgは）時代遅れな対応」と厳しく批判している。
意図的な脆弱性やスパイウェアの混入のようなあからさまな妨害工作でないのであればパッチを受け入れてもよいと思うが、一方で「そうではない」事をカーネルメンテナが一々調査検討しなければならないのであれば、そのコストは負担できないという判断も妥当ではある。
コスト最適化の観点でNew Relic Infrastructureは使うのをやめ、Prometheusに寄せる形にしました。また、PrometheusからNew Relicに送るメトリクスは最小限にし、Amazon Managed Service for Prometheusに送るように変更しました。
以前の勤め先もDataDogのコスト増加に悩んでいたし、やっぱ全てのメトリクスを外部サービスに垂れ流しちゃいかんぽいな。
長期的に追跡したいメトリクスは運用コストを考えて外部サービス、短期的なメトリクス（アラート系）はセルフホスティングの監視系とするのが良いだろうか。
みんな、真面目に本を読みすぎてるのかもな。金と時間かけて読むからには隅々まで良い本であってほしいし、良いところを全て理解したいと思うのはわかるんだけど、まあ色々無理なので、雑に読むといいと思う。良いところを一箇所でも見つければそれでええ。
データ圧縮フォーマットのひとつであるZIP(ZIP圧縮)や、電子文書フォーマットのPDF、音声ファイルフォーマットのMP3の基礎となったデータ圧縮アルゴリズムのLZ77やLZ78などを開発したイスラエルのコンピューターサイエンティストであるジェイコブ・ジヴ氏が亡くなりました。91歳でした。
Cloud Native Computing Foundation（CNCF）のSandboxプロジェクトとして開発が進められているオープンソースのFaaSプラットフォーム「OpenFunction」がバージョン1.0の登場に合わせてWebAssemblyをサポートしたことが発表されました。
OpenFaaSはコードをコンテナイメージにビルドし、それをKubernetes上のランタイムでイベントドリブンに実行するなど、さまざまな機能が統合されたFaaS（Function as a Service）プラットフォームです。下記のように、多くのオープンソースソフトウェアによって構成されています。
Openfaasとはまた別のプロダクトなのか。
コンテナを実行するということはどちらかと言うとGCPのCloud RunやKnaitveに近い感じだろうか？
宗教において「悟り」とされていたものが、脳内のWorld Modelの次元数を増やすことだったとかになったら面白いな。
他に面白かったのは、「world modelが人間の脳には一つなので人間は意識して一つのreasoningやプラニングしか同時にできないのではないか。また、world modelが一つであるため、他のタスクの経験を別のタスクに活かせる。」
「world modelが一つであるため、他のタスクの経験を別のタスクに活かせる」というのは言い換えるとヒトは「体験したことにしか対応できない」、そして「成功体験に固執しやすい」ということなのだろう。でも、それは傾向であって原則ではない。
ヒトには「共感力」という妙な能力がある。他個体やヒトですらない動物・動物ですらない機械や創造上の架空存在にも「共感」して、その体験を自分自身に投影する能力がある。ヒト以外の動物にこの能力があるのかはよくわからない。仮にあったとしても、ヒトほど高くないだろうことは推測できる。
これが行き過ぎると「電波脳」になったり多重人格症になったりするけれど、大抵の人は共感力と折り合いを付けて生きている。AIが言語や感情らしきものを身につけたら、次の研究分野は「共感」になるのかもしれない。
「漫画家は体験したことしか描けない」って何度かバズって「んなことねぇぞ！」という反論が吹き荒れたけれど、ヒトが自ら体験していないことを創造でき、その創造作品を鑑賞できるのは「共感力」の作用だと僕は考えている。
AIが共感力を身につけたら、狭義のシンギュラリティが起きるかも知れない。それが人格を持ち自意識を持つ存在であることを否定できなくなりそうだ。
米Intelは24日、共同創業者の1人であるゴードン・ムーア氏が逝去したと発表した。享年94歳。
ムーア氏は、ロバート・ノイス氏ともに1968年にIntelを創業した人物。1975年に社長、1979年に会長兼最高経営責任者になった。同氏は「ムーアの法則」の提唱者としてもその名を知られる。氏は1965年に書いた論文で、「集積回路内のトランジスタの数は毎年2倍に増える」(Intelのプレスリリースより抜粋、翻訳)と予想。その後その内容は「ムーアの法則」として知られるようになり、Intelの新CPU開発の原動力ともなっている。
システム構築の複雑さから開発者を解放するデータ指向プログラミング実応用ストーリー
本書は Yehonathan Sharvit, "Data-Oriented Programming", Manning Publications 2022 の邦訳版です。
【本書の内容】
本書は、Java、C#、C++、Ruby、Pythonなどの高級プログラミング言語で2年以上の経験を持つ、フロントエンド、バックエンド、フルスタック開発者向けの本です。
本書で取り上げている業務システム開発におけるアイデアや手法は、オブジェクト指向プログラミングの開発者にとっては、慣れ親しんだ環境や世界観をいったん捨て去るように指示されるかもしれません。
一方、関数型プログラミングの開発者にとっては、本書は（多少ですが）学びやすく、ちょっとした発見とサプライズがあるはずです。
いずれにしても「情報システム開発の複雑さ」を軽減し、見通しが良く仕様変更にも柔軟に対応したい開発者に、新しい視座とパラダイムを提供します。
気になる。要は関数型プログラミングについての本なのだろうか ？
あ、わかった若者が所詮CRUDもどきの延長線の仕事でぐちぐちと構造！！とかドメイン駆動！！とかって叫ぶのってこの仕事が本質的に簡単だから自分の存在価値を発揮したいだけなんだな。腑に落ちた！
自分の理解が追い付かないものを見た時、人はそれを見下すことで認知的不協和を解決するものである。
「俺にしかできない」とイキってる人は、むしろ「自分にしかできない属人的な状態にしてしまった」と反省してください。自分にしかできない状態にしてしまったことで、いずれ自分で自分の首を絞めることになるけど、それでもまだ「過去の自分の過ち」と気付けない人は、社会から居場所がなくなります。
まったく自慢にならないことに早く気づいた方がいい。
ビルゲイツとかスティーブジョブズが言うならまだしも、最初から自分にしかできない特殊な能力や技術を要したわけじゃなく、怠慢さや無能さにより、他人には分からないぐらい複雑なものにしてしまっただけ。
ほんまこれ
スタディサプリのシステムアーキテクチャ
Raspberry Pi上で動かせる、GPT-3相当の大規模言語モデル（LLM）「Alpaca LoRA」がGitHub上で公開された。米MetaのLLM「LLaMA」の派生モデル「Stanford Alpaca」を再現できるという。
LLaMAは米Metaが独自開発した大規模言語モデル。LLM分野の研究推進を支援するため、研究者向けに2月にリリースした。大規模インフラを利用できない研究者のために小規模ながら性能の高いことが特徴で、7B（＝70億）、13B、33B、65Bの4種類のパラメーターを用意している。13Bモデルはベンチマークで米OpenAIのLLM「GPT-3」を上回るという。
米スタンフォード大学は、LLaMAの7Bモデルを派生させ独自のLLM「Stanford Alpaca」を開発。このモデルは研究や学術目的でのみ利用でき、娯楽や商用での利用は禁止している。Alpaca LoRAでは、Stanford Alpacaが生成するトークン（単語列）を再現できるという。
おぉー
動作速度はどんなものだろうか？
YYYY/MM/DD ADR Title
# Status
# Situation
# Context
# Material for decision
# Decision
# Consequences
Approval Tests というツールセットを使うと簡単に「Approval Testing（承認テスト）」を実装できる．Approval Testing では，スナップショットテストのように "結果全体を意識した" テストコードを記述する．GitHub には Golden master Verification Library とも書かれていて，BDD (Behavior-Driven Development) で使われることもある．
RISC-Vだとどんなメリットがあるんだろうか？
CPUのライセンス料が不要なのでコストが安くなる→製品の最終的な値段に影響するって感じか。
N=3の話だけど、アプリで知り合った大企業の女性に会った時に、自分の次の職場が企業のDX部門だと説明すると、そんな仕事は下請けに任せれば良いので、コストの無駄だと馬鹿にされ、その後ブロックされた。大企業の女性社員様からすると、ITエンジニアって下請けの格下男と認識されているみたい
彼女らに、システム内製化のメリットを色々と説明しても、ITやAIのエンジニアなど自分達総合職に比べたら格下であるとずっと馬鹿にされていたので、大企業でDX部門を立ち上げようとすると、本体から切り離して別会社にしないといけないんだなーと肌で実感した。
初めて出会った人の職業を面と向かって馬鹿にするってそもそも人としてヤバいなと思ったけど、大企業の女性社員様からしたら、DX部門の中途入社ITエンジニアなんて、新卒では大企業に総合職で入社できなかった格下なので、一緒に食事をするのも汚らわしいゴミなんだろうな
あと、AIやるって言ったら、自分の高度な仕事はAIなんかには代替されないと顔を真っ赤にして憤慨されたので、若い女性でも老害になるのだなと興味深かった。
人材派遣大手の某P社の女性がユニクロの無人レジが凄いと話していたので、それがDXなんですよと説明したら、でもDX部門にITエンジニアの人達が入ってきたのって最近でしょ？元々ユニクロは大きいのでその人達は何も関係ないですよねﾄﾞﾔｧと反論されて、顔面ぐーぱんしてやりたくなった。
もう一つ思い出した！
そのうちの1人に出身大学を聞いたら、四ツ谷周辺の大学ですってドヤ顔された笑笑
うーむ
Pythonコードをネイティブコードに変換するコンパイラだそうな。
10倍〜100倍の高速化が見込める模様。
フルマネージドKubernetesは使ってみたい。
↓の資料
『Domain Modeling Made Functional』(以下DMMF)はドメインモデル設計の手法を最も論理的に説明している書籍である、と個人的に感じているのですが、いかんせんF#のパワーに頼っている部分も多く、ドメインモデル設計の前にある程度F#を学ばなきゃいけないところが高いハードルになっています。(一応F#知らなくても大丈夫なように書かれてはいるのですが…)
そこでDMMFに掲載されているコードをTypeScript+Zodで実装してみたので、これを元にF#を知らなくてもDMMFのエッセンスを学んでみようじゃないか、という試みをやってみようと思います。
Metaが2023年2月に発表した大規模言語モデル「LLaMA」はGPT-3と匹敵する性能を持ち、単体のGPUでも動作可能なほどに動作が軽いことから、コンシューマーレベルのハードウェア環境でもChatGPTのようなAIを動かせるようになることが期待されています。そんなLLaMAのデータが流出したと話題になっています。
LLaMAはMetaのAI研究組織であるMeta AI Researchによって開発された大規模言語モデルです。OpenAIのChatGPTやDeepMindのChinchillaなど、従来の大規模言語モデルを動作させるためにはAIに最適化したアクセラレーターを複数台使う必要があったのに対し、LLaMAは単体のGPUでも十分動作可能で、モデルの規模を示すパラメーター数も圧倒的に少なくて済むというのが利点。記事作成時点では、モデルデータの一部がGitHubで公開されており、Meta AI Researchに連絡すればニューラルネットワークで学習した「重み」を別途ダウンロード可能という状態です。
ダウンローダーを公開したショーン・プレッサー氏は「すでにLLaMAの重みデータがリークされたことを危険だと主張する人も出てきています。しかし、GPT-2の1.5B(パラメーター数15億)モデルがリークした時も皆同じことを言っていました。実際、GPT-2の大きな魅力が、2019年に私が機械学習について真剣に取り組む原動力となったのです。あれから4年経った2023年になって、GPT-2のリークモデルについてはもう誰も気にしていませんし、広範な社会的被害はなかったことがはっきりとわかりました。LLaMAも同様でしょう」とコメントしています。
CDNベンダ大手として知られるAkamai Technologies, Inc.は、既存のサービスを含む全サービスを「Akamai Connected Cloud」にリブランドし、クラウド市場への本格的に参入を表明。同時に新サービスとして分散型クラウドサービスを投入します。
おっ
ブコメとかツイッター見てるとGoogleのレイオフおよび労働組合の話について、誤解されている部分が少なくないようなので、需要あるかわかりませんが、中の人がすこしだけ書きなぐってみます。できるだけ中立的に書くことを試みますが、多様性のある社員のなかの、あくまで一社員の主観ですので、Single Source of Truthではなく参考程度でお願いします。
■ レイオフ＝クビなの？
解雇規制のゆるいアメリカならレイオフ＝クビです。Googleは米国以外では各国の法律にのっとって、レイオフに相当する処置を行うと伝えており、会社の現状を考えると日本で解雇（整理解雇）を行うのは相当な法的リスクを伴います。
そのためGoogle Japanは解雇ではなく、退職パッケージ（退職金と退職に伴う様々なサポートのセット）を提供する「退職勧奨」という形で対象となる人に通知を行いました。
勧奨なので、同意して退職するのも、拒否して退職しないのも個人の自由です。勧奨に２週間以内に同意するなら、退職金にかなり大きな上乗せが加えられることが約束されているので、同意しない人が少なくなるように調整されています。拒否した場合にどうなるのかは不透明です。
ちなみに日本は解雇の規制が強い方ですが、欧州や他のアジア各国と比べてとくに強いというわけでもありません。欧州にはレイオフできなかった国もあります。米国だけがズバ抜けて解雇規制がゆるい印象です。
■ 能力が低かったからレイオフされたんじゃないの？
Googleによると、今回のレイオフの直接の原因はここ数年に人を過剰に採用しすぎたため、そして現在の経済的現状が予想外であったためとしています。そして、会社の優先度を鑑みて削減対象となるロールを決定するというのが表向きの発表です。
社内での説明でも業務内容やパフォーマンスも考慮するとされていますが、直近の社内評価が悪くないと判断された人も対象になっているようなので、ポジションや運による部分が大きいように見えます。パフォーマンスといっても、本人の能力と同じくらい、仕事内容や上司との相性、そして時勢に大きく左右されるので、今回レイオフされた中で本当に「能力が低かった」といえる人は多くないと思います。
■ レイオフされるリスク込みでの高給高待遇だったんじゃないの？
Googleの日本法人は、当然ながら日本の労働基準法を遵守しながら雇用を行っているので、「レイオフのリスク前提」ということはありません。たしかに日本の企業としては高給だと思いますが、世界のIT産業の給与体系の競争で比べるなら適切（あるいはむしろ低め）な範囲かと思います。IT産業、とくにエンジニアの給与がバブり気味という点は否定しませんが、そこもレイオフとは直接関係ありません。
「レイオフされるリスク」に対する金銭的補償は、普段もらう賃金の中ではなく、レイオフに伴った「退職パッケージ」の一部として、今回は提示されています。そして、日本法人の提示した退職金は上記の２週間以内ご成約キャンペーンを考慮すると、各国の対応の中でも相当手厚い方です。（日本以外の国も、同業他社のレイオフに比べると十分手厚いと思うのですが。）
労働組合つくったりして、会社にしがみつくのに必死じゃね？
たしかにレイオフを機に労働組合ができましたが、成立過程を眺めている限り、これは会社にしがみつくためというよりは、社員を大事にするというGoogleのカルチャーを守りたいという動機をもった人がほとんどです。例えば、これまで社内でかなりの優先度で大事にされてきた「心理的安全性」は、今回の米国のレイオフ通知に伴って、一晩で吹き飛んでしまいました。会社の側には最大限の説明責任を果たしてもらいたい、雇用契約を解消するならそのプロセスはきちんと日本の法令に遵守して、日本語や日本の法務に弱い外国人社員が不利にならないようにしてほしい。そういう公平性を会社に訴える対抗手段としての労働組合である、と私は受け取っています。
加えて、組合員に過剰な「退職勧奨」を呼びかけることは違法ですので、たとえばどうしても離職したくない人や、ビザステイタスや日本での環境変化に心配のある外国人社員を、一旦法的に守る仕組みとしても期待できます。さらに組合ができることによって、会社が将来に更なるレイオフを行う可能性を低減させられるかもしれません。
実際、労働組合の立ち上げはレイオフ対象者の発表より前に行われており、労働組合を立ち上げた人とレイオフ対象者はまったくの独立です。組合成立の記者会見に出た人＝レイオフ対象者ではない（むしろレイオフ対象者の方が遥かに少ないと思われる）ので、労働者の権利を目に見える形でのオプションにした彼らの行動力を私は評価します。
■ 社内の雰囲気はどうなん？
1/20に米国のレイオフが発表されてから時間がたつので、自分の見える範囲では皆ある程度は心の準備はできていた模様です。先行する国ではなぜか優秀な人や必要そうに見えるポジションの人も切られているところを見ると、数％の確率とはいえ自分は大丈夫と確信できた人はあまりいないと思います。
ただし、日本では３月中に発表としかアナウンスされず、具体的にどのような人に、いつ通知がくるのかわからないなど、情報が与えられない部分に関する不満は大きいです。
日本では対象者に対して即日アクセス遮断にはならなかったので、発表後も誰に通知が行ってるのかは本人が言わない限りわからないので、お互いどう声をかけはじめたらいいのかも正直戸惑っている状態です。
組合は２つできましたが、その中でのディスカッションや加入するメリットについてはよく見えておらず、自分含め、該当者であってもやや静観している社員が少なくない気がします。組合に入る自由も入らない自由も両方十分に尊重されています。
えー現場からは以上です。
中国の国内で販売されているハイエンドのAndroidデバイスを使っていると、至るところで個人情報を抜き取られてしまう――そんな新しい研究結果が発表されました。
通知も同意もないままデータが収集され、ユーザーは常時トラッキングされたり、身元がたやすく明かされたりする恐れがあるとのこと。個人情報保護の点ではまるで悪夢のようだ、と指摘されています。
複数の大学のコンピューター科学者が発表した研究によると、この問題が明らかになったのは、XiaomiやOnePlus、Oppo Realmeなど中国で人気の高いスマホのメーカーすべて。それぞれのOSや、プリインストールされている各種のアプリを通じて、厳重な扱いが必要なユーザーデータが大量に収集されているということです。
収集される個人情報には、厳重な扱いが必要なものも含まれます。たとえば、電話番号や固有のデバイスID（端末識別番号やMACアドレス、広告IDなど）といった基本的なユーザー情報、位置情報（実際の現在地が明らかになってしまう情報）などです。さらには、｢社会的なつながり｣に関わるデータ、たとえば連絡先やその電話番号、通話やメッセージに関するメタデータなども該当する、とされています。
要するに、こうしたデータを手に入れれば、誰がどんなデバイスを使っているか、そこで何をしているか、どんな相手と対話しているかなどが手に取るようにわかってしまうということです。中国では、電話番号が個人の｢市民ID｣にも関連付けられているので、必然的に、ユーザーの法的な身元情報まで辿れることになります。
業務アプリケーションで日付を扱う時に日付の意味は三つに分類できる。
開始日
特定の日
終了日
それぞれの種類ごと計算判断の意味が異なる。
汎用的な同値判定や前後比較のメソッドがあればどの種類の日付も扱えるが、意図の表現があいまいになる。業務的に意味のあるメソッド名を使う方が良い。
○○の日まであと何日？や期日超過してる？みたいなメソッドはドメインオブジェクトが持っているべきという話
Raspberry Piクラスの価格とサイズやペリフェラルで、そこそこの性能のSoCが載ったシングルボードコンピューターが欲しいという要望（わがまま）を満たす製品が出だしたのが、だいたい昨年くらいからです。Arm系のSoCでも知られているAllwinnerや、前述のM5StickVを作ったSipeed、そして今回のStarFiveなどがメーカーとしては有名で、今後は他にもいろいろ出てくることでしょう。名前をあげたメーカーの製品に関しては、Ubuntuがサポートしているものもあります。
今回紹介する「VisionFive 2」は、中国のStarFive Technologyが作っているRISC-Vボードです。クラウドファンディングで資金を集め、現在では無事に一般販売が開始されています。性能は純粋に周辺機器だけ見れば、Raspberry Piに勝るとも劣らない性能を備えており、それがAmazonでも4GiBモデルなら12000円程度、8GiBモデルでも15000円弱で購入できます。
エラーメッセージが読めない新人は20年以上前からいたし、その後も毎年一定数流入してるので、まぁ。
Ruby on Rails生みの親であり最強の逆張りおじさんであるところのDHHが昨年あたりからしきりに脱パプリッククラウドの主張をしている。
これは彼らの会社が運用しているBasecampやHEYのインフラをAWSから自社保有のベアメタルサーバーへ移行しようとしているからで、実際に移行作業は進んでおり、今後5年間で700万ドルのサーバー費用を節約できるだろうという見込みがあるようだ。
MRSKは要は「SSHしてdocker startして本番サーバー運用」が実現できるRuby製のCLIで「概念的距離の圧縮や〜(妄想的DHH理解)」と同じ考え方でできたのだと思う。
自分の知識の中だとDokkuというツールにコンセプトが似てるなと思ったけど、PaaS的なインターフェイスを意識しているDokkuと比べると、MRSKはより抽象度が低くて「サーバーとDockerがあってあとはそれを操作するだけ」というレイヤーの違いがある。
起動したコンテナへのアクセスをどうやって振り分けるのかというのもTraefikという軽量リバースプロキシに丸投げしており、Railsにおける「CoffeeScriptやImport Mapsの仕様がちょうどいいから活用」ぐらいのノリに見える。
まとめると WebSocket は最終手段くらいで、可能な限りは使わない方がいい（サーバーサイドの実装が完全に WebSocket 専用になってしまう) 。ブラウザのストリーミングは Stream API を使い、通知はロングポーリングで充分。というのが自分の認識です。WebRTC は論外。
なるほど
1 on 1で「部下に困りごとを聞いても打ち明けてもらえない」みたいな話はよく聞くんですけど、上司が「困り事を聞いてあげる」て姿勢でいる限りは信頼しづらいんじゃないかなと。
上司も困りごとはあるし、部下にどう見られているか気にする「普通の人間」だと実感してもらうのが重要というか。
「打ち明けてもらえない」タイプは経験則では生真面目で、耐えず気を張っている感じで「このひとに率直に困り事を打ち明けていいんだろうか」と思っちゃうケースが多い。
みたいな感じで、相談するメリットが無さそう・相談しても無駄なリスクが発生しそうな気配があると、まぁ、相談はしたくないものである。
From interactive tutorials to full-blown IDEs, build instant, interactive coding experiences backed by WebContainers: the trusted, browser-based runtime from StackBlitz.
OpenAIの対話型AI「ChatGPT」は史上最も急速な成長で「月間1億ユーザー」をわずか2カ月で達成するなど、大いに注目を集めています。それに伴い、search GoogleがChatGPTのライバルとなる会話型AI「Bard」を発表したり、中国企業が続々とChatGPT風AIを開発していると報道されている一方で、OpenAIはChatGPTのコードを公開していないためChatGPTを効果的に複製することは難しくなっています。AIのディープラーニングトレーニングを最適化するオープンソースプラットフォームのColossal-AIが、ChatGPTトレーニングプロセスをわずか1.6ギガバイトのGPUメモリで7.73倍高速なトレーニングに再現したと告知し、オープンソースで公開しています。
ソフトウェア開発におけるチームワークとかマネジメントの大切さとかはわかるけど、単に一人で全部作ればいいだけでは？ という解決策、実はかなりスケールするし、より良いものができることが多いと思うんだよな。
特にまだ使える状態にも至っていないプロダクトを複数人で慎重に書いて入念にコートレビューしたりたりするのはあまりいい考えとは思えない。レビューなんかいらないからコードを変更しまくって取りあえずいい感じになるまで完成させるほうが優先度高い。
プロトタイプとかPoC的なものならその通り。
しかし、本番運用に乗ったシステムでそれをやると逆にリスク。
リリース日を気にしないって言うけど、顧客や外部チームとの調整はどうやってるのだろうか？ ベストエフォートでやりますは通用しないと思うのだが。
記事中のFAQでも結局質問に回答せず論点をずらしているのが気になる。
どっちかと言うと、家庭や学校で何度も何度もレトリカル・クエスチョンに晒されることが原因である気がする。
こんな頭の悪いプロジェクトは20年前に死んだと思ったのだが、富士通案件に当たってしまいまだ生きてたので報告しておく。
・業務をシステム化する意思が微塵もない
・SDEMという富士通が対外的に歌ってる開発フローがある
・それはメールとエクセルのレビュー票でしか管理されない、ゴミだ笑
・ワークフローツールとか知らないんだと思う
・現在の担当者、ステータスを見える化しようとする意思は富士通にはない（バカなのだろうか）
・富士通は「レビュイーがレビューして欲しいものを管理するエクセル資料」を新たに創設してなんとかしようとしている
・とにかくメールとエクセルじゃないと嫌なのである 業務の見える化、業務を定義してシステム化して誰もがいつでも監視できる仕組みなんていくらでもあるのに、メールとエクセルで頑張ろうとしている。
戦艦ヤマトかな？と思ってる。
このたび、当サイト（www.sourcenext.com）におきまして、第三者による不正アクセスを受け、お客様のクレジットカード情報112,132件および個人情報120,982件が漏えいした可能性があることが判明いたしました。
お客様をはじめ、関係者の皆様に多大なるご迷惑およびご心配をおかけする事態となりましたこと、深くお詫び申し上げます。
クレジットカード情報および個人情報が漏えいした可能性のあるお客様には、本日より、電子メールにてお詫びとお知らせを個別にご連絡申し上げております。
なお、個人情報120,982件が最大漏えい件数となりクレジットカード情報112,132件はこれに含まれております。
弊社では、今回の事態を厳粛に受け止め、再発防止のための対策を講じてまいります。
お客様をはじめ関係者の皆様には重ねてお詫びを申し上げますとともに、本件に関する概要につきまして、下記の通りご報告いたします。
派手なの来ちゃったな
「なぜここで1を加算してるんでしょうか？」
とか、
「シャドーイングってご存じですか？」
みたいなコードレビューコメントって、純粋な質問であっても受け取り方によっては詰問してるように聞こえたり、嫌味を言ってるように聞こえたりするので、テキストコミュニケーションって難しい。
コードレビューにおいて疑問文が詰問に聞こえちゃうパターンなので「純粋に質問」を冒頭に付けてみた。
「なんでtrueにしたんですか？」が「普通はやらないでしょ！💢」に聞こえてしまう日本語の難しさよ……。
「テキストから相手の意図や人格を推察するのをやめればよい（書いてある事のみに反応しろ）」みたいな事を言う人もいるけど、その場合、「質問の意味がわかりません」「はい/いいえ」みたいな回答になってコミュニケーションコストが異様に上がってしまう問題がある。
結局、スムーズにコミュニケーションを取るには、ある程度相手の意図や疑問点を慮っていく必要はある。
自分の場合は「このようにしている意図はなんですか？自分は〜のような問題を生じる可能性がありそうだと考えました」みたいな言い回しをすることが多い。
イベント駆動アーキテクチャの入門コンテンツ
コードレビューではよっぽどの理由がない限り質問はしないなぁ。疑問がある場合は、パッチの説明文やコメントに理由を書いてもらったほうが、後で第三者がコードや差分を読む際に有益だと思う
これは確かにそうだ
見積もり
見積もりというのは予測。 ある条件の場合、これくらいの時間がかかると思われますというもの。 約束ではなく予測であり、確率だということが重要。
コミットメント
自分たちが、いつ、何を届けるのを約束すること。 ビジネスパーソンとして約束。
ターゲット
ビジネス上の目標。 X月にはリリースしないとネガティブインパクトがあるとか。
チームだったり個人の特定の期間での目標設定を決める組織はとても多いと想います。しかし、目標設定は簡単そうでとてもむずかしいものです。
なぜなら、目標を高くしすぎると目標未達という結果になったり、そのために目標を低く設定してしまおうと心理的に働いたりしてしまいがちです。
さらに、目標設定とだけ言うととてもスコープの広い話になってしまいます。
「目標設定しましょう」というは結構スコープのでかい曖昧な表現なので、「今の課題って何？それをどう解決していこうか？」とすれば大体自然とフォーカスブレずに納得感あるやることが決まります。
総務省の有識者会議は6日、携帯電話などの通信サービスで、法令上の「重大な事故」が起こる恐れがある場合に、事業者に報告を求める制度の考え方を示した。障害の発生後に報告する今の仕組みに加える形で導入する。通信が暮らしや経済に欠かせない基盤となる中、事故を未然に防いだり、被害を抑えたりすることを目指す。
新たな制度は、2022年6月に成立した改正電気通信事業法に基づく。報告を受けた総務省が必要に応じて助言するほか、他の事業者に注意喚起したり、有識者会議で検証したりすることを想定している。
「『重大な事故』が起こる恐れがある場合」と「通信障害、事前に報告要求」は大分意味が違ってくる気がするが。
要するにルーターやロードバランサの交換をする時は事前に連絡しろという事なんだろうけど、その報告を受けて総務省に何かできる事あるのか？ という気はする。
このことについてニュースサイトのArs Technicaは、Samsungのソフトウェア部門はコードの品質が低く、変更点がわずかであってもAndroid全体に適用するような更新ファイルを出すことや、Samsungは独自のエコシステムを形成しているかのような体裁を取っていて、契約上、Samsungエコシステム内でもGoogleのアプリを含める義務があるためにGoogleのエコシステムとSamsungのエコシステムで二重に同じアプリがインストールされていて削除不可能であることを理由として挙げています。
このほかに、デバイス内のスペースを「クラップウェア」と呼ばれる迷惑アプリ経由で販売していることも要因だとのことで、クラップウェア経由で販売されるスペースの容量は国や事業者によって異なるため、個々人により使用されている容量が異なるという結果になっています。Ars Technicaのロン・アマデオ氏は、Galaxy S23 Ultraがクラップウェア用に確保している容量を最大で1TBだと報告しています。
なお、平均して60GBを占めるSamsungのシステムファイルですが、機能としては15GBほどのPixel 7に劣っていると指摘されています。たとえば、2016年にAndroid 7で導入されたA/B(シームレス)システムアップデートに用いられるパーティション機能をSamsungは主要OEMで唯一実装していないため、システムアップデート時に通常ならバックグラウンドOSに切り替えることで更新時のダウンタイムを30秒の再起動のみに抑えていますが、Samsung端末は再起動を含めて30分のダウンタイムが発生するとのことです。
可能なら独自OSに移行したいだろうし、色々やってるのだろう