Replit(旧Repl.it)は、アメリカ サンフランシスコ を拠点とした企業によって運営されているオンライン統合開発環境である。 Replitを利用することにより、開発環境を構築しなくともブラウザでプログラミングを行うことが可能である。[4] Replitという名前はREPLに由来する。これは"Read–Evaluate–Print Loop"(読んで 解析して 出力して 繰り返す)の略である。 Amjad Masad,Faris Masad,Haya Odehらは、2016年に同社を起業した。[1][2] Replitを使用することで、ユーザーはブラウザ上でコードを記述し、アプリやWebサイトを作成できる。 このサイトには、ライブチャットフィード技術を利用したリアルタイム共同編集機能等といった、さまざまなコラボレーション機能もある。また、 Java、Python、HTMLを含む50以
フィーチャートグル[1]（feature toggle、機能トグル。別名としてfeature switch（機能スイッチ）, feature flag(機能フラグ), feature flipper(機能切替スイッチ), conditional feature(条件付機能)など)は、ソフトウェア開発 において、複数のソースコードのブランチ（機能ブランチ）を維持するのとは別の方法を提供しようとする手法である。 継続的リリースと継続的デプロイは、コーディングについてのフィードバックを開発者たちに頻繁に提供してくれる。これを実現するには、複数の開発者たちのコードを可能な限り早期に統合することが必要になる。機能ブランチはこの過程に抜け道を作ってしまう。機能トグルを利用すれば、開発者たちはメインのトラックに頻繁にソースを統合しつつも、開発中の機能へ入っていける実行経路のトグルを「OFF」にしておけば
As developers, we love to customize our environment, and to build tools that fit our unique preferences and workflows. We do this not just because it improves productivity and ergonomics, but also, because it makes our daily routine feel more personal. And when things feel personal, they’re typically more fun. However, while we may invest in things like managing dotfiles, writing automation script
［速報］GitHub、自然言語による指示だけでアプリケーションを生成する「GitHub Spark」テクニカルプレビュー公開 GitHubは、日本時間10月30日未明に開幕したイベント「GitHub Universe'24」で、自然言語による指示だけで、パーソナライズされた小規模なアプリケーション（Micro-App）をすぐに生成できる「GitHub Spark」の テクニカルプレビューを発表しました 。 下記はGitHub Sparkのデモとして公開された動画の一部をキャプチャしたものです。 例えばユーザーは、ダッシュボードから「An app for me to log all the cities I've travelled with a review and star rating」（これまで旅行したことのあるすべての都市のレビューと星の数での評価を記録するアプリ）のように、作りた
てとらα SI @TETRA_IT 顧客「システム保守費はやった分だけの実績支払いにしたい。何もなければ0円という事で。ただ何か起きた際には24.365で駆けつけてすぐに対応してくれ。対応した分はもちろん払うぞ」 2024-09-21 11:17:19
ソフトウェア品質保証（ソフトウェアひんしつほしょう、英: software quality assurance, SQA）は、ソフトウェアの適切な品質を保証するために、プロジェクトで使用されるソフトウェアエンジニアリングプロセスと方法を監視する手段と実践である[1] :10-5。ISO/IEC 9126 （現在はISO 25010で置き換え）、SPICE、CMMIなどの規格があり、適合を求められる場合もある[2]。 これには、管理者や開発者がソフトウェア製品と活動をレビューおよび監査して、ソフトウェアが標準に準拠する品質基準を満たしていることを確認するために使用できる標準と手順が含まれる。 Automotive SPICE（ ISO/IEC 15504に基づく）によると、ソフトウェア品質保証は、すべての作業成果物、アクティビティ、およびプロセスが事前定義された計画と品質戦略に準拠しているこ
はじめに 個人でフロントエンド(react)、バックエンド(node.js)、データベース(postgreSQL)を利用したWebサービスを公開したいと考えていました。 まずはテスト的に無料で外部公開できるサービスがないか調査しましたが、2022年8月に有料化されたHerokuの記事ばかりヒットしてしました。 結果的には無料で使用できる構成があり、実際にテストプログラムを動作させることができましたので構成例として記載しておきます。 ※無料なので比較的厳しい条件も含まれていたりするのでそれぞれのサービスを確認お願いします。 例えばsupabaseは数日間利用がないとインスタンスが一時停止して手動で起動させないといけないなどがあります。 今回試したサービス できるだけ同じサービスに集約したいと考えていましたが、実際にはフロントエンド、バックエンド、データベースはそれぞれ異なるサービスになってし
見積りとは何か？ 2023年12月2日 この記事は 10X アドベントカレンダー 2023 という企画の 2 日目（12/2）の記事です。 1 日目（12/1）の昨日は岡野さん（@operandoOS）による「CI を高速化する技術 ⚡️」でした。 はじめに この記事の内容は以下の本の第一章とほぼ同じ内容となります。この記事の読んで見積りについて興味が湧いたらぜひ以下の書籍に目を通してみてください。 出典 ソフトウェア見積り 人月の暗黙知を解き明かす 早速ですが見積りしてますか？おそらくソフトウェアエンジニアの方であれば、こんな感じで会話して見積りした経験が 1 度はあるんじゃないでしょうか？ プロダクトマネージャー「機能xyzの件だけど、開発期間はどのくらいだと見積もってる?」 ソフトウェアエンジニア「1ヶ月ですね。」 プロダクトマネージャー「長すぎる。1週間で何とかならないか。」 ソフ
In software development, effort estimation is the process of predicting the most realistic amount of effort (expressed in terms of person-hours or money) required to develop or maintain software based on incomplete, uncertain and noisy input. Effort estimates may be used as input to project plans, iteration plans, budgets, investment analyses, pricing processes and bidding rounds.[1][2] Published
これはなに？昨年末にOpenAIがリリースしたチャット型AIの「ChatGPT」と一緒にデザインしていくプロセスで、実際にどんなことができるか？を実験してみたnoteです。 前提と注意点 🚨まずこのnoteの趣旨は「これらが実用的にデザイン制作に使える！」といったものではありません。 どちらかというと遊びに近く、実験的に行ったもので、結論から言うと現時点では実用的に使える要素はまだ少ないかなと思います。 また、前提として私はまだまだAIやChatGPTについて詳しいわけでは全くなく、これからちゃんと勉強してみようと思ってるぐらいのレベル、という前提で読んでいただけると幸いです。 （AIについて本を読んだり座学的な勉強から入るより「とにかく何かしら触ったりつくったりしてみる」方が楽しめると思い、せっかくなのでその実験の過程をまとめてみました。） 「こういうこともできるよ」「このやり方の方が
リーダーのための「スクラムガイド」手引き
リーダーのための「スクラムガイド」手引き | Scrum.org © 2022 Scrum.org. All Rights Reserved. ｜ 1 リーダーのための「スクラムガイド」 手引き YUVAL YERET、DAVE WEST 著 長沢 智治、KYON_MM 訳 | 2022 年 5 月 リーダーのための「スクラムガイド」手引きの目的 この手引きは、スクラムチームを率いている、あるいは、スクラムを活用している組織のリ ーダーのためのものである。この手引きでは、スクラムのさまざまな要素に目を向け、リー ダーがその要素に取り組むための効果的な方法を考察している。この手引きは、スクラムガ イド 2020 版向けである。 スクラムを適用する際のリーダーシップの定義は多岐にわたる。リーダーは、スクラムチー ムの内側にも外側にも存在している。誰もが、ある程度のリーダーシップを発揮している。
サイトの開発が遅れたことによる契約解除の可否が問題となった事例。 事案の概要 ＸはＹに対し、美容業界のメーカー、ディーラー、ユーザーらが情報交換を行うためのウェブサービスに関するアプリケーションソフト（本件アプリ）の開発を委託した（本件契約）。 途中で、ＸＹ間は、クレジットカード決済機能を追加し、代金を496万8000円（税込）とすることなどを合意した。ＸはＹに対し、前記代金を3回に分けてほぼ全額支払った。 Ｘは、履行期である2019年3月（具体的な履行期は争いがある。）経過後の5月31日に、 スケジュールやテスト画面もいただけなく，全く状況が分かりませんし，これ以上進めるのは不安です。 もうプロダクトはいただかなくて結構ですので，最短で返金をお願いしたく思います。 と、中止を伝え、開発作業が終了した。 Ｘは、その後、文書による催告と本件契約の解除を通知し、原状回復請求権に基づいて、支払済
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: 医療機器開発ガイド 第2版 開発前から市販後までのステージ別、規制対応の指針: 菊地眞: 本
Amazon.co.jp: 医療機器開発とベンチャーキャピタル 実践編: 大下創, 池野文昭: 本
