IoT製品やIoTサービスを開発するうえでは、通信回線/SIMの高いコストや管理の手間、ソフトウェア開発の工数といった、いくつもの足かせがある。そうした障壁をまとめて解消し、IoT開発をより容易なものにしてくれるのが、低容量IoT向け回線の「1NCE IoTフラットレート」だ。 ドイツ発のIoT通信専業グローバルキャリア、1NCE(ワンス)が提供するこの回線は、1枚2000円(税抜)のSIMカードを購入するだけで、10年間/500MBまでのIoT通信を利用できるプリペイド型の料金体系を採用している。日本およびアジアではソフトバンクが販売パートナーを務めており、日本語によるサポート体制(電話/Web)もあって安心だ。 さらには「1NCE OS」として、IoTデータを変換してクラウドと連携するための各種サービスも、追加コストなしで利用できる。これによってソフトウェア開発のハードルがグッと下がり
チェコのJetBrainsは、これまで7年間にわたって行ってきた、変化し続ける開発者の状況と使用されている主要なテクノロジを関連付けるための、開発者エコシステムアンケートにおける2023年の調査結果のうち、JavaScriptとTypeScriptの内容について、3月7日(現地時間)付の公式ブログ投稿にて紹介している。 2023年の開発者エコシステムアンケートは、世界中の26348名の開発者を対象に行われた。同調査では、7年連続でJavaScriptが世界でもっとも多く使用されているプログラミング言語であることが明らかになっており、JetBrainsはその理由として、JavaScriptがフロントエンドWeb開発のための、障壁の低い言語だからであると指摘する。なお、JavaScriptのシェアはここ3年間少しずつ低下しているものの、この低下はTypeScriptの採用増と同時に発生している
バイデン政権は2024年2月26日(現地時間、以下同)の週、悪質な国家やハッカーが悪用する重大な脆弱(ぜいじゃく)性を減らすための取り組みの一環として、メモリ安全性の高いプログラミング言語の採用について主要業界の支持を集めた。 メモリ安全性の高いプログラミング言語の使用に賛同の声 SAPやAccenture、Palantir、Hewlett Packard Enterpriseなどの大手テクノロジー企業は(注1)、メモリ安全性の高いプログラミング言語の採用を支持している。スタンフォード大学やオックスフォード大学の関係者も、ソフトウェアの測定性を向上させる取り組みを支持している。 ホワイトハウスの国家サイバー局は、2024年2月26日に報告書を発表し(注2)、テクノロジー業界に対して製品にメモリ安全性の高い言語を広く採用するよう呼びかけるとともに、研究コミュニティーに対し、安全なソフトウェア
Redisがライセンスを変更、BSDライセンスからRSAL/SSPLデュアルライセンスに Redisは2024年3月20日、次のバージョン(Redis v7.4)以降、これまで採用してきたBSD 3条項ライセンスから、RSALv2(Redis Source Available License)もしくはSSPLv1(Server Side Public License)のいずれかを選択するデュアルライセンスに移行することを発表した。 Redis Adopts Dual Source-Available Licensing | Redis Today, we announced that all future versions of Redis will be released with source-available licenses. Starting with the releas
ソフトウェアアーキテクチャはシステムの成功に不可欠な要素であり、ソフトウェア開発者にはこの分野における効果的なスキルが求められる。しかし、その学習資料はまだ十分ではないのが現実である。株式会社えにしテックの代表取締役 島田浩二氏は、ソフトウェアアーキテクチャに関する書籍を多数翻訳している。Developers Summit 2023 Summerに登壇した島田氏は、数々の書籍から学んだソフトウェアアーキテクチャの重要なエッセンスを紹介した。 ソフトウェアアーキテクチャとは? 3つの定義を紹介 島田氏は2009年に株式会社えにしテックを設立。2011年からは一般社団法人日本Rubyの会の理事を務めている。島田氏が翻訳に携わった書籍には、『進化的アーキテクチャ』『ソフトウェアアーキテクチャハードパーツ』、『ソフトウェアアーキテクチャの基礎』『Design It!』(いずれもオライリージャパン)
Linux FoundationのGreg Kroah-Hartman氏は12月6日、Open Source Summit Japan 2023の基調講演に登壇し、Linuxカーネルのセキュリティの現状と今後の課題について、さまざまな観点から議論した。安定版Linuxカーネルのメンテナーであり、Linuxカーネルセキュリティチームの主要メンバーでもあるKroah-Hartman氏は、講演の中で、オープンソースソフトウェアのセキュリティを取り巻く状況の変化や、規制上の課題、そしてこれらの問題に対するLinuxカーネルの対応について語った。 ソフトウェアのセキュリティに関する問題が毎日のように発生する中、各国政府は、セキュリティの問題を軽減すべく、企業やさまざまな組織を指示に従わせようとしている。しかし、そこには1つ問題がある。それは、政府はソフトウェアがどう使われているかをほとんど理解してお
本調査は6月に、GitLabのソーシャルメディアチャンネルおよびメーリングリストを通じて行われ、世界中のさまざまな業種・規模の企業に所属する開発・IT運用・セキュリティ部門の従業員およびリーダー1001人から有効回答を得ている。 調査結果によると、回答者の90%が「ソフトウェア開発にAIを活用中または活用予定である」と回答した。また、83%が「他社に後れを取らないように自社のソフトウェア開発プロセスへのAI実装が不可欠」と回答したのに対し、79%が「個人情報や知的財産にアクセスするAIツールに懸念」を示した。加えて40%が、「AIはすでにセキュリティ面で大きなメリットをもたらしている」と答えた一方、そのうちセキュリティ担当者の40%は「AIを活用したコード生成によってワークロードが増大すること」を懸念として挙げた。 AI導入の課題に関する項目では、95%の技術系上級幹部が「AIツールの選定
Elastic社のブログをきっかけに、最近見かける新しいライセンスについて個人的に調べてみた。私は専門家ではないので要注意。公開情報も隅々まで追えているわけではないし。 なお一部ライセンスはOpen Source Initiative (OSI)による承認を受けていないので、ここではオープンソースライセンスではなく単に「ライセンス」と書くことにする。 新しいライセンスが誕生している背景 従来のオープンソースライセンスが再頒布以外の利用をあまり想定していなかった。 Open-core modelないし完全オープンソース戦略を採る企業が自衛策を必要とした。 既存のライセンスが難解なため、理解しやすいライセンスが求められた。 OSS活動を収入に繋げるためのモデルが試行錯誤されている。 新しいライセンスを導入しているプロジェクト(一例) プロジェクト ライセンス Elastic SSPLと独自ライ
HashiCorpは2023年8月10日(米国時間)、Terraformをはじめとした同社の製品のライセンスを 「Mozilla Public License v2.0(MPL 2.0)」 から「Business Source License v1.1(以下、BSL)」に移行すると発表した。BSLは定義上オープンソースソフトウェアライセンスではない。このため、「オープンソース版」あるいは「OSS版」と呼ばれていたものは「コミュニティー版」と名称が変わった。 HashiCorpはさまざまな専門家やステークホルダーとの協議の上で、今回のライセンス変更に至ったという。 BSLはMariaDBが公開したライセンスモデルで、他にもCouchbaseやCockroach Labsなどが採用している。その内容は多くの点で、 Open Source Initiativeによるオープンソースソフトウェアの定
Overview The SAFe Overview is a visualization of the seven core competencies of Business Agility and the dimensions of each. Essential The Essential SAFe configuration provides the minimal elements necessary for ARTs to deliver solutions and is the simplest starting point for implementation Large Solution The Large Solution SAFe configuration is for enterprises building large and complex solutions
符合付き整数や有理数、浮動小数点数を扱う任意精度演算ライブラリで、オープンソースソフトウェアのGNU Multi-Precision Library(GMP)が、2023年6月16日にMicrosoftが保有する数百ものIPアドレスからDDoS攻撃を受けていると報告しました。Microsoftとその傘下のGitHubによる調査の結果、GitHubのユーザーがFFmpeg-Buildsのスクリプトを書き換えたことが原因であることが明らかになっています。 The GNU MP Bignum Library https://gmplib.org/ Microsoft's GitHub 'DDoSes' open source GMP project • The Register https://www.theregister.com/2023/06/28/microsofts_github_gm
作業はグループで進めるのが望ましい。1人でもできるが、プロジェクトに参画した複数のキーパーソンで議論したほうが、より客観的かつ網羅的に原因を究明できる可能性が高い。 ステップ1:全ての失敗原因を抽出 ステップ1では「ITプロジェクト版失敗原因マンダラ図」から全ての失敗原因を抽出する。図に示した第1レベル・第2レベルの原因全てについて、今回のプロジェクトの失敗原因として当てはまるかを確認。当てはまる全ての原因に丸印を付けていく。 作業は左下の「無知」から始めて「未知」で終わるよう、時計回りに進める。この段階では参加メンバーが個別に確認・記入していく。 メンバーは丸印を付けた項目について、具体的な事象を書き出す。「重要性の認識誤り」に丸印を付けたのであれば、「システムダウンが引き起こす社会的な影響を経営層は軽視していた」などと書く。 これは「抽象化と具体化」という技法に基づいている。具体的な事
インフラの環境構築を行ったときに、はい、環境です、と接続情報だけ顧客に提供したところで、そのまま受け取ってくれることはない。 ドキュメントはないんですか?。 何を作ったかを示すドキュメントとセットで初めて、プロにお金を払って仕事をしてもらった気持ちになる。今でも、ドキュメントを残せ、ドキュメントがないと今どうなっているかがわからなくなる、常に更新して最新にしよう、そんな掛け声は健在である。 このドキュメント、年々複雑さが増していると思う。というのも、IT関連のソフトウェアにしろクラウドにしろ、機能は増えるばかりだからだ。かつ、設定自体は年々洗練されており、デフォルト値で動くことも多い。たくさんの設定項目があるが、設定するのはほんの一部分である。 ドキュメントに何を残すべきか。設定値全てをドキュメントに書き込もうものなら莫大な量になる。一方で変更したものは少ししかない。このギャップが激しくな
Microsoftが、Windows 11およびWindows 10でスタートメニューや検索バーなどWindowsの一部の機能が、Microsoft OfficeのAPIを使う一部のソフトウェアと干渉して正常に動作しなくなるというバグの回避策を発表しました。しかし、一部のメディアは「Microsoftはまだこのバグを解決できていない」と報じています。 Windows 11, version 22H2 known issues and notifications | Microsoft Learn https://learn.microsoft.com/en-us/windows/release-health/status-windows-11-22H2 Microsoft: We haven't yet been able to fix Start, UWP, Office issues
日本はIT人材が足りない、という記事が出ていた。 ITの会社で働いていても、できる人の数は足りないと感じるが・・。 toyokeizai.net 日本はデジタル分野の専門人材不足が深刻化する「2025年デジタルの崖」に直面する。経済産業省によると、2020年には30万人、2030年にはデジタルサービスの需要次第で45万人から80万人にまで不足が拡大するとされている。後者の場合、日本が必要とする190万人の専門人材を4割も下回ることになる。 原因分析をいろいろ見ているんだけど、長らくITを見てきた立場から考えると、焦点がぼやけてると思うことが多い。 日本は他国に比べIT人材への給料が安い。それが事実として、1つかみしめなければいけない事実は、日本人が、ITのお仕事に対して生産性が他国より低い、という帰結である。 平たく言えば、IT分野に対して、他国人より日本人のほうが仕事ができない。だから給
ソフトウェアテスト講義ノオト: ASTERセミナー標準テキストを読み解く の 4.5 経験ベースのテスト技法 (1) エラー推測(P.191)に、このように書かれています。 推測は、「テスト担当者の経験、欠陥や故障のデータ、ソフトウェアが不合格となる理由に関する一般的な知識」にもとづいて行います。逆にいえば、経験と知識が貧弱であれば良い推測はできません。エラー推測によるテストで良い結果を出すためには、深い経験と高度な知識が必要ということです。これは、他の「経験ベースのテスト技法」でも同様です。 どうすれば、深い経験と高度な知識が身につくかというと、一件一件のバグを大切にするしかないと筆者は思います。具体的には、テストしてバグを見つけて直ってきたら、その原因について自分が納得するまで理解するの繰り返しです。 ”どうすれば、深い経験と高度な知識が身につくか”の具体的な方法が「その原因について自
ソフトウェア開発における品質のメトリクスについて、新旧2冊の本を比べてみました。 1冊は、『初めて学ぶソフトウェアメトリクス』。 原著『Five Core Metrics: The Intelligence Behind Successful Software Management』(Lawrence H. Putnam、Ware Myers著)は、2003年に出版されています*1。 初めて学ぶソフトウエアメトリクス~プロジェクト見積もりのためのデータの導き方 作者:ローレンス・H・パトナム,ウエア・マイヤーズ日経BPAmazon もう1冊は、『アジャイルメトリクス』。 原著『Agile Metrics in Action: How to measure and improve team performance』(Christopher W. H. Davis著)は、2015年に出版されて
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く