顧客の要望から要件定義、システム生成まで自動化する「Babel」 OSSの「Zoltraak」がコア
AIと量子コンピューティングの研究開発を行なうKandaQuantumは、2024年8月31日、顧客の要望内容を元に自動的に要件定義を生成し、さらに自律的にシステムを構築する要件定義システム生成AI「Babel（バベル）」をリリースした。 Babelは一行の要望から要望一覧、要件定義まで一気通貫で記載する。「要件定義プログラミング」により、自然言語からコードへの直接変換を実現。顧客の要望やビジョンを入力するだけで、Babelが詳細な要件定義のYAMLファイルを自動生成する。その上で生成された要件定義に基づき、Babelが独自にシステムを設計、開発。技術的な詳細を指定することなく、望む機能やふるまいを記述するだけでシステムが構築される。
Babel が Flow から TypeScript に移行した
先日 Babel のメンテナーとして知られる Nicolò Ribaudo 氏が次のツイートを投稿した。 We finally finished migrating the Babel monorepo from Flow to TypeScript! It has been a very long process started by @z_bodya, and after migrating package-by-package @JLHwung just opened this PR 😄 pic.twitter.com/WKXxV8x2MY — Nicolò Ribaudo 🏳️🌈 • 💙💛 (@NicoloRibaudo) July 23, 2022 そう、JavaScript のトランスコンパイラである Babel のソースコードが Flow から TypeScrip
全ての道はRomeへ続くのか - これからのJavascript開発を考える
Romeとは 現代のJavascript開発には多くのツールチェーンが必要とされます。Babel,webpack,Jest,ESLint,Prettier,Typescriptなどを組み合わせて開発することが多く、さらにこれらの一部代替選としてesbuild,SWC,Viteなどのツールチェーンの選択肢が存在し、選択肢の多さやその組み合わせの複雑さに苦い思いをしたことがある方も少なくないのではないと思います。 こうした中で、新たに開発が進められているツールチェーン、Romeをご存知でしょうか？ Romeは先に挙げたように複数のツールチェーンを役割ごとに組み合わせて使うのではなく、1つのツールチェーンでこれら全ての役割を担ってしまおうという壮大な計画を持つツールチェーンです。 Romeは2020/03にFacebookより発表されました。現在は法人化され、yarnやBabelの生みの親である
Ubie がスタートアップだからこそ OSS に寄付をする理由 | Yuku Kotani
いま働いている Ubie で OSS に寄付していくことを決め、まず手始めに JavaScript トランスパイラの Babel に$500 の寄付を行いました。日本のスタートアップが OSS に寄付をするのはまだあまり目にしないため、Ubie がスタートアップだからこそ OSS に寄付しようと考えた理由をご紹介します。 スタートアップにこそ OSS が必要 時間も体力もないスタートアップは、とにかく最速で事業を成長させなければならず、OSS が高速道路としてそれを支えてくれています。 これは極論ですが、OSS が全てなくなったとき、そのまま事業を続けていく自信が皆さんにはありますか？少なくとも僕にその自信はありません。体力のある大企業であれば内製する選択もできそうですが、スタートアップでは OSS なしにはビジネスを成し得ない場合が殆どではないでしょうか。 OSS が持続せずに困るのは、
トランスパイラ「Babel」の開発チーム、「何百万人にも使われているのに、なぜ私たちの資金は尽きようとしているのか？」。資金難により寄付を訴え
トランスパイラ「Babel」の開発チーム、「何百万人にも使われているのに、なぜ私たちの資金は尽きようとしているのか？」。資金難により寄付を訴え 「Babel」は、JavaScriptコンパイラもしくはトランスパイラの代表的なツールとして知られており、FacebookやSpotify、Slack、MongoDBなどさまざまな企業や開発現場で使われています。 そのBabelの開発チームが資金難になっていることを、開発の中心となっているコアチームがブログ「Babel is used by millions, so why are we running out of money?」（Babelは何百万人にも使われているのに、なぜ私たちの資金は尽きようとしているのか？」で明らかにしています。 Babelとは、ECMAScript 15以降のいわゆるモダンなJavaScriptの構文や機能を活用して書
Hugo で React + TypeScript を利用してサクッとウェブサイトに RSS リーダーを追加する
はじめに Hugo のウェブサイトに組み込む RSS リーダーを TypeScript で開発してみたいと思い調査したところ、Hugo の最新版には ESBuild が組み込まれていて、非常に手厚く JavaScript の開発環境がサポートされていることが分かりました。 本記事では紹介していませんが Babel も利用できるようです。 また、NPM パッケージも利用できるため、普段のウェブ開発と同様の流れで開発ができ、各種ライブラリを用いた開発も非常に楽でした。 今回は Hugo で JavaScript 開発する方法を RSS リーダーの開発を例に上げ、そこで得た知見についても交える形で記事として残しておくことにしました。 ちなみに本記事内容は Hugo で JavaScript 開発する方法に焦点を絞ったものなのですが、ウェブサイトに RSS リーダーを組み込むことに焦点を絞って見た
Google App Script を V8 に切り替えたらものすごい速くなった - Qiita
この記事は衝動的な動機によって書かれており、事実を正確に捉えるのに必要な証拠に欠けていることを予め断っておきたい。 また、分かりやすい数字というものは人間の良からぬ想像力を掻き立てる災いのもとになることも思い出して欲しい。この記事にはなるべく事実だけを書くことにして、自分の推測は「〜かも知れない」とか「〜と思う」と書くことにする。この記事を読まれたみなさんが何らかの推論をコメントやツイッターに書き散らしたい衝動にかられた時は、ぜひ同じことを実践して欲しい。 GAS のランタイムで V8 エンジンが使えるようになった ソース https://developers.google.com/apps-script/guides/v8-runtime?hl=ja#enabling_the_v8_runtime Google App Script (以降 GAS) とは、Google スプレッドシート
Simpacker: Rails と webpack をもっとシンプルにインテグレーションしたいのです - クックパッド開発者ブログ
技術部の外村（@hokaccha）です。Rails で webpack を使うためのシンプルな gem を作ったのでそれについて紹介します。 Webpacker Rails で webpack を利用した Web フロントエンドの環境を作る場合、最近では Webpacker が選択されることが多いでしょう。Rails 6 からは Webpacker が標準になることもあり、この流れはますます加速すると思われます。 私自身もこれまでいくつかのプロジェクトで Webpacker を利用してきました。Webpacker は webpack を Rails から簡単に利用でき非常に便利なのですが、使っているうちにいくつか不満な点がでてきました。 一番大きい問題として Webpacker が @rails/webpacker という npm パッケージに webpack の設定を隠蔽し、Webpac
2019年版: 脱Babel!フロント/JS開発をTypeScriptに移行するための環境整備マニュアル - Qiita
2019年版: 脱Babel!フロント/JS開発をTypeScriptに移行するための環境整備マニュアル環境構築TypeScriptライブラリReact TL;DR いろいろ書いていますが、一番書きたかったのは最初のライブラリと最後のReact Componentのプロジェクトの作り方ですね。ぱっとnpm installして、最初から型定義ファイルが入っていて、@typesを持っているライブラリを探したり、自分で.d.tsを書いたりしなくてもいい世界がやってきて欲しいな、という気持ちから書いています。 ここで紹介したTypeScript環境構築はすべて、自分用にYeomanのテンプレートとして作成したので、以下のジェネレータをインストールして選択したらそれでおしまいです。 @shibukawa/typescript (npmには公開していないので、checkoutしてビルドしてインストール
Webpackerを導入してから外すまでをふりかえる - 弥生開発者ブログ
こんにちは、@mugi_unoです。 MisocaでjQuery製のフロントエンドコードを書き換え続けていた結果、技術書典6に参加することになりました。現在必死で書いております。 farewell_webpacker さて、先日とあるブランチがmasterにマージされ、リリースされました。 farewell : ごきげんよう！、さらば！ farewellの意味・使い方・読み方 | Weblio英和辞書 farewell_webpacker です。 長い間フロントエンドのビルドにはRailsのGemであるWebpackerを使ってきましたが、現在は完全に依存を外しており、純粋なwebpackビルドを行う形に書き換えました。 正直なところ、フロントエンド界隈からは否定的な意見を聞くことも多いWebpackerですが、実際にある程度の期間プロダクションで利用してみて、良いところも辛いところも両方
転職エントリ - 素人がプログラミングを勉強していたブログ
これまで 新卒で入社したWeb系IT企業で1年4ヶ月ほど新規事業部門でブログサービスの開発などをしていました。チームでやってるサービスと自分個人が結びつくのもあんまり良くない気がするので会社名は書かないけど、本日が最終出社日なので振り返ってみます。 やったこと フロントエンド周りを中心にやりました。 JavaScript、Node関連ではrollup, babel, prettier, eslintなどを導入したり、すでにあったコードのリファクタリングを行ってES6 Modulesを導入したりしました。 その他、色々なバイナリを入れたりコンパイルをして動かす必要のある部分などもdockerを使って一から環境構築することなくビルドできるようにしたり、CSSはSassを使っていたものをPostCSSに変更したりしました。デプロイ周りのフローもAWSに繋いでる部分を自動にしたり色々気になったとこ
自分流の静的ウェブ開発環境 2018年版 - Qiita
出来上がったもの(2018年9月) ソースコード この記事は半起半眠みたいな状態で書いたので、文章が壊滅している可能性がありますがご了承ください。 dependencies yarn add -D parcel-bundler babel-core babel-preset-env css-mqpacker eslint eslint-config-precure husky lint-staged node-sass node-sass-package-importer parcel-bundler parcel-plugin-imagemin parcel-plugin-inlinesvg postcss postcss-short postcss-sorting pug stylelint stylelint-config-recommended-scss stylelint-scs
ServiceWorker内でBabelを駆使して、JavaScriptをビルドする - ログミーTech（テック）
2018年9月5日、第70回となる「HTML5とか勉強会」が開催されました。今回のテーマは「開発環境」。 Webフロントエンドの開発環境をテーマに、エディタプラクティスやServiceWorkerを開発ツールとして使うアプローチ、長期運用されたサービスのリニューアル方針など、登壇者たちがその知見を語ります。プレゼンテーション「ServiceWorker Side XXX」に登場したのは、mizchi氏。ServiceWorkerを駆使したある取り組みについて紹介します。講演資料はこちら 開発環境のためにServiceWorkerを使う mizchi氏（以下、mizchi）：では「ServiceWorker Side XXX」ということで発表させていただきます。mizchiです。よろしくお願いします。 （会場拍手） ちょっと自己紹介とかはする気ないんですけど、最近本を書いたので、その紹介だけ
社内勉強会 TechLunch で"JavaScript AST ことはじめ"という発表をしました | MEDLEY Developer Portal
2018-06-22社内勉強会 TechLunch で"JavaScript AST ことはじめ"という発表をしましたみなさん、こんにちは。開発本部エンジニアの平木です。こちらのブログの投稿自体はほぼ 1 年ぶりになりそうな勢いですが、みなさまお元気でしょうか? 弊社で定期的に開催してる社内勉強会 TechLunch で自分の順番が回ってきたため、どうしようか迷った末にJavaScript AST ことはじめという発表をしたので、そのことについて書いていきます。 なぜ JavaScript AST について話そうと思ったのか現在、弊社のエンジニアメンバーのバックグラウンドで一番多数派なのは「元サーバサイドエンジニア」です。もちろん、業務ではサーバサイド・フロントエンド・ネイティブアプリとバックグラウンドに関わらず、必要に応じて分け隔てなく開発しています。 とはいえ、ちゃんとサービス開発自体
babel な ESLint の設定をがんばった
やんなくちゃなー、と思っていたので Lint Like It’s 2015 — Medium を眺めながら、ahomu/es6-Kameita の JavaScript Linter を ESLint に乗り換えました。 Lint の設定つくるのがダルイ問題 本当にだるい。この投稿を書いている時点では .eslintrc を以下のようにしました。 スペースの入れ方については、強い意志をもって堅めの設定になっているはず。 max-params はちょい甘めです。consistent-this を全力で否定しているので、流用したい方は気をつけた方がよろしいかと。 { "parser": "babel-eslint", "env": { "browser": true, "node": true }, "rules": { "strict": 2, "default-case": 2, "no-
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
