マイクロソフト、Blazorでデスクトップアプリやモバイルアプリを開発できる「Blazor Hybrid」は.NET MAUIベースになると説明
マイクロソフト、Blazorでデスクトップアプリやモバイルアプリを開発できる「Blazor Hybrid」は.NET MAUIベースになると説明 マイクロソフトは2月9日にオンラインでコミュニティイベント「ASP.NET Community Standup - Blazor .NET 7 Roadmap」を開催。Blazorの開発状況や今後の展開などについて説明しました。 https://t.co/eFOzgs22K8 Community Standup - Blazor .NET 7 Roadmap https://t.co/Veq88bsGrw — The ASP.NET Team (@aspnet) February 8, 2022 Blazorは、C#などの.NETテクノロジーを用いてWebアプリケーションの開発を可能にするフレームワークとして登場しました。.NETの知識や経験をW
バージョニングの見直しとタグ・リリース作成の自動化 - LIVESENSE ENGINEER BLOG
データプラットフォームグループ Livesense Brain チームの富士谷です。 機械学習基盤 Livesense Brain の開発・運用を行っています。 ここでは、Livesense Brain で開発するシステムのバージョニングの見直しと、 GitHub Actions を使ったタグ・リリース作成の自動化について紹介したいと思います。 はじめに Livesense Brain では、開発するシステムのほとんどをコンテナ化しており、大きく「アプリケーション」と「コンポーネント」の2つに分けて開発しています。 「アプリケーション」は、例えば「マッハバイト向けのレコメンド」といった、特定の事業部向けにデータやサービスを提供するコンテナイメージを指します。 また、全社向けのA/Bテスト基盤（Brain Optimizer）も「アプリケーション」に位置づけています。 一方、「コンポーネント
だんだん開発スピードが遅くなっていくのをどうやってとめたら良かったんだろう？ - Mitsuyuki.Shiiba
先日、モブプロをやってきた。その中で、モブプロとは別で、いくつか感じたことがあって、今日はその中のひとつを思い浮かんだままにメモ。 bufferings.hatenablog.com 要件を満たすプロダクトをより早く出す モブプロでTDDしながら、要件を満たすプロダクトをより早く出すことに集中してみた。例えば、第２ラウンドのお題はTDDBCなどでお馴染みの「自販機」。 「100円を入れてボタンを押すとコーラが1本買えること」 最初に「100円を入れてボタンを押すとコーラが1本買えること」と言われ。 assertThat(get(100), is("コーラ")); みたいなテストを書いて。 String get(int money) { return "コーラ"; } みたいな実装を書いた。爆速！ 「200円を入れてボタンを押すとオレンジジュースが1本買えること」 次に「200円を入れてボタ
日本企業にアジャイルを導入して考えたこと #easg - arclamp
2016年11月18日に行われたエンタープライズアジャイル勉強会11月セミナーにて「ユーザー企業へのアジャイル導入四苦八苦」という講演をさせてもらいました。資料は後段に。 エンタープライズアジャイルとは 「エンタープライズアジャイル」の定義は曖昧です。いわゆるエンタープライズ業界でもアジャイルをやっていこう、という方向性を合意しつつ、そのディテールは現場ごとに異なります。 弊社はSIerなので、別顧客で3つの事例を紹介しています。もちろん内容は異なりますが、いずれも以下のような条件になります。 顧客は日本企業で社歴が数十年以上 システムはいわゆるSoE領域（間接的にでも売上に寄与する） 10人ぐらいのチームが継続的に維持される規模 こうした案件を通じた学びはフィードバックサイクル、プロダクトオーナー、アーキテクチャの三点です。 フィードバックサイクル 企業システムではリリースサイクルを「3
不安とストレスから解放される見積りとスケジュール方法 - Qiita
エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 はじめに 何かはじめてのことをする場合、人はとても「不安」を感じます。人は未来を考えることができる生き物です。その特異な能力ゆえに、未来に起こるかもしれないよくないことを考えると「不安」を感じてしまうのです。 仕事のプロジェクトなどは、「間に合わなかったらどうしよう」とか「この仕事はちゃんと終えられるのだろうか。」など、未来のことを
Twitter製の大規模ソフトウェア向けビルドツール「Pants」を試してみる - たけぞう瀕死ブログ
PantsはTwitter社が開発した大規模ソフトウェア向けのビルドツールです。今年の5月に1.0がリリースされました。 github.com 主にPythonで書かれているようですが、Java、Scala、Python、Golangのビルドに対応しており、Thriftのコード生成やMarkdownからのドキュメント生成などもサポートしているようです。 同種の大規模向けビルドツールにはGoogle製のBazelやFacebook製のBuckがあります。 github.com github.com いずれも元は社内用に開発されたツールがOSS化されたものですが、GoogleのBazelは2009年頃からGoogle社内で使われておりかなり歴史のあるツールのようです。 BuckやPantsはBazelを参考にしているようですが*1、BuckはAndroidアプリのビルドが高速だったり、Pant
サーバからクライアントに送信する技術 - WebSocketを中心に - Qiita
Webでのプッシュ技術 HTTPはクライアント（ブラウザ）からリクエストしてサーバからレスポンスが返る一問一答型のプロトコルなので、基本的にはサーバ側からブラウザに新着情報をリアルタイムで通知（プッシュ）できるようにはできていません。 しかしそれでもプッシュをしたいという場合にどうするかという話が出てきます。やり方には以下のようなものがあります。 ポーリング クライアントからサーバに定期的に新着を問い合わせるようにします。 最も原始的かつ確実なやり方。欠点は、最大でポーリング間隔の分だけ通知が遅延しうることです。 ロングポーリング（“COMET”） ポーリングなのですが、問い合わせを受けたサーバは新着情報がなければレスポンスを返すのをしばらく保留します。 そのあいだに新着情報が発生すれば即座にレスポンスを返しますし、一定時間経過したら何もなかったとレスポンスを返しましょう。 飛び交う通信内
ノウハウの共有文化がない場所にコードレビューをねじ込んでみた結果とか - タオルケット体操
「コードレビューをキメると品質も上がるし自分のレベルも上がるので最高」みたいな論が巷を賑わせていて、以前はそういうイケてる制度を指をくわえてみるのみだったのだけれど、最近職場と、それと個人的に関わったプロジェクトでコードレビュー制を無理矢理交渉して導入してみた結果、世間のイケてる書籍やエントリから得られる情報とはまた少し違う知見が得られたので書いてみる。 割と泥臭かったり、あまり希望に溢れてたりはしない感じのエントリなのでそういうのは期待しないほうがいいです。 準備 些末なコードレビューを極力避けるために、コードの規約やスタイルについてはlintとフォーマッターを用意した。 他は無策。 結論 結論から言うと、理想的な運用は出来なかったものの、コードレビューについて世間で言われるような成果（作業を共有する意識、レベルの向上）は得られた。良かった。 ぶっちゃけ僕なんかが浅はかな考えで導入しても
Microsoft – クラウド、コンピューター、アプリ & ゲーム
すべての Microsoft 製品 Global Microsoft 365 Teams Copilot Windows Surface Xbox セール 法人向け サポート ソフトウェア Windows アプリ AI OneDrive Outlook Skype OneNote Microsoft Teams PC とデバイス Xbox を購入する アクセサリ VR & 複合現実 エンタメ Xbox Game Pass Ultimate Xbox Live Gold Xbox とゲーム PC ゲーム Windows ゲーム 映画とテレビ番組 法人向け Microsoft Cloud Microsoft Security Azure Dynamics 365 一般法人向け Microsoft 365 Microsoft Industry Microsoft Power Platform W
社名変更のお知らせ
Fringe81株式会社は2021年10月1日より、Unipos株式会社として生まれ変わりました。 コーポレートミッションを「感情報酬を社会基盤に」と新たにし、ピアボーナスをさらに発展させ、感情報酬を社会実装して社会の基盤とすることを最上位の目標として掲げ、邁進して参ります。 5秒で自動的に切り替わります。切り替わらない場合は以下のボタンをクリックしてください。 Unipos株式会社サイトへ
仕事で使ってる巨大SVNレポジトリをGithubに移管するためにやったことまとめ · DQNEO日記
動機 Subversionで困ってない ぶっちゃけSubversionで全然困っていませんでした。 コードレビューはちゃんとやっていたし、マージ・ブランチングも自作シェルスクリプトのおかげてスムーズにやれていました。 よく「Gitはマージが賢い、ブランチ作成が一瞬でできる」とかいわれますが、Subversionだってちゃんと使えばコンフリクトなんかめったに起きないし、ブランチ管理・マージだって全然めんどくさくない。 特にver1.7からはサーバもクライアントも大幅に高速化されたし、.svnディレクトリが.gitみたいに１個になったし、rebaseみたいなことだってできる。(sync merge & reintegrate) ただ、世の中が一斉にGitにシフトしている中でいつまでもSubversionを使っててよいのかという不安がありました。 また、月から金までSubversionにどっぷり
犬小屋と高層ビルの違い - give IT a try
ちょっと興味深いエントリを見つけました。 IDE教育に不安を覚えること - みねこあ なるほど、Smart UIと呼ばれる作り方が、システムの品質を下げるという点は同意です。 ただ、その原因がIDEにあるのかというと、必ずしもそれだけではない気がします。 おいらが思う一番の原因は、犬小屋と高層ビルの作り方の違いに気づいていないプログラマが多いせいではないかと思っています。 つまり、「はじめてのXXX」とか「一週間でわかるXXX」みたいな本やWeb記事には、ごく基本的な文法の説明や簡単なサンプルプログラムの作り方しか載っていません。 こうした説明のほとんどはSmart UIパターンになっていると思います。 もちろん初心者向けの内容なので、簡単な内容に終始してしまうのは仕方ありません。 しかし、ここで説明されているのは、いわば犬小屋の作り方です。 実際に業務でシステムを構築する場合は犬小屋レベ
プログラマの思索: TestlinkがExcelのテスト仕様書よりも素晴らしい点
TestLinkはオープンソースのWebのテスト管理ツール。 TestLinkがExcelのテスト仕様書よりも素晴らしい点を書く。 【0】インストールが超簡単 XAMP＋TestLinkが一体化されたパッケージがある。 解凍して起動するだけ。 USBメモリに入れて持ち歩くことさえできる。 【1】テストケースを再利用しやすい シナリオベースのテストケースは、運用保守や2次開発でも頻繁に使う。 実際は、1次開発で使ったテストケースを複製して、仕様変更や追加機能を反映させる。 この時、Excelのテスト仕様書から該当のテストケースを抽出したり、変更するのに手間がかかる。 また、テストケースは書く人によって、粒度や書式が大きく異なる時が多い。 後の保守で再利用できなかったりする。 TestLinkの場合、テストケースはDBにあるから複製が簡単。 また、TestLinkの入力フォーマットが固定されて
プログラマの思索: バージョン管理できないプロジェクトの成果物は信用できない
「バージョン管理が原因だとしたらかなりヤバイよ三菱東京UFJ」「三菱東京UFJのトラブルの原因が日経コンピュータに載ってます」の記事を読んだ感想を書く。 【1】デグレ発生が意味するもの 三菱東京UFJのトラブルの原因は下記の通り。 かいつまんで書くと「テストは充分にしていたが、バージョン違いのモジュールを本番リリースしてしまった」ということのようです。 上記の記事を書いた人は、事件の重大性が分かっているのだろうか？ 本番リリース時にデグレが発生したという事実は、下記の意見と全く同じ。 つまり、下記の記事のように、プロジェクトの成果物全てが危険な状態にあるのではないか？という事実を示唆させるからだ。 ところが、デグレやバージョン相違は違います。最新バージョンでないものを使って修正した結果、直したはずのバグや仕様変更が落ちたり、リリースするファイルを間違えてしまったりするのは手続きを遵守でき
プログラマの思索: Subversionのブランチを有効活用してアジャイルに開発せよ
デブサミ2008講演資料の「SubversionとMaven 2 による構成管理」を読んで、改めてソフトウェア開発ではソース管理が最重要であると再認識した。 ソース管理について振り返ってみる。 【1】ソース管理の歴史 ソフトウェア開発では、ソース管理が必須だ。 ソース管理の本質は、履歴を辿って、いつでもソースをUndo、Redoできること。 昔のコンピュータ資源が希少な時、そもそもプログラムを履歴に残すことすらできなかっただろう。 今でもリリース時によくやるように、システム一式を複製して日付でリネームしていた。 僕は当初、ソース管理に、MSのVisualSourceSafeを使っていた。 CVSよりも直感的でGUIが使いやすい。 VSSを使い始めてから、下記の作業がルーチンになった。 朝、出社後、VSSから最新ソースを落として、VisualAgeForJavaのワークスペースにインポートす
【Facilitation】解けない問題を解ける問題へ変換する - プログラマの思索
「ザ・ファシリテーター2―理屈じゃ、誰も動かない!」の本で「解けない問題を解ける問題へ変換する」という挿話がある。 ファシリテーションを得意とするコンサルタントが、ある病院にやってくる。 そこでは、医師と事務のお偉方が「前年度よりも20%手術件数を増やす」という課題について議論していた。 しかし、その会議では、医師は忙しいのだ、医師の数が足りないという堂々巡りの議論ばかり。 そこへコンサルタントがひょっこり入ってきて、状況を聞いた後、現在の医師の人数から、手術可能な件数を計算させてみると、あら不思議、かなり余裕がある。 コンサルタントが「医師の時間の使い方を調べて手術に使える時間を20％増やす」へ問題を置き換えると、医師も事務方も途端に積極的な意見が出始めた。 この挿話では、解けない問題を解ける問題へ変換すると、人は自然に解決する方向へ動き出す、というエピソードで括られていた。 この話をシ
404 Blog Not Found:惰訳 - 建築士がプログラマーのごとく働かねばならぬとしたら
2007年10月26日01:45 カテゴリ翻訳/紹介Art 惰訳 - 建築士がプログラマーのごとく働かねばならぬとしたら 全プログラマーが泣いた。 If architects had to work like programmers... 実は一つだけ「ローカライズ」にあたって変えた前提があります。日本ではこちらの方が実情に沿っているでしょう:) 建築士様、 家を一つ設計施行してくださいな。まだ何が必要か具体的なことはわからないので、そこはよきに計らう方向で。 寝室の数は、2から45までの間。寝室の追加と削除は簡単に出来るようにしといて下さいね。青写真が出来次第あたしが何が気に入ったかを最終判断します。それぞれの青写真について明細書を付けるのをお忘れなく。後で気に入ったのをピックアップできるように。 完成後の家の費用は、今住んでいる家よりも安上がりでないと駄目なことを留意してくださいな。そ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Stack Overflow
スラッシュドット・ジャパン | ベテランプログラマを管理するには?
スラッシュドット ジャパン | 分散型バージョン管理システムはどれが良い?