/note/tech

システムをリニューアル時は、新システムを作ることよりも、旧システムから新システムにデータを移行する対応...

システムをリニューアル時は、新システムを作ることよりも、旧システムから新システムにデータを移行する対応の方が実は何倍も難しい。リニューアルするのにデータ移行の話が全く出てこない、見積もりにデータ移行がないみたいな開発会社に依頼すると、まず間違いなく事故るのでやめた方が良いです。

@yonemura2006

なぜこうなるのかというと経験がないからです。データ移行は経験のないエンジニアの方が実は多いです。新規の開発は自分で独学で経験を積むこともできるけど、データ移行は実務でニーズが発生しない限りは中々経験を積むことが難しい。難易度も高いから経験豊富な会社に依頼しないとマジで事故ります。

@yonemura2006

Active Recordから考える次の10年を見据えた技術選定

シェルスクリプトを書くのをやめる

「知らねぇよそんなオプション...」という体験が増えると心理的なダルさが増えるのはある。

一部上場企業のトップエンジニアから教わった『エンジニアの心構え』

いい話だ

「Oracleは金稼ぎがエグい」って意見と「Elastic(Docker)社は金稼ぎが下手すぎる」って意見が存在してて...

「Oracleは金稼ぎがエグい」って意見と「Elastic(Docker)社は金稼ぎが下手すぎる」って意見が存在しててソフトウェアでお金を稼ぐのって大変ですよねってありし日のSun Microsystemsを思い浮かべてる

@yoshiori

言語やプラットフォームは同等のAPIを備えていれば乗り換えが容易だから独占が難しい領域というのもある

オラクル、Oracle JDKを再び無料提供へ、本番環境でも利用可。昨日リリースのJava 17から

迷走してるなぁ

