レビューをよくするようになって何年か経つのですが、よく目にするのが１つの関数とかファイルの行数が長くて何をしてるのか把握が難しい状態です。
この場合は必要な処理が書かれているか初見では判断できないのでリファクタリングが必要だということで、次のようなステップでコメントをしています。
対話と指摘は違うんだよね。対話による合意形成を好む人は、win-winなゴールを望むので相手と自分の立場をなるべくフラットに持っていこうとするけど、指摘による合意形成を好む人は、win-loseなゴールを望むので自分の立場に上下を作りたがる。表面的には一緒に見えるけど中身は全くの別物である。
こと技術者肌の人は、対話による合意形成を時間の無駄と考える傾向がある。彼らにとっては正解は常に1つ存在していてそれでいけばいいと思っている。”何故答えはある(そしてそれは自分の持論である事が多い)のに無駄な事をするのか”と思っているので無駄という言葉がよく出る。
この手のエンジニア系の人は、win-loseな関係の事をwin-winと誤認している事が多い。win-winとは参加している誰かの持論ではなく参加している人が対話をする事で想像もしなかったよりよい合意形成案を生むことであって自分の正解と思っている自論で周りを納得させることじゃないんだよね。
アジャイル宣言に出てくる対話もwin-winなものを創る活動であって、自分や他人の持論で相手を納得させるwin-loseやlose-winな話ではないと思うのだけど、正解を含めゼロサムな意見を好むエンジニア系の人はこの辺の違いがなかなか理解できないもんだよなぁとしみじみ思う。
会社としての体制が定まらない内は新人〜ジュニア層の採用と育成は難しいわな
よく中抜き構造に対する批判を聞くけれども、表裏である雇用規制をどうすべきかにまで考えが及ぶ人は少ない。必要に応じて直接雇用してプロジェクトが終わったところで解雇できれば理論的には内製できる。実際そうではないから要員を充足できるところまで階層構造が生まれる訳で
COCOAがダメだったのは「技術に対して投資して結果が得られなかったのがダメ」とかではなく企業の中抜き構造がダメだったというのが浮き彫りになったのが正しいんだよなぁ
実際は組織能力とか賃金体系、比較優位といった諸々もあってエンティティを分けることが経済合理的なケースもある。とはいえ役割による分業の方が、雇用構造による分業よりもずっと階層が浅く、取引費用やコミュニケーションコストも小さいのではないかな
Cが危険であり、Cを使い続けることができない状況だからです。
から孫引きすると
2019年と古めの統計ではあるがIs One Programming Language More Secure Than The Rest?によると、脆弱性情報の多いランキングとして以下のようになっているそうです。
C言語 (47%)
PHP (17%)
Java(12%)
JavaScript (11%)
Python (6%)
C++ (6%)
Ruby (5%)
と実に脆弱性の半分がCで作られています。このことは、Shellshock脆弱性[1] やHeartbleed脆弱性[2] などで代表されるような、バッファオーバーフローを簡単に引き起こしてしまう、現代のレベルから劣っているとしか言いようがない、かつ直しようがない言語設計(50年も前の言語なのでしょうがないのですが)、また置き換えられることなくあまりにも長く使われてきたシステムプログラミング領域の言語であったということから来ています。
一方、システムプログラミングの領域では、やはり性能が求められます。CPUが倍に速くなったからソフトウェアの性能は半分で良いと考える人はいません。特にクラウドやサーバサイドでは、ハードウエアで倍量の処理ができるように速度が向上したなら、倍のユーザの同時処理を行うことが求められます。高価なインスタンスを利用するからと言って、じゃあその分遅い言語で書いていいんだね、とかが許される余地はありません。アプリケーションはともかく、「その上で全てが動作する、その動作速度にあらゆるユーザのあらゆる処理が依存する」ようなシステムプログラミングでは特にそうなのです。
ということで、システムプログラミング分野では、旺盛なソフトウェア開発需要のもとで、Cと同等の実行速度は必要であり、ハイリスクなC以外の選択肢は強く求められているのです。
本来なら、C++はその役を担っても良いものでした。しかしパラダイムシフトに匹敵する方針転換を一つの言語上で後方互換を保ったまま何度も行ったことで、その仕様は難解なものとなりました。後方互換を必要としない開発分野では、まさに重荷というべき、採用コストがペイしないうえに保守コスト上も受け入れがたい言語とみなされ始めました。
以上がCの代替言語が出てきた背景となります。残る疑問は、なぜ、この時期にそしてなぜ多数なのか、です。
多数であることについてですが、質問に挙げられた言語をそれぞれ見ていくと、コンセプト、解決したい領域がそれぞれ異なっていることがわかります。
例えばgoはネットワーク・並列処理であるし、CarbonはC++のプログラミングモデルそのままに重荷である後方互換を除去し、良いところだけを取り出したものです。Rustはリッチな型システムに裏打ちされた静的解析によるメモリエラーの撲滅を目指しています。Zigはより直球でCを代替するもので、一周戻ってRust疲れを癒やす存在です。
だから多数なのには理由があり、Cがあまりにも多くを負うていたことの反動だとも言えるでしょう。
最後に「なぜ今なのか」です。といってもGoやRustが出たのもそんなに新しい話ではないですが、D言語やVなんかもあるし印象としては確かに増えてはいます。
その理由を説明するなら、C以外の言語、例えばHaskell,Ruby,JS,Erlang,Typescript言語による成長期・実験期が終わり、言語機能ごとの評価が定まり、良い機能は何か、あんまり良くない機能は何かのコンセンサスが取れてきたということがあります。収穫期が来たということです。
多角的、総合的な意味で「良いシステムプログラミング言語」をどうすれば作れるかがわかってきて、言語設計業界が成熟し、メリットが大きい言語を作れるようになり、ついに偉大すぎるCの遺産を捨ててでも移行する苦痛を凌ぐようになってきました。Cを捨てるメリットが、損益分岐点を超えつつあるのが今だから、いまそのような言語が我々の目に良く付き始めるようになっているのです。その動向は大きな潮流であり、業界全体に普遍的だから、C代替の多数の言語が今、現れています。
脚注
SOLID原則はプリンシパル(ルールやガイドライン)を定めたものであるのに対し、CUPIDはソフトウェアが持つべき性質・特徴を定めたものです。SOLID原則はOOPやプログラミング言語に依存するところがありますが、CUPIDは基本的にOOPやプログラミング言語に依存しません。
CUPIDは下記の頭文字です。ソフトウェアはこれらの性質・特徴を持つように作るべきだというのがCUPIDが伝えるものです。
- Composable : 他のコンポーネントと組み合わせしやすいこと
- Unix philosophy : ひとつのことをうまくやること
- Predictable : なにをするのか予測できること
- Idiomatic : 自然に感じられること
- Domain-based : ドメイン言語とドメインの構造を使うこと
Remix.runのKent C.Dodds氏や、VercelのGuillermo Rauch氏などの著名なソフトウェアエンジニアは、統合テストがE2Eテストよりも低コストで、単体テストよりもカバー範囲が広いことを理由に、もっと統合テストを重視するように提唱しています。
「静的テスト、単体テスト、統合テスト、E2Eテストのバランスはチームが何を重視するかによって変化します。このバランスは、厳密なルールとして捉えるべきものではないでしょう。
あくまで一般論です。使用できるツールでアプリをテストするのがどれだけ簡単か、難しいかによって、実際に異なるのです。 一般的な考え方は、静的テストと統合テストによって、かけたコストに対してユーザに“素晴らしい”価値を保証します。そして単体テストとE2Eテストによって、“良い”価値が得ることができのです。なので全て利用していきましょう」
統合テストの大きな価値の一つは、E2Eテストと同じようにユーザーのふるまいをテストできることにあります。 ユーザーがコンポーネントを単体で使用することはほとんどなく、ほとんどのWebアプリは、異なるコンポーネント間の相互作用として実行されます。
このため、統合テストは、特定のロジックの入力と出力をテストするだけの単体テストと比べて、テスト結果の信頼性が高くなると思います。
なので、最初に書くべきなのは統合テストだと捉えています。 この考え方は、ほとんどの人は直感に反したり、異なる意見を持っているかもしれません。
開発サイクルの中で不具合を発見するのが遅ければ遅いほど、その修正にかかる費用は高くなると教えられてきました。統合テストなどの「大きなタスク」に着手する前に、すべての細部を完璧にしようとします。
先に単体テストを書いていては必要なビジネスロジックを柔軟に変更しながら開発を進めることができません。
確かに関数/メソッドレベルのユニットテストより、それらを呼び出すエンドポイント的な部分のテストから書き始めることが多い。
例えば、コントローラやユースケースの実装＆テストから始めて実際にテストを動かしながら実装を進める方がやりやすい。
米ツイッターの経営が視界不良だ。13日に開いた臨時株主総会で、米起業家のイーロン・マスク氏と4月に合意した総額440億ドル（約6兆3000億円）の買収取引を承認した。同日には米議会上院が、同社のセキュリティー問題を内部告発した元幹部を証人に招き、外国勢力によるスパイ行為などのリスクを問いただした。買収撤回を表明しているマスク氏との法廷闘争に影響する可能性がある。
「非常に大きな影響力を持つ会社でありながら、業界のセキュリティー基準から10年以上遅れている」。ツイッター元幹部のピーター・ザトコ氏は13日、米上院司法委員会が首都ワシントンで開いた公聴会に出席し、同社のIT（情報技術）システムの脆弱性が経営陣によって意図的に見過ごされ、事実が隠蔽されてきたと証言した。
多くの企業はITシステムを稼働中の本番環境と、開発のためのテスト環境に分けている。ところがツイッターではザトコ氏が在籍していた2022年1月まで社内にテスト環境は存在しなかったという。攻撃者の視点でシステムを診断する「ホワイトハッカー」でもある同氏の目には「奇妙で異例」と映った。
ザトコ氏によると従業員の半数を占める4000人近いエンジニアが本番環境にアクセスすれば、電話番号や位置情報を含む多くの個人情報を閲覧できる状態だった。社内ではエンジニアの作業履歴などを追跡する仕組みも整っていなかった。
ツイッターを解雇される直前には中国の情報機関の工作員が同社に在籍していた事実を知らされたという。ザトコ氏は13日の公聴会では「ツイッターの従業員ならばこの部屋にいる議員全員のアカウントを乗っ取ることができると言っても過言ではない」と訴え、米規制当局の対応を促した。
Twitterぐらいの規模になってしまうと本番相当のテスト環境を作るのに多大なコストが掛かるだろうから、フィーチャーフラグを仕込んだ上で本番に直接適用するという方針でも別に不思議ではないが（テストとレビューは厳格にやる前提）。
Facebookもそんな感じの開発フローだと聞いたことがある。
ユーザーデータに対するパーミッションや作業内容の監査ログ機能が無いのは流石にダメだと思うけども。
エ〜クエクエクエク(エクセル怪人の笑い声)今日もセルを結合して中央揃えして、検索に引っかからないようにテキストボックスに大事なことを書いて、印刷する予定も無いのに印刷範囲を設定していくエクねえ……
ある種の人々において、Excelを独創的な使い方をしたがるのは何故なのか
WindowsやMacなどのローカル環境に簡単にDockerコンテナを用いた開発環境を導入できるソフトウェア「Docker Desktop」の最新版「Docker Desktop 4.12」がリリースされました。
2つ目はDockerイメージの管理にcontainerdが使われるようになることです。まだ実験的実装の段階ですが、Dockerイメージの保存やプッシュ、プルといった管理にはDocker独自の実装であるグラフドライバーが用いられていました。
今回のDocker Desktop 4.12からは、このグラフドライバの代わりにcontainerdの機能であるSnapshotterが用いられ、containerdの機能を呼び出してイメージ管理が行われるようになります。
これによって他のcontainerdを用いた環境との整合性や互換性がより高くなると説明されています。
へぇー
基本方針が決まったので、先程作ったリストの項目それぞれに、おおまかに優先順位を付けていくことにしました。 ただ数字を書き込んだだけだと分かりにくいかと思い、各項目に「出血中」「痛みを伴っている」「健康診断判定E」「体脂肪率40% -> 20％」など、健康状態に例えてラベル付けをしていきました。
例えば、極めて改修頻度が低くメンテが後手に回った結果、CIが古く不安定になっているリポジトリには、改修頻度が低いほど自動でのサポートが必須だと考えたため、「出血中」というラベルを付けました。
他にも、フレームワークや言語のバージョンが古いものには「健康診断判定G」、オンプレからクラウドに移行するだけで開発が機敏になるものには「体脂肪率40% -> 20%」などとラベル付けをしました。
その頃社内でのイベントで、「基盤領域の業務の説明をして欲しい」という依頼が来ました。 基盤領域の業務は、非エンジニア職の方々には見えにくく、「こっちはこんなに忙しいのに何をしているのだろう」などという不信にも繋がりかねません。今後の技術的負債の解消に向け、そういった不信感は致命的です。 それを少しでも解消するための良いチャンスと受け止め、プレゼンでは基盤領域の仕事を、アルバイトで求人が多い飲食店チェーンに置き換えて話をしてみました。 要約すると、以下のような感じになります。
- 揚げ物ブームが来たのででかいフライヤーを導入したが、ブームが終わったら稼働率が落ちた。これを撤去したり、新しい機材を入れたりしなければならない
- 包丁もコンロも、各調理器具は手入れをしなければ、継続的に使えない
- こういったものを常に、現在の仕事が滞り無くできたり、新しいブームにすぐ乗れたりするように保つ必要がある
- Webシステムにおいて、そういった手入れや準備、研究、調査をするのが、基盤領域の仕事
これはオープンソースプロジェクトあるあるだと思いますが、コントリビューターの方からもらう大きめのIssueに、最初から過不足無く情報が整っていることなんてほとんどありません。それ自体は当たり前のことです。ここで言いたいのは、Issueをもらった後、対話によって「なにがしたいのか」「どう変えるのか」を突き詰めていく課程が当然に必要になるということです。
しかし、取り込むかどうかわからないものの話を進めて、コントリビューターの時間を使ってもらって議論を深めて、やっぱり行政内で検討した結果駄目でした。というのは、ぼくとしては進められませんでした。
結果として大きめのIssueがほとんど処理できず、小さなIssueやPull Requestのみを取り込むという、言ってみればスケールの小さな活動に終始してしまったのが、ぼくの大きな反省です。
しかし、行政内での人の入れ替わりが激しい。最長でも2年ほどで異動するのが普通だそうです。意思決定者と聞いているポジションで着任したと聞いてから、一度も挨拶しないまま離任した人も居ます。そのような状況ですから、引き継ぎがあるとは言え、オープンソースコミュニティへの信頼は定期的にリセットされた状態になっていると個人的には感じています。
接触確認アプリ「COCOA」は、もともと10年続かない（続いて欲しくない）プロジェクトとぼくは認識しています。 その上で、ソフトウェアには10年以上使うものはそれなりにあります。ソフトウェアのオープンソースコミュニティと、人の入れ替わりが定期的にある行政とは相性が悪い気もします。
あと、もう少し物事を進める権限が欲しい。意思決定者と直接、話をさせてもらえる機会がちゃんと欲しい。意思決定者でなくてもいいから、どういう話し合いがあってそういう結論になったのか、経緯をきちんと教えて欲しい。
TL;DR
- 100％のテストカバレッジを目指す
- テストはブラックボックスを優先して記述、どうしても到達できない場合はホワイトボックス
- 最初のテストケースは、テスト対象が動作する最も一般的なケースであるべき
ソフトウェアは何もしないと壊れる
というのは事実ではあるんだけど、それが良いことかというと、どうなのかなあと思う。ほかにも、我々プログラマはつい「ソフトウェアは完成しない」とかいってしまうし、それは雇用のためには良いことなんだろうけど、でも本当に完成しないんだろうか。
ここ最近ずっと G-SHOCK のオリジナルに近い四角いモデルをつけていて、こういう、完成した定番品というのが、コンピュータとかソフトウェアの世界にも、もう少しあってもいいんじゃないかと思う。
実行基盤（OS）自体が変化していく界隈だしなぁ
確かにWindows2000をWindows2000のままブラッシュアップしていってほしかった気持ちはある。
Docker、いつでも簡単に再現性のあるLinuxランタイムを作って壊せて便利だと思って数年置いてたらDebianのバージョンが賞味期限切れでコンテナを再構築できず、ほんとにすごいのはAPTだったんだなとわかる回
CentOSイメージも古いバージョンはリポジトリのURLが変わったりしてすぐ動かなくなる。
やはり放置はダメなのだな。
とはいえ、オープン化してからソフトウェアの寿命はどんどん短くなっているのは事実で、それが全て好ましいとは思えないってのもある。
特に機械の制御機器に汎用PC（とソフトウェア）を使うのはライフサイクルが短すぎて厳しいというのはずっと言われていることだし（例えば、デジタルサイネージの管理システムが未だにWindows2000＋VBアプリである、とか）。
ドメインの分析はイベントストーミングで行うべし、というところから始まっていて、DDD の実践書としてコンパクトながらよくまとまっている。DDD の入門という観点でもよさそう。
結局この本で言っている Functional とは
- 静的な代数的データ型を駆使してモデリングすることと、
- 不変なデータと副作用のない関数に基づいてワークフローを実装すること
ということのようである。
分析を経て得られたドメインモデルを、型を通じてモデリングしていく。ここではとくに直和型が重要な働きを持っていて、これを使うことで違うものを違うものとして表現できる。「ありえない状態はそもそも表現できないようにする（Making Illigal States Unrepresentable In Our Domain）」というのが大方針だ。
This project provides some working examples using Go the hotwire/turbo library published by basecamp. This is based on a great post about Hotwire: HTML Over The Wire by @delitescere.
このプロジェクトは、basecamp によって公開されている Go hotwire/turbo ライブラリを使用して、いくつかの実例を提供します。 これは、@delitecere による Hotwire: HTML Over The Wire に関するすばらしい投稿に基づいています。
エンジニアの人たちね、まあ頭が良いということなんだろうけどもね、例えばなんだけど「Aを使ったBがしたい」と言うと、そのAとBになった背景を聞くのね。
これは全然良いんだけど、最終的に「それならCがいいよ」って結論を出してくるの。相手はAを使ったBがしたいって言ってるのに。
これ逆に頭悪いんじゃない？って思うことはある
例えば1000を上限としてるのに、50くらい変わらないでしょって前提で、1050くらいの話を勧めてきたりとか。なんかいちいち話をズラしたり外堀だけ埋めてこようとするの。たぶん自分がしたい話を選んでるってことなんだろうけど、すげー会話しづらいよ。
制約条件を明示しない方が悪いのだ。
制約条件が明示されていないなら、結果に対して最善と思われる提案を出すに決まっているだろう。
削除されて困るデータはそもそもバックアップしておくべきだし、初期化されて困るというのもよくわからない。
もう5年以上続けている取り組みのひとつにデスクトップ環境をdisposableに保つというのがある。いつでも何があっても即座に環境を捨てて作り直せるようにするということ。EC2やVPSのインスタンスに対してAnsibleでプロビジョニングできる状態にしておけば即座に新しいホストを立てて古いホストを捨てられる、そんな状態を目指すということ。具体的には以下のようなことを心がけている。
設定を一発で復元するシェルスクリプト作っとこうと思いつつ、ずっと後回しにしてたけど少しずつやっていこうかな
HTTP GETで起動するバッチ処理、Confluenceに作ったAPIドキュメントにURIを貼ったらプレビュー機能が働いてバッチ処理が叩かれてしまい、障害が起こったのでConfluenceが禁止になった回。
草
最近のお客様でもこれは強く言われる。なぜかと言うと変更にかかるコストの問題で、相手がSIerであれ情シス部門であれ、キャッシュアウトや交渉の手間を嫌うから。私も経理部員だったのでわかる。
これはあまり健全だとは言えない。コードで表現すべきことはそうすべきだと思います。(続く)
昔、お客様の基幹系システムをスクラッチ開発していた頃、システム運用担当の皆様ともよく打ち合わせしたが、ビジネスルールを如何にわかりやすくコードに書くかではなく、業務上変わり得るルールならそもそもコードに書かず、ユーザー部門がテーブル登録する仕様にしてくれという話の方が普通だった。
テーブルでビジネスロジックを表現するのが難しい場合があり、担当者が3代変われば、もはやブラックボックスになります。コードで表現してある方がまだしも親切で、リーダビリティが高いと尚よい。DevOpsが実現されていて内製化されていればもっとよい。
ビジネスロジックをテーブルで実装できるとなったら、ユーザーは仕様の決定を先送りする。過度な柔軟性を持たせることを要求する。 あんまり良いことではないが、変えようもない。情シス部門は事業部門より立場が弱い。昔に比べその傾向は強い。だったらコードの部分で何とかするしかないと思います。
昔、お客様の基幹系システムをスクラッチ開発していた頃、システム運用担当の皆様ともよく打ち合わせしたが、ビジネスルールを如何にわかりやすくコードに書くかではなく、業務上変わり得るルールならそもそもコードに書かず、ユーザー部門がテーブル登録する仕様にしてくれという話の方が普通だった。
この辺、この三十年ぐらいで、もしかしたらものすごく後退してきてるんじゃないかと感じることがある。
COBOL が Java になろうが、何かの関数型言語になろうが、変わり易いと分かっている業務ルールをハードコードして、リーダビリティ云々と言っているんじゃ、ソフトウェア設計としては、レベルが落ちているとしか言いようがない。
太陽電池でモーターを回し、木をこすって火を起こしている印象だ。
僕のいたのがコンサルティング会社でレベルが高かったー、みたいな話ではなくて、お客様の情報システム部門がまずそういうスタンスだったですね。
確かにやりすぎのリスクはある。普通のマスター項目以上、汎用言語未満、みたいなところで寸止めするのが結構大事。#やりすぎがちなアカウントの述懐
DBのカラムにJSのコード断片入れておいてごにょごにょさせる、みたいな。けっこう凶器じみているかも。
本件、メタプログラミングを志向してるんじゃないんです。変わると言われがちな要件の背後にある変わらぬものを見い出そうとする試みなんですね。まあ、メタプログラミングは本来そうだと言えば、そうかもしれない。
そりゃ昔（今も？）みたいにコードの変更は「まず稟議を上げて部門長の承認を得て、システム部門に申請してシステム部門の承認を得て、そこから開発企業に発注して、先方の対応を待って漸く実装されたら、受入試験を実施して...（略」みたいな状況だったら、そりゃ利用部門で柔軟に変更できるようなDSL的な何かが欲しくもなるだろうけど。
社内に開発チームを常駐させて緊急性・重要性の高い案件から処理していくアジャイル開発のスタイルを採用するなら過度な柔軟性はむしろ生産性を下げるのでドメインロジックはコードで表現するのがやはり最適解だろう。
とはいえ、DSL的な何かで処理やデータを自由に定義できるという方向性自体は間違いでも無いので、そういうのはダッシュボードツールやJupyter Notebook的なものを提供すればよいだろう。
米Folio Photonicsは8月30日(現地時間)、多層光ディスク技術において重要なブレイクスルーを達成し、抜本的に低コストと大容量を両立させ、動的にリード/ライト可能な光ストレージディスクを開発したと発表した。製品の投入は2024年を予定している。
2024年投入時で1ディスクあたり1TB、これを10枚集約したカートリッジで10TBを達成する。その一方でコストに関してはHDDが1TBあたり25ドルであるのに対し、1TBあたり5ドル未満を達成できるとしている。将来的なロードマップでは1TBあたり1ドル以下を目指す。
現在の低コストなデータアーカイブ技術としてはテープがあるが、Folio Photonicsの光ディスクはランダムアクセス性を実現できるほか、電磁パルス攻撃、サーバー攻撃から保護できるエアギャップ、100年のメディア寿命を提供する。
本当に実現できるのだろうか？
飲食チェーン「焼肉きんぐ」などを運営する物語コーポレーション（愛知県豊橋市）は9月5日、顧客の個人情報14万3876件を誤って削除し、復旧できない状態だと発表した。サーバ移行時の確認不足によりデータを移行し損ね、そのまま古いサーバの契約期間が終了したという。削除した情報の漏えいは確認していない。
誤って削除した情報は、焼肉きんぐに加え「お好み焼き本舗」「焼肉かるびとはらみ」など計6ブランドのチェーン店に来店したことがある顧客の氏名、住所、電話番号、生年月日、性別、メールアドレス。いずれも、誕生日の顧客にサービスやキャンペーンを告知する目的で保存していたという。
oh...
ソフトウェア開発で「正確な工数見積はできない」というのは、新規なんてやってみるまで何ひとつわからないという怠慢の肯定ではなくて、過去の経験からだいたいカンでこれぐらいかなと予測した数字は出せるけど、そんなものの足し算で長期計画のケツを約束する愚行をやめようという意味なのよね
わかってればわかってるほど、こうなんですよね。本当に全くわからないなんて言い出す人は、きみ開発経験ほんとにあるの? ってことになっちゃう。まだそれは誠実なほうで、わからないのに見栄を張って数字を言っちゃう不誠実が横行するのが問題。動機が見栄だから、実際の結果はだいたい期待を下回る
で、ボロを出したくない心理で、見積の間違いを隠すんですけど、そのままだと最後にバレるのは容易に想像できるので、言ったことと帳尻を合わすためにムリをするんですよね。まあ当然、開発者がそうやって疲弊したらソフトウェアのメンテ品質はさらに下がって、ますます遅れちゃうっていうのがオチです
まあそのなんだ。100%でなければ0%かよみたいな極端な話は不毛だからやめようってことと、その中間の確からしさと不確実さを受け入れて、嘘の進捗管理をやめようよということです
Google Chromeの開発チームは、すでに非推奨となっているWeb標準のWeb SQL Database APIをChromeから削除、その代替機能としてSQLite開発チームと協力してWebAssembly版のSQLiteを開発し、提供する予定であることを明らかにしました。
クライアントで本格的なDBが動けば嬉しいなと思うことはないでもないんだけども。
ちまちまREST APIを叩くよりSQLiteのデータファイルを直接配信/アップロードする方が効率的ってなるのだろうか。
サンプルを見た感じ、中々良さそうだが
私の考えでは以下の使い分けが望ましいです。
UIとUIロジックは密結合
UIと業務ロジックは疎結合
UIロジックと業務ロジックは疎結合
- atoms
- コンポーネントの最小単位。
- ロジックは持たない。
- ステートレスなコンポーネント。
- システム全体で流用できる。
- molecules
- atoms、moleculesの複合コンポーネント。
- UIロジックを持つことがある。
- ステートレスなコンポーネント。
- システム全体で流用できる。
- organisms
- atoms、moleculesの複合コンポーネント。
- 業務のドメイン情報をDOMに持つことがある。
- そのためシステム全体で流用できるとは限らない。
- APIとの疎通や業務ロジックを持つことがある。
- PresentationalComponentsとContainerComponentsを分ける。
TL;DR
- docker-compose では bind mount の構文が "short", "long" の2通りあるが, それぞれ挙動が異なる
- docker-compose.yml の volumes に略記法 (short syntax) を用いると, コンテナ内で non-root user を用いる際にエラーの発見が遅れる可能性があるので避けよう
services:
app:
image: nginx
volumes:
- "./config:/config"
services:
app:
image: nginx
volumes:
- type: bind
source: "./config"
target: "/config"
そんな指定の仕方があったのか
プロダクト開発みたいに不確実なことをやる場合、成果が約束できないからって、やることを約束しちゃいけない。ムダなことをひたすらやり続けることになる。約束していいのは、目指す成果とプロセスの透明性まで。
JSONの構造を可視化してくれるツール
Dockerイメージも用意されているのでローカルで動かすことも簡単
アウトプットが出ない会議の特徴5要素:
Linuxの主要なディストリビューションの1つであるUbuntuを開発するCanonicalは、AWSが主導するオープンソースの検索エンジン「OpenSearch」のプロジェクトへの参加を表明しました。
すでにOpenSearchにはオラクルを始めとする多くのパートナーが参加していますが、オープンソースの主要なプレイヤーの1つであるCanonicalの参加はAWSやOpenSearchの継続性に懸念を持つ人々にとって心強いものとなりそうです。
結局、ElasticsearchとOpenSearchは別の道を行くのか
コード品質を定量的に測る指標の1つにCognitive Complexityがあります。Cognitive Complexityは人間視点での複雑性を評価する指標で、例えばネストが深くなるほど複雑と判断される特徴があります。複雑なコードは変更に多くの時間を要し、テストが難しくなるので要改善なシグナルといえるでしょう。私たちが今回実施した品質改善の取り組みでは、コードの状態を定量的に説明するための数値の1つとしてCognitive Complexityを採用していました。実際にコード品質を向上させるまでに取り組みを紹介しつつ、Cognitive Complexityの値が低下（改善）した背景を解説します。
物流関係のシステム開発を手掛けるダイアログ（東京都品川区）は8月29日、在庫管理の実態調査を発表。約4割が「Excel」や「紙」を利用していることがわかった。調査対象は、倉庫の在庫管理業務の担当者・経営者・役員189人。
「倉庫の在庫管理で主に行っている方法は、約4割が「Excel」や「紙」と回答しており、Excelでの在庫管理では、「Excelを作った本人しかわからない」や「リアルタイムで更新できない」などの課題の声が挙がりました。更には、Excelあるあるとして「計算式が壊れた際、復旧に時間がかかる」という悩みの声も。なお、半数以上が、現状の在庫管理の方法を変えていく必要性を実感しており、今後WMSを中心とした倉庫管理システムを検討する企業も増えているようです。また、WMS中心の倉庫管理システムに対する期待は高く、「機能種類の充実」や「機能の選択の自由性」、「拠点増加など、あらゆる需要変動への対応」、「様々なデバイスで業務可能か」などの機能が求められていることが分かりました。さまざまな管理方法として「エクセル」が身近で導入費用がかからないと考え、多くの企業に「エクセル」が普及しました。また、DX化が進む近年ではシステム化が重要視され、「在庫管理」においても「エクセル」や「システム」が同時に検索されていることから、このことから「在庫管理をシステム化したい」というニーズが増加していることが伺えます。一方で、「エクセル」は属人化しやすい傾向があり、誰にでも使いやすい管理方法とは言えない実態もあります。人材不足を課題とする企業においては、在庫管理業務の脱属人化による作業効率化を叶え、作業を標準化させるためにシステム導入の需要が加速しそうです」
スマート倉庫を運用できる規模の企業ならともかく、間貸しレベルの小規模企業だといちいちシステム化していられないし、搬入される貨物も多種多様なのでシステムの対応を待ってられないという現実はありそう。
メルカリWebのマイクロサービス化に向けた開発が始まり、最終的にweb-2がシャットダウンされるまで、実に4年以上の期間がかかりました。この記事では、この4年間に開発チームの中でどのような議論があり、どういった選択を行いながらアーキテクチャを変更していったのかを記述し、変化に強い組織やアーキテクチャについて考える上で参考にしていただければと思います。
2022年8月にGo1.19がリリースされ、次のリリースは2023年に予定しているGo1.20です。Go1.20ではGo1.18やGo1.19に入らなかったジェネリクス関係の変更のリリースが期待できます。ここではGo1.20でリリースされると決まった訳ではありませんが、将来リリースされることが期待できる3つの機能について解説します。なお、本稿の執筆後に仕様が変更されたり、機能自体がリリースされない場合もあります。
一塊のコードを複数人に共有させないこと。セールス野郎に会社を仕切らせないこと。ハイエンドの製品を作らないこと。コードを大きくしすぎないこと。バグを見つけるのを品質保証の人間に任せておかないこと。リリースの間を開けすぎないこと。開発者をユーザから隔離しないこと。
mvSQLiteの特徴は、SQLiteのストレージレイヤーをFoundationDBに分離しているところです。 これにより、DynamoDBのように際限のないスケーラビリティ、point-in-timeでの読み取り、そしてRDBの厳密な一貫性を提供します。
作成者曰く、mvSQLiteの目標は「SQLiteを分散データベースに変えること」とのことです。
- Public roadmap: launch of our interactive product roadmap for Heroku on GitHub.
- Focus on mission critical: discontinue free product plans and delete inactive accounts.
- Student and nonprofit program: an upcoming program to support students and nonprofits in conjunction with our nonprofit team.
- Open source support: we will continue to contribute to open source projects, notably Cloud Native Buildpacks. We will be offering Heroku credits to select open source projects through Salesforce’s Open Source Program Office.
Our product, engineering, and security teams are spending an extraordinary amount of effort to manage fraud and abuse of the Heroku free product plans. In order to focus our resources on delivering mission-critical capabilities for customers, we will be phasing out our free plan for Heroku Dynos, free plan for Heroku Postgres, and free plan for Heroku Data for Redis®, as well as deleting inactive accounts.
Google翻訳:
- 公開ロードマップ: GitHub で Heroku のインタラクティブな製品ロードマップを開始します。
- ミッション クリティカルに焦点を当てる: 無料の製品プランを中止し、非アクティブなアカウントを削除します。
- 学生および非営利プログラム: 非営利チームと協力して学生と非営利団体をサポートする今後のプログラム。
- オープン ソース サポート: オープン ソース プロジェクト、特に Cloud Native Buildpacks に引き続き貢献します。 Salesforce のオープンソース プログラム オフィスを通じて、選択したオープンソース プロジェクトに Heroku クレジットを提供します。
Heroku の製品、エンジニアリング、およびセキュリティ チームは、Heroku の無料製品プランの詐欺や悪用を管理するために多大な労力を費やしています。 お客様にミッション クリティカルな機能を提供することにリソースを集中させるために、Heroku Dynos の無料プラン、Heroku Postgres の無料プラン、Heroku Data for Redis® の無料プランを段階的に廃止し、非アクティブなアカウントを削除します。
まぁ、無料プランは悪意のあるユーザーを呼び込んでしまうってのはある。
WEBサービスはいつまでも使えるわけではないという教訓である。
オブジェクト指向って継承による多態があるからこそなんだけど、継承が非推奨になって以降に雰囲気でオブジェクト指向を知った人には、継承はオプションでカプセル化だけでオブジェクト指向って言ってしまいがちに思います。 実際はカプセル化はオブジェクト指向固有じゃなくて、クラスでカプセル化を実現してるだけです。
昔は「継承・カプセル化・ポリモーフィズム」がオブジェクト指向の三原則みたいな言い方されてたな。
アイワから「aiwa」ブランドのデジタル分野における商標使用権を取得したJENESISは、「aiwaデジタル」シリーズとして、9月7日に10.3型のAndroidタブレット「TBA1001」を直販サイト特価39,800円で、6.5型のAndroidスマートフォン「SMP0601」を直販特価16,800円で、スマートウォッチ「SNW01」を直販特価5,800円で発売する。
値段が安いとはいえ、このスペックのスマホやタブレットでは実用に耐えない気がする。
最初に出す製品だからあまり冒険できなかったのだろうけど、これでは製造費の回収すら困難なのではなかろうか。
JavaScriptのドット記法的な感覚でJSONにアクセスできるようにしてくれるライブラリ。
JSONの特定のデータだけ必要で構造体を定義するのが面倒な時に便利そう。