Redisは2024年3月20日、次のバージョン（Redis v7.4）以降、これまで採用してきたBSD 3条項ライセンスから、RSALv2（Redis Source Available License）もしくはSSPLv1（Server Side Public License）のいずれかを選択するデュアルライセンスに移行することを発表した。
RSALv2はRedisの機能拡張であるRedis Stackなどで採用されているライセンスで、ソフトウェアを商品化したり、マネージドサービスとして他者に提供することができない。ライセンス、著作権、その他の通知を削除したり隠すこともできない。
またSSPLv1はMongoDBなどが採用しているライセンスで、ソフトウェアを「サービス」の一部としてサードパーティが利用できるようにする場合、修正されたかどうかにかかわらず、そのソースコードをすべて公開する必要がある。公開範囲はユーザーがサービスのインスタンスを実行できるようにするすべての管理ソフトウェア、ユーザーインターフェイス、API、自動化ソフトウェア、監視ソフトウェア、バックアップソフトウェア、ストレージソフトウェア、ホスティングソフトウェアなどが含まれる。
このため、組織内でのRedisの利用についてはこれまでと同様だが、Redisをクラウドサービスなどで提供する場合は制限が適用されるケースが出てくることになる。
またこれにともない、製品名として「Redis」または「for Redis」という記述を使用することもできなくなる。製品の説明で「Redis」という名前を使用したり、Redisと互換性がある、または以前のバージョンのRedisに基づいていると記述することはできる。
当時、jQueryは「サイズが大きくてパフォーマンスが悪い」ものとして厄介払いされようとしていました。 bundlephobiaによると[3]、ミニファイされたjQueryのバンドルサイズは85.1kb、GZIPされたものは29.7kbです。読み込みまで遅い3G回線なら0.59s、4G回線でも34msかかるそうです[4]。
現在いちからWebサイトを作ろうとするなら、フロントエンド開発者ならNext.jsなり、RemixなりReactのフレームワークを立ち上げて作るでしょう[5]。しかし、そうするとなんと、10年前のJQueryをCDNで読み込んだサイトと似たような問題を抱えることになります。 Reactは「サイズが大きくてパフォーマンスが悪い」です。
Reactを使うときはreact-domを一緒に使います。bundlephobiaによると[6]、ミニファイされたreact-domのサイズは130.2kb、GZIPされたものは42kbです。読み込みまで遅い3G回線なら0.84s、4G回線で48msかかるそうです。
この記事を書くために調べてちょっと驚きましたが、ReactはjQueryよりも重いのです[7]。
株式会社ユリ電気商会（本社：大阪市北区・代表取締役：木内 正人）は、2024年2月29日に「Kaki Pi（カキパイ）」としてプレスリリースした開発中の小型コンピュータのブランド名を「Kakip（カキピー）」に改定し、今後のシリーズに展開していくことを発表しました。
Kaki Piは発表後、短期間で多くのメディアやSNS上で取り上げていただき、様々な方面からご期待の声もいただいております。話題として取り上げていただく中で、たとえ法的な制約がなくとも、その名称により他社製品との混同が生じたり、将来的な販売店での取り扱いや企業ユーザーでのご採用に影響を与えたりする可能性がある、と弊社は判断致しました。
発売前の現段階でブランド名を変更しておくことが上記のような将来目標の実現の為に適切な措置であると判断し、入念なリーガルチェックを経て「Kakip（カキピー）」という名称に改定することといたしました。
つまりレビュアーに承認を求めることは、「却下すべき理由を探す」ことを求めているのである。 そして「却下すべき理由を探す」ということは、その事柄に対して批判的・悲観的な立場に立つことと同じである。 「保障プロセスとして機能するレビュー」において、レビュアーは間違いなく批判者である。 レビューで批判的立場から却下されるということは、そのレビューが保障プロセスとして機能していることの表れともいえる。
※あくまでも＜事柄＞に対しての批判であり、レビュイーの＜人格＞への批判は求められることではない。
その前提を踏まえた上で、レビューを依頼するときには「承認をもらいにいく」（支持してほしい）のではなく、自分とは違う視点から「検証してもらいにいく」（見落としを見つけてほしい）というマインドでいること、それがレビュアーに対して優しさを期待することに諦めがつく気の持ちようではないかと思う。
また、レビュアー側も「保障プロセスとして機能するレビュー」にするために批判的立場からコメントすることをあらかじめエクスキューズしておくことで、不都合な衝突を起こすリスクを減らすことはできるだろう。
「行政指導でここまで踏み込んだ文書は、あまり見たことがない。次こそは許しませんよ、というメッセージだろう」
総務省は3月5日、SNS「LINE」や検索サービス「Yahoo! JAPAN」などを運営するLINEヤフーに行政指導を行った。その指導内容を記した文書を見た通信業界関係者は、驚きの声を上げた。
LINEヤフーは2023年9～10月、LINEの利用者や取引先の情報など約51万9000件を外部に漏洩させていた。総務省はこのうち2万件以上が電気通信事業法上の「通信の秘密」の漏洩に当たると判断した。
具体的な指導項目として、LINEヤフーの親会社に50％出資する韓国のIT大手、NAVERとのシステムの切り離しや、グループ全体のセキュリティガバナンス体制の強化などを要請。その取り組み方針などを4月1日までにとりまとめたうえで、今後少なくとも1年間は、四半期ごとに総務省に対応状況を報告することを求めている。
行政指導に当たって総務省がまとめた10ページに及ぶ文書には、苛立ちすら感じ取れるような厳しい言葉が並ぶ。
「旧LINE社に対しては、（中略）アクセス管理の徹底等も含めて行政指導を行っていたにもかかわらず、なおもアクセス管理の不備を一因とする本事案を招いた」
「電気通信事業全体に対する利用者の信頼を大きく損なう結果となったものであり、当省として極めて遺憾である」
さらに、委託先であるNAVER側への適切な管理・監督を機能させるため、親会社も含めたグループ内における経営体制の見直しの検討にまで言及している。
goqite (pronounced Go-queue-ite) is a persistent message queue Go library built on SQLite and inspired by AWS SQS (but much simpler).
goqite (Go-queue-ite と発音) は、SQLite 上に構築され、AWS SQS からインスピレーションを得た永続メッセージ キュー Go ライブラリです (ただし、はるかに単純です)。
SQLiteを永続層に持つメッセージキューライブラリ。Goで実装されている。
米Microsoftは3月12日（現地時間）、「Visual Studio Code」用の「Unity」拡張機能を一般公開した。昨年8月からプレビューテストが続けられていたが、ようやく正式版として利用できるようになった。
「Unity」拡張機能は、Windows/Mac/Linux環境の「Visual Studio Code」で「Unity」コンテンツを開発するために必要な機能をまとめたツールキット。同社はすでに、「Visual Studio」向けに「Unity」開発のプラグインとして「Visual Studio Tools for Unity」を提供しているが、Mac/Linuxをカバーする「Visual Studio Code」でもそれに迫る生産性を享受できる。
3月も半ばになり、暖かい日も増えてきました。これだけ暖かくなってくると、ちょっとしたアプリで少し特殊なネットワークフレームを流したり、普段使わないネットワークプロトコルを試したくなりますよね。でも本番環境でそれをやってしまうと、変質者としてしかるべき場所に通報されてしまいます。そこで今回は他人に迷惑をかけずに隔離されたネットワークテスト環境を構築できる「mininet」を使って、お縄にかからないようにしてみましょう。
EU首脳は最近、RISC-Vベースのチップ開発を推進するためのイニシアチブをいくつか開設した。これは、加盟国が半導体の開発／製造を外国企業に依存していることを懸念する声に対応するためのものだ。近年では世界的な半導体不足によって、サプライチェーンに混乱が生じ、半導体主権の重要性が浮き彫りになっていることから、こうした懸念がさらに高まっている。
RISC-Vは、オープンソースの命令セットアーキテクチャであり、どの企業にも所有されていない。このためEUにとっては、優れた柔軟性と安全性を実現することが可能な、魅力的な選択肢となっている。
Valero氏は、「英国のEU離脱や、ソフトバンクによるArm買収の後、EUには、欧州独自のプロセッサが存在しなくなるという問題があることが分かっていた。だがそれは、7年前にRISC-Vが登場するまでのことだった。RISC-Vは欧州をはじめ、世界中のあらゆる企業がプロセッサを作ることができるという可能性を開いた。米国や欧州、中国が命令セットを決定するのではなく、グローバルな命令セットであるからだ」と述べる
2023年12月1日から働き始めた株式会社令和トラベルを3月19日付けで退職します。1984年4月1日から社会人として働き始めてから9社目の会社でした。9社の中で最も在籍期間が短かった会社となります。
私自身は、今年の11月で65歳になります。ウェブサービスの業界で働き続けるとしたら、API仕様ファーストおよびE2Eテストによるテストファースト開発を経験するエンジニアを増やしていければと思っています。もちろん、私自身もソフトウェア開発を続けたいのは以前と変わりません。しかし、私自身が正しいと思わない方法でソフトウェア開発を続けたくなかったので退職することにしました。
単体テストでDBに依存すべきじゃない → じゃあスタブに置き換える → 現実とテストコードが一致しなくなってあぼーん みたいな話よくあるつらさ
今回は、昨年11月に開催した、テストとリファクタリングのためのワークショップの中で行ったライブコーディングの準備をするにあたって困ったことについて記載します。
しかし長年の間に、このコミュニティ中心のアプローチは変化してきている。Ubuntuは今でもエンドユーザーが使いやすいディストリビューションのままだし、大手ベンダーが手掛けるLinuxの中では、いまだにデスクトップLinuxの火を消さないよう強力にサポートしている唯一のディストリビューションなのだが、Ubuntuが今一番使われているのは、クラウドや、サーバーや、IoTの分野だ。
CanonicalはLinuxの将来に影響を及ぼそうとしてきたが、成功した部分もあればそうでない部分もある。例えば2011年には、デフォルトのデスクトップ環境に新しいLinuxデスクトップである「Unity」が採用された。 その目的は、Linuxデスクトップだけではなく、スマートフォンやタブレットでも使えるインターフェースを生み出すことだった。
[...]そこで制作されたのが、今回紹介する「Moralerspace」。「monaspace」に高品位な日本語フォントを組み合わせてあり、日本語テキストが混じってもバランスのとれたレンダリングが行えるのが魅力だ。全角空白の可視化といった工夫も施されているので、ソースコードに全角空白が混じってコンパイルが通らないといった、日本語環境にありがちなミスを未然に防ぐこともできる。
ライセンスは「SIL Open Font License 1.1」。比較的縛りが緩く、個人利用・商用にかかわらず無償で、Webサイトに埋め込むだけでなく、改変して派生フォントを開発したり、アプリやゲームなどに組み込むこともできる。
登氏は「日本にICT人材がいない」という課題の根本原因として、「米国といった“先輩たち”との環境の違いがあるのではないか」と指摘する。その違いは2つに絞られ、1つは「コンピュータ／プログラミングが自由に試行錯誤できる環境があること」、もう1つは「ネットワークの試行錯誤ができる環境があること」だという。
「これらは日本のICT環境においても2000年代に見ることができた。それを発展させなかったために、昨今では外来製品を使わなければならない状況となっている」（登氏）
「米国の先人たちは、夜になると法律や数学、化学、哲学などを学んでいた。これが超正当派の人材育成に大いに関係がある。プログラミング言語、メモリ、プロセス、カーネル分離などのアイデアは突然出てきたのではなく、こういった文系的学問からも派生しているように思える。日本人もおそらく一緒で、本格的ではなくても、3割くらいはこういった文系的学問に投じてもいいのではないか」（登氏）
「第一に試行錯誤できる環境を作ること、第二に文系的学問を尊重すること。だいたいどんな企業も、文系的な人たちが、“けしからん”支配をしている。でも、そういう支配をしている人の頭の中には、こういう大変良い知識も隠されている。技術者も、大変“けしからん”文系的支配的人間と交流を深める必要がある。これによって、いよいよ技術者と経営／企画側との意思疎通が図ることができ、共通の利益が得られる。これが今後、日本で成されるべきものだと思う」（登氏）
1：MicrosoftはWindowsにそれほど興味がない
2：Steamによるゲームの発展
3：一部のディストリビューションの使いやすさがようやくユーザーに伝わった
4：Linux用ソフトの検索とインストールが容易になった
5：インドで人気が高まっている
用途がプログラミングメインならLinuxの方が楽な場面は多いし、ゲームしないならLinuxでいいんじゃないか
株式会社ユリ電気商会（本社：大阪市北区・代表取締役：木内 正人、以下「ユリ電気」）は、昨今急速に市場が拡大しているAMR（Autonomous Mobile Robot）やHSR（Human Support Robot）等において、ロボット制御の課題である搭載コンピュータの能力不足と計算コスト増大などの諸問題を解決するべく、強力なAI性能を持った小型コンピュータ製品を開発しました。本製品はそれらの用途で多用されるSBC（Single Board Computer）の標準的な形状を採用し、置き替えや設計資産の活用が可能です。本製品は2024年4月末に発売、量産を開始する予定です。
「Kaki Pi」は世界的にロボットやIoTで利用されているSBCの標準的な形状で設計しています。そのため、既存のAMRやHSR、IoTで使われているSBCを大幅な構造変更をせずに置き替えられ、機能や性能向上させることを可能としています。SBCに果物の名前をつける業界の風習を踏襲し、近年輸出を拡大している日本の代表的果物「柿」を名前に配しました。「Kaki Pi」はハイエンド製品を含めた今後のシリーズ展開も目指しております。
具体的な利用シーンとしてAMR/HSRなどの小型自律型ロボットやドローン、CCTVや生産設備のビジョンセンサ、ホビーロボットや大学や高専などの学術研究を想定しており、年間3,000台の生産を目標としています。
米国に本拠地を置くOrbicは、日本でフィーチャーフォン型の端末を発売する。同社日本法人であるJapan Orbicのダニー・アダモポウロス社長が明かした。
同機は、フィーチャーフォン向けに開発されたKaiOSを搭載している。KaiOSは、Mozillaが開発を中止したFirefox OSの後継コミュニティが手掛けるオープンソース版OSから派生しており、海外では、フィーチャーフォン型の端末に採用されることが多い。JOURNEY Pro 4Gは、メニューを日本語化できるほか、テンキー操作による日本語入力にも対応している。MWCのOrbicブースに展示されていた端末でも、その動作を確認できた。
そして春節もあけた今週、さっそくAlibabaがとんでもないトーキングヘッドモデルを引っ提げて登場したかと思えば、Microsoftの中国チームがとてつもないLLMをリリースした。それが「BitNet 1.58Bits」だ。
もともとMicrosoftはかねてから「1ビット量子化」の研究を続けて来た。しかし、32ビット浮動小数点での計算が主流な時代にはあまりに野心的で荒唐無稽なプロジェクトに見えていたのは否めない。しかし、現在、大規模言語モデル(LLM;Large Language Model)は8ビット、4ビットで量子化されるのが当たり前になり、量子化しても性能劣化はある程度まで抑えられることも知られるようになった。
昨年10月に発表した「BitNet」は、多くの人々が他のことに気を取られていてほとんど話題にならなかった。
そんな中、満を持して発表された1ビットLLMの性能に関するレポートは、衝撃的と言っていい内容だ。論文のタイトルも堂々と「The Era of 1-bit LLM(1ビットLLMの時代)」としている。
この表によると、BitNetはLlamaよりも3倍高速でしかも高精度ということになる。
PPLは「困惑」の度合いを意味する数値で、低いほど「困惑してない」ことになる。Llamaよりも性能劣化してないどころか性能は上がっている。
また、各種ベンチマークにおいても平均点は同規模のBitNetがLlamaを上回っている。しかもBitNetは規模が大きくなるほどLlamaに対して優位に立つようになっている。
この圧倒的なスピードの秘密は、BitNetが文字通り「1ビットで処理している」からだ。
通常、LLMをふくむディープラーニングされたニューラルネットは巨大な行列の積和演算(掛け算と足し算)を必要とする。
推論時も学習時もそうだ。
しかし、1ビット、つまり、行列の中身が0か1しかないのであれば、全ての計算を加算演算のみにできる。
加算と乗算では計算速度も負荷も段違いに異なるため、これだけのスピードの差が出ている。また、当然ながらメモリ効率も高い。
非常に驚異的なことが書いてあるのだが、残念ながらBitNetによるLLMの実装とモデルはまだ公開されていない。
だから彼らの主張が本当かどうかはまだ誰にもわからないのだが、BitNetTransformerの実装だけは公開されているため、腕に覚えがあるエンジニアなら自分でトレーニングコードを書いて確かめることができる。
いずれにせよ、 この論文が本当だとしたら、とんでもないことが起きることになる。
しゅごい
next.js, Astro, Remixは使わない。next.jsとAstroは大好きなのだが、社内向けとか個人用とか小さいアプリに使うにはあきらかに恐竜であると思う。Remixは大好きではない。
■ 実際に使ってるもの
- esbuild
- esbuild-server
[...]こんな感じなのでtsxも必要。あとはreactとかreact-domとかも適宜入れる。Tailwindが必要ならtwindあたりが楽。自分用とか社内ツールならMVP.cssあたりで楽するのもよい。
ルーティングはwouterを使おう。大抵の用途でこれで困らないはず。
■ Next.jsは認知負荷が高い
- ありとあらゆるキャッシュがOpt-in
- 無効化できないキャッシュも存在する
- 知らないと訳の分からない挙動をする
■ Next.jsはサーキット最速
- Next.jsは
- 決められたコースを
- 潤沢な予算と
- 最高のチームによるサポートを受けながら
- サーキットを最速で走る
- F1マシン
■ おまえにNext.jsは必要ない
- 自分のアプリがDOMの組み立てに何msかかっているか分からない
- →おまえにNext.jsは必要ない
- バックエンドの処理に何msかかっているか分からない
- →おまえにNext.jsは必要ない
- 別ドメインへのアクセス時、名前解決に何msかかっているか分からない
- →おまえにNext.jsは必要ない
■ じゃあなにがいいのか？(個人的なオススメ)
- Server Side Rendering がしたい
- → Remix
- Server Side Generation がしたい
- → Astro
- Client Side Rendering でいいや
- 1画面でいい •
- → Vite + React
- ルーティングが欲しい
- ここが2024年の分岐路
■ 2024年のSPA戦争
- Vite + TanStack Router plugin
- 2023/12/23にv1.0になったばかり
- タイプセーフなルーティングができる
- Remix SPA mode
- 2024/02/20にStable Release
- ファイルベースルーティングとしてセットアップされたVite + React Routerとして使える
- SPAで始めて、後からSSRできる
[...]しかしながら講演は2010年のものであり、オンラインゲームはこの10年余りで進化しています。
この辺りの進化の話を簡単にまとめつつ、オンラインゲームの同期方式の選び方を紹介します。
表題のとおりなんですが、私は仕事のスタイル上、1〜2年くらいで現場を移っていて、とくにスタートアップだとこうしたガイドラインの類が存在しないことがあるので、毎回（要請があれば）そのチームや状況に特化した形で書いてきました。これまではその都度イチから書いていたので、どこかにまとめておきたいと考えて、GitHub に載せておくことにしました。
■ メリット1 作らない機能についてキッチリ議論できる
一般的な一覧には“作る機能”しか記載しませんが、FMには“作らない機能”も含まれます。そのため、「リクエストされたけど作らない機能も含めて、ここに載っているものが全てです。この時点で漏れている機能があれば言ってください。」とコミュニケーションできます。「作る機能」ではなく常に「作らない機能」で議論が紛糾するため、この方式は大きな威力を発揮します。
■ メリット2 機能の優先順位（実現のステップ）がわかる
FMは“機能の優先順位”がついているので、「システム全体でこれだけの機能があります。とはいえ、段階的に実現していくので、まずはこの機能から作成します。来年時点ではこれだけの機能しかありませんが、業務まわりますか？」と時間軸を意識したコミュニケーションが可能になります。
■ メリット3 機能全体を俯瞰できる
一般的な機能一覧は証跡とすることを目的としているため一覧性など気にしませんが、FMは機能全体を俯瞰するため“一覧性”を高めています。実はこれが重要で、全体像が見えると心理的な安心感が高まるのです。常に全容が把握しやすい状態を作ることが、コミュニケーションのツボであり、この方式の狙いです。
強磁性体と反強磁性体の特性を併せ持った「第三の磁性体」として存在が期待されていた「Altermagnetic」(アルター磁性体)が初めて確認されました。アルター磁性体は、新種の磁気コンピューターの製造などに役立つことが期待されています。
研究チームは光がどのようにテルル化マンガンに跳ね返るかを測定し、結晶内部の電子のエネルギーと速度を測定しました。これらの電子をマッピングしたところ、アルター磁性体のシミュレーション結果とほぼ一致することが明らかになっています。電子は2つのグループに分かれることで、結晶内部での電子の異常な動きを可能としており、これがアルター磁性の特性の源になっていると研究チームは指摘しました。
科学系メディアのNew Scientistは「アルター磁性体の特性を用いることで、コンピューターのハードディスクドライブ(HDD)の記憶容量を増大させることができる可能性があります。市販のデバイスには強磁性体材料が詰め込まれているため、外部磁場の干渉に弱いという特性があります。アルター磁性体の場合、既存のものよりも高密度に磁性体材料を詰め込むことができるようになる可能性があります」と記しています。
AI 環境が目まぐるしく変化する昨今において、デベロッパーは大規模言語モデル（LLM）を使用するアプリケーションを構築するうえでさまざまな課題に直面しています。特に、従来から LLM の実行に必要だった GPU の不足は深刻なハードルとなっています。この投稿では、デベロッパーが Google Cloud のフルマネージド開発環境である Cloud Workstations 内で直接、CPU とメモリ上でローカルに LLM の力を活用できる新しいソリューションを紹介します。このチュートリアルで使用するモデルは Hugging Face、具体的には「The Bloke」のリポジトリにあり、CPU または低電力 GPU で実行できるようにするための量子化手法に対応しています。この革新的なアプローチにより、GPU が不要になるだけでなく、シームレスで効率的なアプリケーション開発の可能性も開かれます。「量子化モデル」、Cloud Workstations、localllm という新しいオープンソース ツール、一般提供リソースを組み合わせて使用することで、十分な機能を備えた開発ワークステーション上で既存のプロセスやワークフローを活用して、AI ベースのアプリケーションを開発できるようになります。
■ 主な機能と利点
GPU なしでの LLM の実行: localllm を使用すると、CPU とメモリ上で LLM を実行できるようになるため、不足状態の GPU リソースを使用する必要がなくなり、パフォーマンスや生産性を損なわずに LLM をアプリケーション開発ワークフローに組み込むことができます。
生産性の向上: localllm では、Google Cloud エコシステム内で直接 LLM を使用します。このインテグレーションにより開発プロセスが合理化され、リモート サーバーのセットアップや外部サービスへの依存に伴う複雑さが軽減されます。そのため、GPU の管理が不要になり、革新的なアプリケーションの構築に集中して取り組めます。
費用対効果: localllm を利用することで、GPU のプロビジョニングに伴うインフラストラクチャ費用を大幅に削減できます。Google Cloud 環境内の CPU とメモリ上で LLM を実行できるため、リソース使用率が最適化され、結果として費用が削減され、費用対効果が向上します。
データ セキュリティの向上: LLM を CPU とメモリ上でローカルに実行することで、機密データを管理下に置くことができます。localllm を使用すると、データ移転とサードパーティのアクセスに伴うリスクを軽減して、データのセキュリティとプライバシーを強化できます。
Google Cloud サービスとのシームレスなインテグレーション: localllm は、データ ストレージや ML API などのさまざまな Google Cloud サービスと統合されるため、Google Cloud エコシステムの可能性を最大限に活用できます。
shadcn/ui compatible react aria components that you can copy and paste into your apps. Accessible. Customizable. Open Source.
shadcn/ui と互換性のある反応 aria コンポーネント。コピーしてアプリに貼り付けることができます。 アクセス可能。 カスタマイズ可能。 オープンソース。
WindowsやMacなどのデスクトップPCでVisual Studio Code（以下VSCode）を利用して開発をする場合、同じローカルマシン上でDockerコンテナのLinux環境を起動し、VSCodeのターミナルで接続して操作することは、開発環境としてよくあることだと思います。
これと同じことをWebブラウザ版のVSCodeでも実現する、すなわちWeb版VSCodeが同一Webブラウザ上にWebAssembly化したDockerコンテナを起動し、Web版VSCodeからローカルマシンとして接続し利用できる、実験的実装を実現したVSCodeの拡張機能「vscode-container-wasm」が登場しました。
この開発をオープンにしないという考えが自分にフィットしている、そのため自社で公開しているオープンソースは基本的にこの考えを適用している。
理由としてはオープンな開発は負担が大きすぎると感じているのが一つある。小さな会社はリソースが少ないため、オープンな開発をやっていくのはとてもむずかしい。
もう一つの理由は、なにかあればパッチではなく、フォークして開発してもらうという方針を取りたいというのがある。自分たちでコントロールできる範囲で開発していきたいう考えが強いからだ。
開発をオープンにしないオープンソースという考えは、小さな企業がオープンソースを公開するときの方針の一つとしてはありだと思う。
状態を持たない処理ならStaticでええやろという話は同意できるけど、それをもって時代がStaticおじさんに〜は流石に意味不明。
目次
- タスク把握は諦めた
- 定点観測としての隔週1on1（30分）
- その人のキャリアとライフ（人生）を知る
- みんなの前で褒める
- 「僕の時間はすべて君たちのためにある。忙しいとか気にするな。使い倒せ」
- 会社の（人事）制度や仕組みについて、理由もセットで説明する
- 自社の魅力と会社（と僕）が「できないこと」を説明する
- 本人と話し合いながら適切な目標設定をする（挑戦項目を入れる）
- 許容できる失敗を想定しておく
- （必要なら）気軽に頭を下げる
- 警察官、裁判官として適切に機能する。意図も説明する
- 評価に対する基本スタンスを伝える
- 方針やスローガンなど「良い感じの話」を月に一回以上話す
- ときどきプレイヤーとして圧倒的なパフォーマンスを見せる
- 理屈を持ってたくさん（量）のフィードバックする
- そもそも、マイナスなことを言わなくて良いように日々の仕事をやらせる
- そもそもMBOなどの「目標制度」を誤解させない
- 有給休暇の話題は”こちらから”出す
- 期末にひとりづつメッセージを送る
- おまけ：判断や指示に、すべて理由を説明できるようにしておく
米国の研究機関であるAperture Internet Laboratoryは、Linuxで動作する中国のインターネット検閲システム「グレートファイアウォール」（Great Firewall、GFW、金盾）をオープンソースで実装したシステム「OpenGFW」を発表した。このシステムは家庭用ルーターで使用可能なほど柔軟で使いやすく、GFWを個人レベルで実現することを目指している。
OpenGFWは、IPとTCPのデータを完全に再構築する能力を持ち、HTTP、TLS、DNS、SSHなどのネットワークプロトコルを解析できる。特に、Shadowsocksなどの完全に暗号化されたトラフィックの検出機能や、Trojan-killerに基づいたTrojanプロトコルの検出機能が含まれている。
IPv4とIPv6の両方をサポートし、ネットワーク負荷を複数のコアで分散処理する機能や、exprに基づいた強力なルールエンジンを搭載している。Webベースのインタフェースや機械学習を用いたトラフィック分類機能の開発も進行中である。
ソフトウェアやクラウドサービスなどの設定に用いるコンフィグレーションファイルはどんどん複雑になってきており、利用者が望む詳細な設定を、一般的なコンフィグレーションファイルのフォーマットとして使われているJSONやYAML、XMLプロパティリストなどの形式で正確に記述することは難しくなってきています。
Pklはそうしたコンフィグレーションを正確かつ分かりやすく記述するために開発された、特定目的用のプログラミング言語だと説明されています。
純粋な「個人ブログ」、「日記」というものはもうGoogleはインデックスしない。
「しない」は言い過ぎかもしれないが、ほとんどしない。いつからだかはよくわからない。よくわからないが、おれがそれを実感したのは、去年「ジャパンモビリティショー」に行ったときのことだった。いや、正確には「行く前」だ。いったいどんなショーなのか、どのくらい混んでいるのか、どんな雰囲気なのか、ちょっと検索してみたのだ。終わりごろに行ったので、いくらかわかるだろう、と。
しかし、出てくるのは公式サイト、ニュースサイトの記事（といっても、プレスリリースだけみたいなのも多い）、出展者の公式サイト……。もちろん、「感想」や「日記」というフレーズを足してみたりしても、もう個人の日記なんて出てこないんだよ。なんかムキになって探したけど、本当に出てこなくて、「ああ、もう本当にインデックスされねえんだな」と思ったよ。結局、Xで入場列の長さのポストを見たくらいだ。
「monaspace」は、GitHubがプログラミング用途に開発したモダンな等幅フォント。ライセンスは「OFL-1.1 license」で、現在「github.com」のプロジェクトページから無償でダウンロードできる。
本フォントは比較的縛りの緩い「OFL-1.1 license」ライセンスとなっているので、日本語フォントと組み合わせた派生の登場も期待できそうだ。今後の展開に期待したい。
コードエディタのVisual Studio Code（以下、VSCode）は2024年1月のアップデートで、「Hey Code!」と音声で呼びかけると、Copilot Chatが起動する新機能が追加されたことが明らかになりました。
日本放送協会(NHK)は、総務省の会合において、将来NHKインターネットサービスの必須業務化が改正放送法で決まった場合の基本的な考え方を説明。負担のあり方について、「必須業務として実施する以上、インターネットでの提供についても、受信契約の対象として相応の費用負担(受信料)をお願いすることになる」との考えを示した。NHKプラスのような動画サービスだけでなく、NHK NEWS WEBなどの報道サイト等も対象となる。なお、テレビ受信料を支払っている場合は、追加の負担なくネットサービスを利用できる。
負担のあり方については、「必須業務として実施する以上、インターネットでの提供についても、受信契約の対象として相応の費用負担(受信料)をお願いすることになる」と説明。
そして、「その際は、テレビを設置し、NHKの放送を受信できる環境にある方に契約をお願いする従来の受信料制度との整合が重要と考えている」、「いわゆるペイウォールのような、料金を支払う事で初めて利用できるかたちとは異なる方法で実施する想定」と話した。
スマートフォンやPCなどの通信端末を取得・保有しているだけでテレビ設置した場合と同等に考えるのではなく、あくまで、「視聴する意思が外形的に明らかになるような何らかの積極的な行為が費用負担の要件」としながら、費用負担の方法の詳細については「技術的な課題も含め、現在様々な方法を検討中。時期が来たら、改めて説明をしたい」と述べた。
OSCHINA の方針で 1 月 31 日の閉鎖を予告していたスラドと OSDN だが、一転方針が変更されサーバーを停止せずに受け入れ先を募集することとなった。
これにより、両サイトとも当面はこれまで通りアクセス可能だ。ただし、スラド編集部はアピリッツとの契約で更新作業を続けてきたが、契約は 1 月 31 日で終了となるため、更新に関して本日をもって停止する。なお、保守や管理のために何らかの案内等が更新される可能性はある。
スラドまたは OSDN の受け入れを希望する企業の方は、編集部 (osdn_api@appirits.com) までご連絡いただければ、詳細が決まり次第ご連絡差し上げる。末筆となったが、OSCHINA への譲渡後 1 年以上にわたって編集部との契約を続けていただき、引き続きメールアドレスも使わせていただいているアピリッツに感謝したい。
「読む人のことを考える」
これだけ。
僕は、ドキュメントを読むのが苦手。すぐに混乱する。
ひとつの段落が長いと混乱する。正確に書いてくれているんだろうけど、書き手目線で細かくばーって書いてあって、読み手がそこから自分の目的の情報を探し出さないといけない状態だと混乱する。
あと、ページの階層が深かったり、リンクでジャンプしまくったり、用語がぶれていたり、文章が複数の意味に捉えられる書き方になっていたりすると、混乱する。
他にも、このあたりに気をつけてる
- いきなり詳細の話から始まると混乱するので、全体を説明してから詳細に入るように書く
- 段落は長いと読めないので、3〜5行にする
- 違う意味にとられないように気をつける（赤いシャツのシミ、は、シャツの赤いシミ、ともとれるから、シミが赤いシャツについている、って書くとかそういうの）
- 受動態だと主語が分かりにくいので、能動態にできないかを考える
- 二重否定を避けられないか考える
- 複雑な説明は、文章だけじゃなくて、図を描く
- ページ階層が深くなりすぎないようにする
- リンクは文章中よりも、参照リンクの項目にまとめたほうがいいかどうかを考える
- 同じことをできるだけシンプルに書けないかを考える
- ここに書かなくてもいい情報を書いてしまわないように気をつける
とか、そういう風にして、自分が読んでも混乱しないドキュメントにしてる。
ソフトウェア開発にもまたアート的なクリエイティビティが求められつつも、ビジネスとしての利益追求では再現性が同時に求められることが多い。従って、多くの現場ではソフトウェア開発を再現性の高い労働集約的な仕事に転換しようとする。むしろ、そうしなければ開発組織の規模をスケールさせることができない。
ここで言うクリエイティビティの有無とは本質的に技術力とイコールであり、その具体性の表出はフレームワークやプログラミング言語を使うことではなく、逆にそれらを生み出す側にある。このレベルの技術力を持つ人材を集め続けるのは無理があるが、一方で技術力を求めなければ採れうる人材の幅は圧倒的に広くなる。
エンジニアリングに話を戻して具体的にするならば、あるチームの仕事の中に社内で使っているサードパーティ・ライブラリの基盤に新機能追加のPRを出すタスクと、単にアプリケーション側でフレームワークの新しい機能を使うように書きかえるだけのタスクが同列に存在しているような状態を想像するといい。全員が同じレベルで全てのタスクに着手できない状態である。開発者ごとに相対的な認知負荷に対する許容範囲の差分があり、メンバー間の認知負荷の差分が結果的に技術的負債を生み出す原因になる。また、この手の負債は属人性がボトルネックになることで回収されないままになる。*2
これらは、いずれにしても同一のチームで求められるクリエイティビティのレンジと、個々人が対応できる認知負荷の容量のバラつきが大きすぎることが原因である。認知負荷は他者の発揮するクリエイティビティの発露によって生まれる結果であり、この差分が大きくなっている箇所をチームとして分割せねばならない。
その際には、育成や指導でメンバーのクリエイティビティの下限をどうにかして上げようとするのではなく、構成されるメンバーに応じて上限にリミットをかけるためにチームを分割・構成するべきだ。
プロパティベーステスト（Property based testing）は、テスト対象のコードが満たすべき特定の特性や条件（プロパティ）が、さまざまな入力値に対して一貫して成り立つかどうかを確認する方法です。
- 自動化されたテストケース生成
- エッジケースの探索
- 効率的なテストプロセス
- 継続的なテスト更新
面接そのものは実際そんな大事じゃないのかなと改めて思ったりもしました。
書類からある程度ペルソナができていて、その検証作業のような気がします。
1時間やそこらで人間の深いところなんてわかんないですし、騙そうと思えばいくらでも騙せると思いますし。
IT企業の採用において、「迷ったら見送る」「採用基準は下げない」というのが鉄則みたいです。
■ スキル
- Githubアカウント見て、コード見るのが一番早くて安心感がある
- 論より証拠
- 仕事より雑に書いてたとしても、それでもレベル感は把握できる
- アーキテクチャー/テストの意識があるか
- ただ特定のアーキテクチャーへの思想が強すぎるとか、TDDを絶対視してるとかは危ないかも
- 原理主義の傾向がある人は避ける
■ コミュニケーション
- HRTの原則で行動できているか
- 有害性が高い人は真っ先に弾きたい Brilliant Jerk（優秀だが攻撃的で周りに悪影響を与える人材）は避ける
- 受動的すぎる人もなるべく避けたい
- が、エンジニア採用だと、優秀な人ほど面接の印象が受け身に見えがち
- 実績で判断するのが良いか
- 質問に対して、適切な回答が来る、というのは大事
- 質問がわかりづらいパターンもあるので、そこはふりかえる
■ カルチャーマッチ
- その人のやりたいことと会社&ポディションがマッチするか
- 担当することになるプロダクトに興味あるか
- 必須条件ではないが、あった方が本人のモチベになるので結果的には良いと思う
- 単純にノリが合いそうかどうか
- 多様性の担保も大事だが、あまり攻めすぎると早期離職や人間関係悪化が起こる
以前は、DDDでどう実装したらいいかなぁって考えてたんだけど、最近は、そういうことへの興味があまりなくなっている。エンティティや値オブジェクト、集約やリポジトリなど、そのあたりにあまり興味がない。ヘキサゴナルアーキテクチャなども、そんなに考えなくなった。
TypeScriptを使うことが多いので、型でしっかり守るとかカプセル化するとか、そのあたりがどっちでもいっかという気持ちになっていることが影響してるとは思う。TypeScriptでクラスを使おうとはあまり思わないし。BrandedTypeみたいなのを使ってまで型で守ろうとは思わない。
■ トランザクション境界
トランザクションの境界を作って、DB（RDBMS）を小さく保ちたいと思っている。DBが大きくなると、すぐに複雑になっていく感じがする。
だから、トランザクション境界を作ってDBを小さく保てば、そこに対するサービス（アプリケーション）も小さく保てるかなと。サービスが小さければその中でSQLの力を活かした素朴なコードを書いても、そこまで複雑にはならないんじゃないかなという気持ち。
トランザクション境界があると、それを超えた整合性の伝搬には非同期処理を使う必要があるなど、別の複雑さを持ち込んでしまうけど、DBが一手に担ってくれてた複雑さをどう分散させるか、そのあたりをうまくやることに今は興味がある。
■ ユビキタス言語
ユビキタス言語は、とても意識している。PdMが喋る言葉から、ドキュメントはもちろん、プログラムの中まで同じ言葉を使うようにしている。
たとえば「薬品」はプログラムの中でもそのまま「Yakuhin」となっている。バックエンドで変数名などに漢字を使うのは予期せぬ問題にぶつかりそうだから、ローマ字にしてる。ちなみに、フロントエンドでは日本語コンポーネントを使ってる。ぱっと見て理解できる漢字のすばらしさよ。
■ 小さく保つ、名前にこだわる、それで複雑さに立ち向かう
という感じで、今は、影響範囲を小さく保つことと、名前にこだわることに興味を持っている。いちどに気にする範囲を小さく保って、レイヤーを分けて、意識しておくべきロジックは凝集させて、変数や関数やモジュールの名前にこだわる。1つの関数をできるだけ小さくする。依存の向きは一方向にする。イミュータブルにする。
スタートアップ的な開発と技術的負債の話、スタートアップからの案件相談とか聞いてて思うのは、安定化・リファクタリング期間を明示的に積む経営判断をすれば済んでる話を、現場レベルで技術的負債が生まれる前に完璧なアーキテクチャを組もうみたいなアプローチをして爆散してる印象なんだよな
まあ、このあたりの話、単に経営者が技術に疎いとかそういう話ではなく、CTO的な人間がそういうマネジメント概念を持ってないケースもあり