マイクロサービスへの上手な分割手法. ドメイン駆動設計(Domain Driven Design…

RECRUIT TECH MEETUP #1

9/22 1900から

駆け出しエンジニアと繋がりたい のタグが信用を失いつつあるのは何故か。

例の彼の件、まとめられてた。

それはさておき、「駆け出しエンジニアと繋がりたい」タグが失笑と冷笑で語られるのは

という直視に耐えない気持ち悪さが原因である。

DevelopersIO 2021 Decade

6日間もやるのか

ジュニアを採用しない連中はシニアに値しない

長いが読む価値がある

Cloud Runに常時CPU起動オプションが追加された模様

Cloud Runで常時CPU割り当てが可能になる模様。

起動コストが大きいアプリケーションやバックグラウンドで長時間処理を行うアプリを動かすことができるようになる。

問題はお値段だけど、幾らぐらいになるのだろうか。

とりあえずGCEと比べて割高になるのは避けられないと思うのだが。

デザパタ狂信も昨今のアジャイル流行も、本質を見抜く力のない情報弱者を振り回して混乱させているだけ...

デザパタ狂信も昨今のアジャイル流行も、本質を見抜く力のない情報弱者を振り回して混乱させているだけという意味ではやってることは同じやんというのは、せやなと思うけど、一括りにしちゃうのはもやるかな〜。

@aa7th

そうは言ってもソフトウェア開発のテクニックや考え方は一子相伝の秘法ではないのだから、公開されれば広まるのは仕方ない。

そして、エンジニアの8割が本質を見抜けないクソザコナメクジだとしても残り2割が本質を更に磨き上げて後世に引き渡せばよい。

技術の進歩とはそういうものだろう。

Netflix社製のメタデータ管理OSS「Metacat」を試してみた

Metacatとは、Netflix OSSとして開発されているメタデータ管理サービスです。

REST/Thriftインターフェースを持っており、様々なデータソースに対して統一されたインターフェースでメタデータを参照することが可能です。

Metacatには以下の特徴があります。

  • APIのみ提供(Web UIは存在しない)
  • Java/Groovy製
  • ビジネス要件/ユーザー定義メタデータを保存可能
  • データディスカバリー
  • データ変更の監視/通知機能

ふむふむ。

チームみを大切にした 私たちの“受託アジャイル・スクラム”体験談

件のフリーランス先生の元勤め先が開示されるなど

恥ずかしながら...その採用したベンチャーってうち。最終選考は僕が自ら面接して、未経験だけど熱意を買ってチャンスを与えたつもりだったんですけどね。

自社の主力プロダクトの開発に携わてもらったんですが、突然親の介護のため今日退職したいとのことで心配してたんですが...まぁ無事で良かったw

採用したベンチャー大迷惑被ってて草

これやってるとまじで未経験者取ってくれるとこ無くなるよ

https://twitter.com/masa_x15/status/1437251275725303808

@plus_one_masaki

@atsushimatsumo8

件の人↓

不義理をやらかしておいて実名で能書き垂れられるの本当にすごいという感動があった。

イケハヤ大先生の同類なのだな。

社会の害悪だから早めに消えて欲しいものだが。

ダメな開発チームほど、マイクロサービス化したり、ReactやVueで不必要にSPAにしたり、無駄にスケール...

ダメな開発チームほど、マイクロサービス化したり、ReactやVueで不必要にSPAにしたり、無駄にスケールする複雑な構成にしたり、RESTFul使わずにGraphQL使ったり、想定利用ボリュームや必要なパフォーマンスは低いのにGoを採用しがちです。

@MotoyasuYamada

多少趣味に走るぐらいなら目を瞑るけど、自分で選んだ技術にハマってスケジュール遅延起こしてたりすると「こいつはバカなのでは?」という評価を下さざるを得ないのだ。

僕がフリーエンジニアになった手順 ①公務員を辞めて逃げ道なくす...

僕がフリーエンジニアになった手順

①公務員を辞めて逃げ道なくす

②半年間本気でプログラミング学習

③Wantedlyと企業HPから300社近く応募

④ベンチャー内定

⑤実務キャッチアップ+フリーランスの方と交流

⑥4ヶ月で独立

①で環境を変えれるかどうかが一番重要!

#駆け出しエンジニアと繋がりたい

@masa_x15

実務経験4ヶ月でフリーランスとかテスターとかかな?

プロフィールが↓なんだが、これは...

【19歳で公務員を辞めて1年未満でフリーランスになった人】高卒で警察官になるが10ヶ月で退職 ▶︎プログラミング独学 ▶︎ 実務4ヶ月で独立 ▶︎ フリーエンジニアになり月単価50万以上

何となくいい感じに表現してるけど、実態は↓ということか。

単価50万/月は実績として書かないほうがマシまであるのでは...

追記:

全方面から殴られてアカ消しして去っていった模様。R.I.P。

次に転生する時はもう少し誠実さを身に着けよう。

というか、こんな不誠実なパーソナリティの人間が警察目指していたというのもホラーなんだよな。

Airbnbが採用するServer-Driven UIについて、私達はどう活かすのか

サーバからレイアウト指示を含んだJSONを受け取ってクライアントはそれを復元する...ということなのだろうか?

HTMLの再実装感ある。

継続的ドキュメンテーション: Github DiscussionsとADRのすすめ

GMO Developers Day 2021

Docker発展の貢献者、Docker社創業者兼CTOのSolomon Hykes氏がDockerを去ると発表

やっぱりDocker社やばいのでは?

Seed期スタートアップがITエンジニア採用で強い理由と、新卒採用戦略の反省

色々刺さるものがある。あとで何か追記するかも。

みずほ銀行のシステム障害特別調査委員会報告書を読んで

「あえて精度勝負をしない機械学習」という選択肢

  • 最高精度のモデル、必ずしも実務においては最適ならず
  • 自分が過去に手掛けた事例
    • 「予測」ではなく「説明(解釈)」をアウトプットとして返す
    • 「確信度」の高い予測結果だけを使い、残りは捨てる
  • 「精度」よりも「合目的性」と「現場の感覚の活用」を

データの記録と参照が主体のアプリケーションであればドメイン駆動設計のアプローチは非効率というか不適切。

データの記録と参照が主体のアプリケーションであればドメイン駆動設計のアプローチは非効率というか不適切。

問題は、データの記録と参照が主体で複雑な計算判断はできないアプリケーションを開発することが良い選択かどうか。

アプリケーションソフトウェアを開発する費用対効果の問題。

@masuda220

シンプルなCRUDアプリにDDDを適用してもしんどいだけで、そういうのはRoRやLaravelに任せておけばよい。

...のだが、そういうアプリケーションも時の流れと共に複雑なビジネスルールを孕んだ怪物に発展することは本当によくあることなので、ある程度目利きができる人間が必要になってしまうのだ。

インシデント発生時の立ち振舞いの学び方とか

「深夜にトラブルで対策本部を置いた」事ついての反省会した。

1. 三浦呼んだ効果はあった

2. ただ「技術的な解決してない」ため「捌き」だけなら他の人でも良かった

3. 出来れば「突発的な社外の人」でなく自社員が良い

4. Closing時「各自明日いつ出て何する」を話すべきだった

くらいを確認した。

@kazuhito_m

深夜「のっぴきならん障害」起こった場合…

- 本部ぽいの設置

- ホワイトボード置く

- 今日の到達点(コレ出来たら寝れる)決定

- 解ってる事、予定、取れる策 等書き出す

- 必要な人を呼び、不要人は返す(明日の為)

- 解散時「明日の予定」確認

を「経験で」してるけど「これ学ぶ本」とかあんのかな。

@kazuhito_m

ちょっと「誤解されたら困る」ので補足しますと…。

今回「リモートで対応している」「全員リモート」なので、実際にはホワイトボードを使ってません。

「リアルだろうがリモートだろうが、ホワイトボード的な”全員が書けて、全員が観れる”集約場が居る」

ということです。 #今回はHackMD使いました

@kazuhito_m

今後SREの集合知としてまとめられていきそう

日本のIT投資、人海戦術の手作業テストとそのエビデンス書類あたりに金が消費されてるの、そりゃまあ成果...

日本のIT投資、人海戦術の手作業テストとそのエビデンス書類あたりに金が消費されてるの、そりゃまあ成果出ないだろうな感がある

@nagise

大規模開発とかSIerの界隈と関わらなくなって久しいんだけど、未だにそんなことやってるとこあるのだろうか?

佐賀パターン

佐賀

みずほのシステムについて質問です。

最後の「自らコードを書いているわけではないみずほ社員や経営陣の責任を追及してもみずほのシステムは治るわけがない」というのも、上記のように「責任はコードを書いている人にある」と思っているからこそ出てしまう言葉でしょう。3つのフライパンが結合した調理器具で料理が失敗したとして、その責任は誰にあるでしょうか。コック(みずほ社員)としては、使い勝手が悪すぎる結合フライパンを作った溶接職人に文句を言いたくなるかもしれませんが、本質的には筋違いです。「経営陣がフライパンを溶接できるわけではない」とはいえ、そんなフライパンを作らせたのは経営陣だから当然責任は経営陣にあります。「今の」役員個々人に責任があったかというとこれは気の毒な面はありますが、しかし組織として先代からの権利と責任を受け継ぐ前提で就任しているのですから、責任がないとも言えません。

「ではどうすればいいのか」というのは現時点で誰もわかっていないと思いますが(当のみずほ自身がわかっていないのですから)少なくともベンダーのせいにしているうちは解決は望めないでしょう。質問者さんが仮にみずほ内部の方であるならば、そのような他責思考に陥ってしまう社内文化が醸成されている可能性が高く、それは即ち金融庁やメディアの指摘が正しい傍証になってしまっています。みずほへの批判に対して憤懣やるかたない思いを覚えてしまうのは愛社精神があるからだと思いますが、是非ともその愛社精神は責任転嫁や正当化ではなく、自行の改善という方向に使って頂きたいと思います。

世の中の多くのプログラミング言語のコンパイラはC言語で書かれていて、じゃあC言語はなにで書かれている...

世の中の多くのプログラミング言語のコンパイラはC言語で書かれていて、じゃあC言語はなにで書かれているかというとC言語で書かれていて、C言語がないとC言語作れないから堂々巡りかというとそうではなく、より機能の少ないC言語で高機能のC言語をコンパイルしたりする。

@hamukazu

という話は、高いビルの工事で高所にクレーンを運ぶ方法と似てるなあと思ったりしたので急に思いついて書いたりした。

@hamukazu

機械工作の精度を高めるには、まず手持ちの機材で最高精度の工作機械を製造して、その工作機械で更に精度の高い工作機械を製造して、更にその工作機械で...というステップで工作精度の向上が図られてきたという話を思い出す。

新しい環境でバリューが出せずに悩んでいる場合の解決法

SRE Gaps「理論と実践からSREを再考する」

19:30 オープニング 主催 Forkwell 重本 湧気 / モデレーター nwiizo氏(株式会社スリーシェイク ソフトウェアエンジニア)

19:40 基調講演「SREの理念と原則」 外資系ソフトウェア企業 デベロッパーアドボケイト 山口 能迪 氏

20:10 質疑応答  

20:20 休憩  

20:25 講演1「Sreake流 SREの始め方」 株式会社スリーシェイク Sreake事業部 部長 手塚 卓也氏

20:45 講演2「大規模組織のSREが果たすべきミッション」 株式会社エヌ・ティ・ティ・データ ITSP事業本部 カード&ペイメント事業部 デジタルペイメント開発室 主任 矢口 拓実氏

20:55 休憩  

21:00 パネルトーク / 事例講演への質疑応答  

21:30 クロージング

こっちを見てる

ZOZO Technologies Meetup〜ZOZOTOWNアーキテクトナイト〜

タイムテーブル

19:00 オープニング

19:05 これからのZOZOTOWNを支えるログ収集プラットフォームを設計した話 SRE部 データ基盤 / 塩崎 健弘

19:25 ZOZOTOWNマイクロサービス基盤のIstioを活用したService Mesh アーキテクチャへの移行 SRE部 ECプラットフォームSRE / 川﨑 庸市

19:50 ZOZOTOWNマイクロサービス化に向けたサービス粒度の話 ECプラットフォーム部 / 高橋 智也

20:10 ZOZOTOWNのアーキテクトという役割を紹介します アーキテクト部 アーキテクト / 岡 大勝

20:30 クロージング

こっちはアーカイブで見るかな

Reactによるコンポーネントパターンまとめ

驚くべきことに、プロジェクトが大きくなると動かしてみる手間がかかるからとやらない人が本当にいる

プログラム書いたらテストしようね → 何でもいいからためしに動かして動作確認ふつうするやろ

驚くべきことに、プロジェクトが大きくなると動かしてみる手間がかかるからとやらない人が本当にいる。自動テストを実践するかどうかというレベル以前に

ほんと素朴に、テストしようってこれやねん

@tanakahisateru

できる人でもやっぱりでかいプロジェクト試すの面倒は面倒よ。まあやるけどさぁ。だから、変更箇所の単体テストでOKにしたいわけ。で、単体テストっていうのは、画面まで遠すぎるやつは、ライブラリをコードで呼び出して済ませたいわけ。それには、TDD で設計するのが早いよってだけの話

@tanakahisateru

きれいな TDD で設計してあると、アプリケーション全体のつながりを切り離せるんよね。サードパーティのライブラリは画面ないけどそのライブラリの単体テストで信用して使ってるじゃん? それと同じような完全切り離しを自分のコードでもなるべくやっておこうぜというのが「テスト書こうね」のほう

@tanakahisateru

切り離せてない部品をいくらコードで呼び出してても、それは手作業の試行錯誤と同じことをわざわざコードにしてるのと同じだから、テストをしていると言うことはできても、「単体テストを書いている」には入らないよね。ってぐらい幅の広い話が「テスト」の一言でまとめられてるのはなんかなぁと思って

@tanakahisateru

流石に動作確認はやってくれとしか言いようがない。

とはいえ、「それなりに大きく育ってるけど、ユニットテストが無いから手動で画面をポチポチする以外にテストの方法がないアプリ」を目の前にして心が折れるのは正直分かる。

更に正常系ではなくイレギュラーケースだと本当にダルい。

DBにテストデータを入れたりする事前準備だけで1日潰れることも多々あるのだ。

そういう場合は大抵最初に作った奴はとっくに退職して行方を眩ましているという...

The ReScript Programming Language

コードをJavaScriptへ変換するJavaScriptのサブセットな言語。

TypeScriptと違って、JavaScriptとの言語上の互換性はない。

言語仕様はシンプルで結構好きなタイプだけど、TypeScriptでええやろ感が否めず、あまり流行らなそうな気はする。

モデリングの学び方:座談会

聞いている

サーバーワークスが「自走するエンジニア組織」を13年間運営できてきた理由。国内トップクラスのAWS導入実績...

チャレンジした結果失敗しても、ネガティブに捉えない

よく「やり始めたからにはやりきりましょう」なんて言う会社が多いんじゃないかと思いますが、「初志貫徹しなさい」とは誰も言いません。本当に必要な技術を選び抜くには、取捨選択が欠かせない。そのためには失敗してもいい。

けれど当時から大石はメンバーと意見を言い合うことはあっても否定するようなことは決してありませんでした。

事業を展開する上で一番危ないことは、新しいことに取り組む際、お金がかかる、時間がないといった「挑戦しない理由」を許してしまうことだと考えています。

「ググれ禁止」というルールがありますね。要は、困っているから質問している相手に対して「もう一回自分で調べて」と突き返すことを禁止しているということです。たとえば、弊社のSlackには「どんな質問をしてもいい」というチャンネルがありますし、それ以外の場所でもなんでも質問できる文化があります。

「自己満足」するまでやり切ることですかね。私たちはいつも「顧客満足」は必ず「自己満足」のあとにあると思っているんですね。私が「このお客様のためにやりきった」と言えて、お客様に納品して、初めてお客様が満足してくれる。この順番が大切なんじゃないかなと思っていて。

なので、メンバーには「自分が満足するまでやりきったのか」って必ず聞くようにしています。それで本人が「満足した」と言い切ったら、あとは私たちの責任です。メンバーはベストを尽くしたのだから、あとは責任者である我々マネージャーの腕の見せどころ。お客様に対してしっかりメンバーの仕事を説明しますし、より高い顧客満足を実現するために私たちが技術的なアレンジやサポートを入れたりすることもあります。次も彼らが満足できるように私たちは支援し続けていけば彼らの成長につながっていくんじゃないかなと思っています。

いい話ばかりだった

コロナ下でフルリモートワークをしながら、ローカルワークに思いを馳せる

コロナ下で、多くの人々がリモートワークを経験していると思います。その中で、リモートワークこそが「正しい」労働環境であるという主張を見かける事もあります。もしかしたら、そうなのかもしれません。

  • 自宅から職場までの移動。
  • Slack や議事録にまとめられていない、すれ違いの 10 秒で交わした会話。
  • 隣のチームから聞こえる仕事とは関係無い笑い話。
  • エレベーターを通って売店まで移動する合間に見えるオフィスの外の風景。

そんな必要ない物がスッキリ整理された、ノイズの無い理想的な労働環境。

残念ながら、私にはその様に思う事ができませんでした。リモートワークによって、今まであったものが何か失われてしまっている。この感覚が、私の心の中にずっと残り続けています。

相手の表情から意図を汲み取り、身振り手振りを交えて伝えたい事を表現しようとする。対面で人と話す事というのは、やる事の多い、ストレスのかかるコミュニケーションの仕方です。論理的な文章や、課題との因果関係が明確なデータがあれば、非同期的で非対面なコミュニケーションをしていた方がよっぽどストレスがかからないでしょう。しかし、ストレスがかかる事との引き換えに、同じチームで同じ物を作っている感覚や、言葉だけでは表現できな情熱を伝えるといった事ができていた気がします。

正直同意できない

いわゆるSESの嫌なところを言語化してみると、それは時間をお金に変える仕組み...

いわゆるSESの嫌なところを言語化してみると、それは時間をお金に変える仕組み。

仕事の本質ってニーズに対する定性的な成果と、感謝を表す物品の交換だと思ってる。

これを定量化する為に時間とお金を交換するようになったわけだけど、SES業界にはそれに慣れて目が曇ってる人が多すぎる気がしてる。

@uskitdesign

そういう観点からすると、成果を時間以外の尺度で定量化する方法が潜在的に求められていて、それをやると確実にイノベーションになると思ってる。

@uskitdesign

何言ってんだこいつ(真顔)

仕事の本質は生み出した価値とそれに対する対価ということなら、それはまぁそうだろうが、その言い回しは必要だろうか。

SESが時間を潰していれば換金できるところがクソというのも、まぁ概ね同意である。

時間を潰していれば利益が発生するビジネスモデルの何が問題かと言うと、技術者の市場価値向上のモチベーションが生じないこと。

企業にとってもエンジニアにとっても座ってるだけで一定の利益が見込める/給料が保証されるのだから、更に勉強したり学習に投資する理由がない。

結果として低レベル人材を大量に生産してしまうので業界どころか日本全体にとって害悪である。

エンジニアリングマネージャーとしてどんなことをしているのか?

契約単位が作るだけとか保守するだけとかになってて、となると合理的にその契約に特化するのが正解に...

契約単位が作るだけとか保守するだけとかになってて、となると合理的にその契約に特化するのが正解になる。作る契約でその後のこと考えての言動は、理想論で足引っ張ってるように感じてしまうのかもしれない。「言ってることはもっともだけど、そんなこと考えてたら終わらないでしょ」と。。。

@irof

直感に反するかもだけど、経験的に保守とかのことを考える方が早く終わるんだよなぁ……余計なもの作らなくて済んだり、「決めの問題」とか言ってふわふわしがちなものを主体的に決められるようになるのが大きい。

@irof

スコープを定めると「その中でだけやる」ってことがある。脇目も振らず邁進するために視界を狭めるとかの選択もある。その過程で「本当は使える情報だけどシャットアウトしてしまっているもの」ってあるんだろなぁ。

@irof

実際問題、ひとつのプロダクトに長期に関わることは無いのであれば、保守性などを考慮する必要はないという発想は正しいものではある。

フリーランスのエンジニアはそういう人も多い。

客が逃げにくいようにしてからバンバン値上げというORACLE DB商法が怖いのでOracle Cloudは使う気になれない...

客が逃げにくいようにしてからバンバン値上げというORACLE DB商法が怖いのでOracle Cloudは使う気になれない。「複数のOracleDB利用システムがあれば、全部保守に入るか全部入らないかどっちかしか選べない」とかいろいろ無茶された恨みは忘れない。OracleDBが入ったシステムはもう買うな、が合い言葉

AWSに何故にそこまで執着するのか理解しかねる。

ガンダムの世界で言うなら、一年戦争時代のモビルスーツに執着するようなものか。

みんな、Oracle Cloudにおいでよ。グリプス戦役時代のモビルスーツに移ろうぜ。

@takehora

@a_saitoh

まじめに書くと、Oracle DBがエンタープライズ向けにシフトして弱小顧客のつかうDBじゃなくなったのにきづかずに使い続けたのが悪い。ただ、一度入れたら5年とか7年は使わざるを得ないので途中で価格政策を変えられると辛い。

@a_saitoh

OracleさんはC/S全盛期にヘイトを買い過ぎた感があるのと、データセンター事業でもかなり身勝手なことをやって信頼を落とした実績がある。

米Oracleおよび日本オラクル(以下、オラクル)は、国内で自社運営のデータセンター(以下、DC)を間もなく開設するのに伴い、富士通の国内DC内に設置しているクラウドサービス「Oracle Cloud」を利用する顧客企業に対し、自社DCへ移行するように交渉を進めていることが、関係者の話で分かった。

ワイがインターンで書いたコードの保守に年間200万かかってる話思い出してバハハって...

ワイがインターンで書いたコードの保守に年間200万かかってる話思い出してバハハってなってる

@yashiro_ld

これは本当にありふれた話で、結構な大手企業でも新人の手習いとして作らせた社内システムがいつの間にか重要なインフラに成り果ててしまい、どうにもならなくなってリプレイスを外注するというケースが腐るほどある。

そうなると困るのは引き受けた外注先のエンジニアで、明確な仕様はないのでリバースエンジニアリングからしなくてはならないし、所詮新人が作ったものなので、不具合なのか仕様なのかの判断を付けることは困難だしで大抵炎上する。

組織を見るエンジニアのための『四象限』

実はDDDってしっくりこないんです

いいコミットメッセージの共通点と書き方〜便利なテンプレートやチーム開発時のお作法まで詳しく解説〜

ドメイン駆動設計について DroidKaigi 2017 で登壇しました。

行政文書はMarkdownで管理できるか

mercari / merpay SRE Tech Talk

これは後で見よう

CI/CD Conference 2021

今日だった

Docker Desktopが有料化へ、ただし250人以下かつ年間売り上げ1000万ドル(約11億円)以下の組織や個人...

Docker Desktopは個人利用など下記の条件では引き続き無料で利用可能。

Docker Desktop remains free for small businesses (fewer than 250 employees AND less than $10 million in annual revenue), personal use, education, and non-commercial open source projects.

Docker Desktopは、スモールビジネス(従業員数250名以下かつ年間売上高1000万ドル以下(訳注:1ドル110円換算で11億円))、個人利用、教育機関、非商用のオープンソースプロジェクトであれば、引き続き無料でご利用いただけます。

つまり251名以上もしくは11億円以上の企業でDocker Desktopを利用する場合には、有料となります。

料金プランは月額5ドルの「Pro」、月額7ドルの「Team」、月額21ドルの「Business」の3種類。TeamとBusinessは以前からDocker Hubの料金プランとして存在しており、新規に「Pro」が追加された形です。

正直、開発用途ではDocker Engineがあれば十分なので別にDocker Desktopはいらないのだが。

そして、本番運用を想定したコンテナレジストリはGCPやAWSのそれで十分というか課金するならそっちにするし。

kubernetesがDockerを捨てたようにローカルの開発用途からもDockerが捨てられたりするのだろうか。

開発者としてはDockerfileやdocker-compose.ymlが問題なく動作するならバックエンドがなんだろうと興味ないし。

そう考えると一瞬で代替が生まれてDocker Desktopが捨てられそう。

fzipp/gocyclo - Go-lang用の循環的複雑度測定ツール

ふむふむ

Software Design連載 2021年8月号 Python製のレガシー&大規模システムをどうリファクタリングするか

Ubuntu Linux 20.04 LTSに、Androidの画面をPCに転送するscrcpyをインストールする

面白そう

開発組織をデザインするための3つの観点

ベイジのウェブ制作ワークフロー2021年版(約100のタスクと解説)

しゅごい

イーロンマスクの「開発の5ステップ」をまとめました - あなたの要件はアホだし、そのプロセスも要らない...

開発の中では以下の順序を必ず守らないといけません。

  1. 要件をアホのままにしないこと。誰しもがアホにするので疑う

  2. プロセスを削除する。無駄なのを積みたがるので徹底的に減らす

  3. シンプル化・最適化する

  4. サイクルを速くやる

  5. 自動化する

職務経歴書/履歴書からカルチャーフィットを読み解く方法

本当に素人が簡単に稼げるようになるスクールがあるのなら、そもそもスクールやらずに会社やって...

本当に素人が簡単に稼げるようになるスクールがあるのなら、そもそもスクールやらずに会社やって未経験素人を教育して現場送り出す方が遥かに儲かるかと思うのですが…

@PoisonEngineer

それ以上いけない

20年前の「障害の再発防止策の考え方」は今でも通用する説

障害の再発防止策は、

  1. メカニズム

  2. ツール

  3. ルール

  4. チェックリスト

の順番に検討せよ。

CoeFont STUDIO/CoeFont CLOUD

CoeFont STUDIOでは最新のAIによって、自然な音声を無料で生成できます。動画の音声・プレゼンスライドの読み上げなどの幅広いユースケースで利用できます

しゅごい

june29さんとランチ会をしました (2021/8/5 木)

SESのエンジニアって、仕様書に書いてなければいちいちバグや使いづらさを指摘しないですよね?実際にSESの...

SESのエンジニアを使いたがる会社や組織はそもそも品質を求めていない(納期の方が優先)という理由もありそう。

漬け水に浸かる

朱に交われば赤くなるみたいな話で、ダメな文化を持つ集団に属しているとその「ダメな文化」が内面化されてしまう。

実際に思い当たる事例も多い。

やはりエンジニアは定期的に転職を繰り返すべきなのだ。

保守性の高いソフトウェア開発のTips集

よい

ユニットテストにまつわる10の勘違い

挫折しないドメイン駆動設計

ぼくのかんがえたフロントエンドアーキテクチャ

ドメイン駆動開発を浸透させるための新しい取り組み

SQLModel - O/Rマッパー

要するにシンプルで高機能なO/Rマッパーらしい

昔は自宅サーバに音声ファイルや動画ファイルをめちゃんこ貯め込んで、ブラウザ経由や独自通信で...

昔は自宅サーバに音声ファイルや動画ファイルをめちゃんこ貯め込んで、ブラウザ経由や独自通信で観たり聴いたりできる仕組みを自作したり改良したりしていた昔の若者ことオジサン達が、年齢を重ねて「これでいいじゃん」と音楽クラウドを使う様になり、最近その手の方面の技術が廃れてきてる気がする。

@mattn_jp

これ、これじゃん。

昔は GUI が大好きでちょっとしたツールにもフロントエンド作ったりして極めすぎて自作 GUI ライブラリまで作った昔の若者ことオジサン達が「これでいいじゃん」とブラウザを GUI 代わりにする様になり、最近 GUI ライブラリ方面の技術が廃れてきてる気がする。

@mattn_jp

まぁしゃーない

OpenStackの誤謬みたいなやつ、多いよね……。

OpenStackの誤謬みたいなやつ、多いよね……。

(「Pythonを選択しておけばみんな書けるよね!」-> 「そもそも分散システムの闇と戦う力の方がよほどレアだったでござる……他の言語を習得するコストなんかネグリジブルで、Pythonしか書けないような人は戦力として意味がないでござる……」)

@hito

COBOLから連綿と続く「〜しておけば誰でもプログラム書けるよね!」の失敗パターンやんけ

ソフトウェアシステム開発は本質的に難しいのだ

Nelua

Lua風のスタイルながらインタプリタではなくコンパイル型でネイティブバイナリを出力する言語らしい。

あと型チェックもある。

OSS X Users Meeting #31

見ている

みずほが事故起こすたびに「1から作り直せばいいのでは?」っていう人が出てくるんだけど「いや...

みずほが事故起こすたびに「1から作り直せばいいのでは?」っていう人が出てくるんだけど「いや東日本大震災で大障害起こして1から作り直した結果がこれなので…ちなみに35万人月・4千億円かかってまして…」と言いたくなる('ε'*)

@fstora

門外漢の外野からアレコレ言われてるの見るとちょっと同情心が湧いてきちゃうアンビバレンツな感情あると思います

jmoiron/sqlx

SQLの結果を構造体に自動的にバインドしてくれるライブラリらしい。よさそう。

「SES」って言葉。本質的に、多重派遣の代替品を、サービス名であるかのように言ったものだからね...

「SES」って言葉。

本質的に、多重派遣の代替品を、サービス名であるかのように言ったものだからね。

それが本質ならばそれでいいけど、受託も準委任も契約形態であって、顧客に提供する価値が別のものであるならば、SESを自称する事はやめるべきなんだよ。

ソフトハウスは。

@WjgotINrU14Z1fB

昔は、ホントにただ「準委任」って意味で使ってた。それはそれでいいんだけど。

対顧客・SI商流とかで、お綺麗に価値提供してる世界とは違う世界が、結構な規模に肥大化してるみたいだ。

それをSESと呼ぶ層がいて。

語源・字面、どっちで見ても、彼らの使い方の方がハマってるわな。

@WjgotINrU14Z1fB

別にアプリでもインフラでもいいけど。

システム全体を一社で提供し切るような立ち位置じゃなくてもいいけど。

提供してるもの、責任持つものが開発だったら、開発会社だわな。

システムエンジニアリングサービスとか言う、別のものではないと思うぞ。

@WjgotINrU14Z1fB

常駐が悪だかなんだかは、メリデメも語れないやつが言ってるだけの話であって(今は既に常駐もほとんどしてないけど)

そいつら、低い知見の連中に表現を合わせて差し上げる必要性は、もうないと思うよ。

そのくらいデメリットが大きくなった。

SES会社の業態の多様化によって。

@WjgotINrU14Z1fB

て、マックでJkが言ってたぜ。

@WjgotINrU14Z1fB

実態にしろマインドにしろ人材派遣会社でしかないし、受託ではないから結果に責任も取らず、それを習い性にしてしまうから他で潰しも効かない似非エンジニアを量産してしまう。

どう取り繕ったとしても害となる側面の方が大きく、したがってSESは法律で禁止されるべきである。

Ubuntuに日本語を話してもらおう

興味あり

「エースと呼ばれる人が抜けても何とかなる、会社とはそういうものだ。」とは言われるけど、実際見たこと...

「エースと呼ばれる人が抜けても何とかなる、会社とはそういうものだ。」とは言われるけど、実際見たことあるのは補充人員も来なくてボロボロになるケースと、委託先の協力会社の人が何とか支えてるケースなんだよな…

@kanna21st

メンバの離脱が仕事の見直しにつながるのはそうだろうけど、実はやらなくても良かった仕事をなくす・許容範囲内で品質を落とす、により残ったメンバでも何とかやっていける…というのは1つのシナリオでしかないと思うんだよね。

@kanna21st

「やれる人(エースや協力会社の人)がいたからやってただけで、本音では別に撤退してもいい」みたいな悲惨なケースあると思います

業務分析をする上でデータモデル技法は不可欠だと思います。椿正明さんのTHモデルや佐藤正美さんのT字型ER手...

Tの字は、業務分析というか概念分析を進めるための手法であるところが偉大です。実は手法と自称する大半は、実は成果物の列挙だったり単なる注意書きだったりして、手法とは言い難いものです。Tの字はちゃんと手法です。ただし、業務分析が中心であって、業務改革のネタ出しにも使える一方で実装にはあまり触れられていません。ちゃんと概念がモデリングされてれば後は簡単だろ、という主張であり、ちゃんとしたSEがついていれば開発も問題はないので、手法としての欠点とは言えません。

実装に向けてはTHの表現力がプログラム設計、DB設計とも近いものがあります。帳票やスキーマまで表現する力はTHのほうが強いです。たとえば典型的な例としては、Tの字には在庫の概念がありません。しかしヘタクソへの耐性はやや低いです。その分、教育するところに力を入れているので、これも手法としての欠点ではありません。

TPS(トヨタ生産方式)入門

Goのアーキテクチャとフレームワークについて

マイクロフレームワークに関する考え方は殆ど同じだけど、一度自分なりの考え方を言語化しておいてもよさそう

ソフトウェアエンジニアとしての姿勢と心構え

BCP想定を上回ったニップンへのサイバー攻撃についてまとめてみた

SESだと自社に知見が貯まらないというツイートを見かけたけど、それは本来の専門的技術を持った人が...

SESだと自社に知見が貯まらないというツイートを見かけたけど、それは本来の専門的技術を持った人が専門家として自律的に行動してサービスを提供するSESではないのではなかろうか。事実上の派遣のようになっているから、知見が貯まらないのではないだろうか。

@tomooda

現実問題として、SESは事実上の派遣として扱われることが大半なのだから仕方がない。

SES企業の顧客としてはJITで人員を手配できる機能が重要なわけで。

専門家として自律的に行動〜というのはSES企業のエンジニアは求められていないことも多い(そういうのは元請けSIerやコンサルの仕事という切り分けがされがち)。

まぁ、SESなどやるべきではないということである。

小規模プロジェクト、大規模プロジェクトの見積もり

小規模(S)

全体で参加する技術スタッフが5人以下のプロジェクト。

中規模(M)

5人から25人程度のメンバーで構成され、3ヶ月から1年程度継続するプロジェクト。

大規模(L)

半年から1年以上継続する25人以上のプロジェクト。

大規模は言うに及ばず、中規模ですら失敗確率が高いので極力小規模に抑えた方がよい

実践! Typescript で DDD - マイクロサービス設計のすすめ

アーキテクチャが過剰である気はするんだよなぁ

JJUGナイトセミナー「Kubernetes Native Java」

アメリカから登壇する予定の登壇者が現れず司会進行の人達がトークしてたw

タイムゾーン違うと厳しいよね

弊社はもう10年前にはSES事業撤退したけど、撤退理由は「1人月拘束されると頑張っても所在人数×単価しか儲から...

弊社はもう10年前にはSES事業撤退したけど、撤退理由は「1人月拘束されると頑張っても所在人数×単価しか儲からないし非稼働が出ると詰む」「会社に知見が貯まらない」「現場で人を増やしてそこから受託開発に繋げるなんて幻想」こんな所だったと思います。

@TETRA_IT

ゼロから始める、データ分析と可視化

ソフトウェアプロセス改善手法 SaPID 導入の壁と工夫

SaPIDとは?

SaPIDは、当事者自らがシステム思考を活用して対象のメカニズムをシステムとして構造的に捉え、最も効果的で現実的な箇所、あるいは新しい価値創出に有効な施策・対策をうち、成果をあげていくための手法です。

特定の個人が実践することも可能ですが、チームや関係者、組織のメンバーが参画し、デザイン思考を併用して一緒に成長する、そして新しい価値を共創する方法を併せ持つのがSaPIDの特徴です。

とらのあなラボ Tech Conference

今日だった

Pythonでリアクティブプログラミングしてみる

Rx某ってスマホアプリの文脈でよく見かけるなーと思ってたけど、Pythonにも存在したのか

データを変換する処理はやっぱり関数チェーンで宣言的に書ける方がよい

【Podman v3】ルートレスモードでdocker-composeを実行する

Ubuntuでもできるのかな?

理想のチームに近づけていくために

「次から気をつけます」に対抗する、反省文よりは効果が上がる再発防止、学びの機会

計算判断ロジックに焦点を合わせたクラス設計のやり方

計算判断ロジックに焦点を合わせたクラス設計のやり方。

①アプリケーションの対象領域(ドメイン)で扱う値の種類(型)を特定する

②値の種類ごとに、その値に対して実行したい計算判断の関数を列挙する(関数の集合として型を定義する)

③データとロジックを一つのモジュールに集める(カプセル化)

@masuda220

NEXT