API開発のためのプログラミング言語"Ballerina"の直感的な構文について解説します。認証や承認、OpenAPIツール、可観測性、SQL/NoSQLクライアントライブラリなど、重要な言語機能についても論じます。記事を読み終えれば、Ballerinaが次のバックエンドAPI開発の有力な候補である理由がよく理解できるでしょう。2022年4月InfoQ編集チームが2022年に進化するソフトウェアアーキテクチャと設計のトピックをどのように見ているかの概要です。アーキテクトが今、何を設計しているかに焦点を当てています。Pan氏が、分散データベースシステムにおけるシャーディングアーキテクチャのパターンについて論じます。ShardingSphereプロジェクトがデータシャーディングの課題にいかに対処しているかを説明した上で、DistSQLを使って分散データベースと暗号化テーブルを生成する方法の実例2つを論じています。カルチャー&手法カオステストで、見えない課題からアプリケーションのレジリエンスを改善するこの記事では、Netflixが提唱するカオステストの原則を列挙した。読者は、カオステストが提供するメリットとデメリットを理解できるはずだ。することで、カオステストを行うかどうかの判断材料となる。リスクに対するすべてのメリットを考慮して、カオステストを行うために経営陣を説得すべき理由も説明した。原文(投稿日:2018/03/07)へのリンクあなたのリクエストに応じて、ノイズを減らす機能を開発しました。大切な情報を見逃さないよう、お気に入りのトピックを選択して、メールとウェブで通知をもらいましょう。ソフトウェア開発や何か大規模なものを作ることを本当に推し進めるには、自分の盲点を探り、(自分自身を含む)人々とのやりとりを学ぶ必要がある。自分たちが作る文化は自分たちが使う技術と同じくらい重要だ。高いパフォーマンスのチームと低いパフォーマンスのチームの生産性と品質は桁違いだ。どのようにやるか、は、何をやるかと同じくらい重要だ。2018で、Googleでのチームの開発とコーティングについての経験を話した。InfoQはこのカンファレンスの模様をインタビューや記事で取り上げている。InfoQは氏にインタビューし、ハイパフォーマンスなチームを作ることについて、そして、エンジニアリングが栄える条件を確立することについて話を聞いた。ハイパフォーマンスなチームを作るのに関する主な問題は何でしょうか。誰もがヒーローになりたいと思っている世界にすべてがあります。現実には、上出来なコードはあなたを成功に導きません。たくさんのコードを書けるのは、自分の時間を最大限活用するのをやめてからです。多くの人々が関わるほど、何をしているのかよりも、どのようにして行うのかをもっと注視する必要があります。本当に進歩しているならば、特に他の人と大企業で働いているならば、人を扱うことを学びます。他の人とのやりとりを教えてくれる人はいません。やってそれを理解するか、ということです。この点について、時間を投資するなら、私は、デール・カーネギーだと思います。カーネギー曰く、私たちの成功の85%は人と接する能力に依存していて、専門技術に依存するのは残りの15%だけです。これはとても怖いことです。私は技術を身につけ、私にとってうまく働く仕組みを見つけなければならないことに気づきました。しなければ、本当に仕事をすることができないのです。十分ということはありません。私はGoogleでの自分の多くの時間を社員同士がより互いに話すようにすることに使っています。物事や振る舞いの中には都合がよいので実行してしまうが、長い目で見た場合はためにならないことがあります。私たちは実際に会って話すよりもテキストメッセージやメールを送りますが、これは、良いコミュニケーションの方法ではありません。考えを伝えるとき、言葉はそれほど効果的ではありません。面と向かって話すよりも文字でやりとりする世界では特にそうです。逃げるか戦うかの反応が引き起こされることもあります。私たちがどのように振る舞うかは生活の中で習慣づけられています。これは解きほぐすのがもっとも難しい振る舞いのループです。習慣になっていること自体に気づかないからです。自分ではうまく動作していると思っているが、実際にはそうではない頭の中の配線に盲点があります。どこに盲点があるかを探し始めると他人に対してうまく受け答えできるようになり、受け答えを理解できるようになり、相手より優勢に立つにはどうしたらいいかわかるようになります。この壊れた人間機械にどのように対処すればいいでしょうか。盲点を学ぶことから始めます。このような盲点がありのか理解するためにモデルを学び、自分の脳には考えに強力に影響を与えるものの自覚して制御できない部分があることを理解します。有用なモデルとして三位一体脳説があります。これは、私たちの意識の進化を表すモデルです。脳の意識の部分の下にふたつの動物の層があり、乱暴に言えば、それぞれの層がワニと馬に対応しています。動物の脳は特有の動機を持っています。ワニの脳は食べ物や安全、暖かさ、繁殖に関心があります。馬の脳は社会的受容や人気に関心があります。血は動物の脳から意識の脳へと流れています。動物の脳は気にくわない考えに対する拒否権と、目的に沿った考えを促進する能力を持っています。それゆえ、私たちは動物の脳の観点で物事を処理してしまい、そのことに気づきません。広告会社もこのことを知っています。フェラーリのディーラーにいる45才のワニの脳に、もし車を買えばたくさん子孫が増やせる、と伝えれば、車の美しさはもはや関係ありません。その一連の考えに対するたくさんの承認が得られます。反対に、高いビルの端から飛び降りようとすると、ワニの脳は反対をして、そのような考えをする脳の部分への血流を止めます。これは逃げるか戦うかの反応でも発生します。ワニの脳が生存を左右する筋肉へと血を流そうとするからです。これによって、合理的な判断をする脳は停止します。健康な関係を欲するなら、逃げるか戦うかの反応に陥るような状況に人を置かないようにする必要があります。エンジニアリングが盛んになる条件を満たすにはどうすればいいでしょうか。私たちが作り出す文化は私たちが使っている技術と同じくらい重要であるということを受け入れる必要があります。幅広い多様な考えと視点から最高の解決策を見つけるためには、誰もが貢献できるようにする必要があります。そのためには、大きな図を理解する必要があります。獲得していない知識やスキルを見つける必要があります。自分たちから始めて、自分たちの失敗しやすさを理解し、それを、仲間やユーザーに対する理解の糸口にします。人々の集まりをそれぞれ人の掛け合わせになるようにする方法を理解します。この点でリーダーの役割が重要になります。チームにやることを指示するのではなく、サーバントリーダーのモデルでチームのファシリテートします。その仕事をやる理由を理解するのを手助けするのです。皆を手助けすることで運用の仕方が改善されます。私は誰かにコードの書き方を教えることはほとんどありません。これは単にソフトウェアを作ること以上のことです。私たちの働く環境であり、意思決定の能力であり、移譲することであり、間違いから学ぶことであり、アイディアを共有し作ることなのです。ハイパフォーマンスなエンジニアリングチームとそうでないチームの違いは生産性と品質の大きな違いです。自分たちを超えた大きなスケールのものを作りたいなら、このようなことをする必要があります。本当にうまくいったことのひとつは、ツールの電子メールがどれほど貧弱であるかを人々が理解できるようにすることでした。疲れているとき、機嫌が悪いとき、感情的な返信になりそうなときは、メールを返してはいけないというルールはとても強力でした。私たちはまとまりのないメールを書いて、誤解を招くことがあります。そのまま返信するよりも、会って話して意図を理解した方がよいのです。相手の意図とあなたの受け取ったものは似ていません。対面のやりとりをするように促すこと。同じ部屋にいることで生まれる親密さによって相手とより簡単に共感できるようになります。ポジティブな振る舞いを認識するように促すこと。研究によると、感謝の言葉を言ったり、努力の価値を認めたりした場合、そうしない場合に比べて、助けてもらえる可能性が2倍になります。ポジティブな振る舞いを認識すればするほど、ポジティブな振る舞いに出会えるようになりのです。私に不賛成を表明すること、そして、互いに不賛成を表明すること。あることをする理由や解こうとしている課題は全員が知っているべきです。理由を説明しなければ、間違ったことをしてしまいます。私が間違うこともあります。この点を人々の前で認めることです。重要なことにフォーカスすること。私は、皆に時間の使い方を選ぶように指示しています。ミーティングに価値がないなら、出席しなくていいのです。ミーティングの数が多くなると脳内のリソースを支配するようになります。ミーティングは少ない方がいいです。役に立つことをしましょう。フロー状態に入れるようにするためです。Spolsky氏のコンテキスト切り替えについての記事を読み、啓発されました。皆が成功/成長しなければならない。Pink氏のモチベーションについての動画をリトマス試験紙として使います。人々が自主性や学習/成長の機会を感じていないなら、彼らの関与は低いままです。成果ではなく結果にフォーカスすること。大きな図を見失わさせるバグや機能一覧によって、私たちは迷子になることがよくあります。チームの誰もが素晴らしいものを作れるようなひらめきを得られる環境を作りたいと思っています。"あるxという機能を作る"が成功であると見なすなら、解決しようとしている課題を見失っています。正しいひとつの方法にこだわらずに結果にフォーカスすること。解決策はたくさんあります。私たちはフレームワークや言語、デザインパターンを巡る聖戦に巻き込まれました。その議論に費やしたエネルギーによって、解決しようとしている実世界の課題への注意が失われます。ソフトウェアエンジニアリングは有用でなければなりません。有用であれば、人々は目的意識を持つことが容易になります。毎週火曜日に前週のまとめコンテンツをお送りいたします。(日本語版は不定期リリース)25万人のシニアな開発者コミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。登録するとさまざまなことができます。アカウント登録をしてInfoQをお楽しみください。あなたの意見をお聞かせください。毎週火曜日に前週のまとめコンテンツをお送りいたします。(日本語版は不定期リリース)25万人のシニアな開発者コミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。Inc.プライバシーBT。