DX(デジタルトランスフォーメーション)の推進に向けて新規システムの開発が相次いでいる。開発するシステムが変われば実装のためのプログラミング言語にも変化が生じる。 日経クロステックは、エンジニアが使っている言語や開発環境について、継続してアンケートを実施している。そこで、こうしたアンケートの結果をまとめた。「いま選ぶべき言語」を知りたい人は参考にしてほしい。

米国の調査によれば、アジャイルが注目を集める中、この2年間でウォーターフォール型の開発に回帰する企業が増加傾向にあるという。 米国の調査会社Forresterによればアプリケーション開発者の間で、アジャイルへの移行が勢いを増している。 同社の調査「Q4 2021 Global State of Agile at Scale Survey」に回答した152人のうち60%近くが、アジャイルプラクティスを採用するための「5カ年計画」に着手している。10年前はわずか4%だったことを考えると大幅な増加と言える。 スケールに関する課題は残る。この調査の回答者のうち、自分のチームがアジャイルプラクティスに「高度に熟練している」と答えたのはわずか4分の1で、アジャイル変革を支援するための構造改革に十分に投資したと感じているのはわずか17%だった。 Forresterの調査では、前回の調査から2年の間にウォ
第1章:悪しきコードの弊害から痛みを知る仙塲大也氏(以下、仙塲):ここからは各章の紹介です。本書は1章から17章までの全400ページあります。第1章「悪しき構造の弊害を知覚する」。1章と2は、新卒さん向けの章です。「設計なんかぜんぜん知らないですよ」という方向けの章です。 そもそも設計って、「設計しなきゃ」という危機意識が必要なわけですね。その危機意識の醸成には、悪しきコードによる弊害を知覚する必要がありますよ。悪しきコードの弊害を数例用いてダイジェスト的に紹介して、痛みを知ってもらおうという章です。 第2章:「設計とは?」を学ぶ第2章「設計の初歩」。本格的な設計は3章の「クラス設計」から始まりますが、いきなりクラス設計となるとちょっと重いので。第2章で簡単な命名や小さいメソッドの設計とかをベースに、「どういうことをするのが設計なの?」というところを学びます。1章と2章をつうじて、設計がぜ
GitLabは、これまでGitLabが自社で開発し提供してきたWebIDEを、Visual Studio CodeベースのWebIDEへ移行していくと表明しました。 Here's what's coming next to GitLab Web IDE. https://t.co/1iHQrvR46a — GitLab (@gitlab) May 24, 2022 GitLabには以前から、Webブラウザの画面からコードを管理しつつ、そのままコードの編集などを可能にするWebIDE機能が統合されていました。このWebIDEはオープンソースのMonaco EditorをベースにGitLabが開発してきたものと説明されています。 今回の発表は、このWebIDEをVisual Studio CodeベースのWebIDEに置き換えるというものです(ちなみにVisual Studio CodeもMo
英マイクロフォーカス(Micro Focus)が2022年2月に発表した調査結果によると、世界中の企業や組織で現在使われているCOBOLコードの総数は7750億〜8500億行で、これまで推定されていた規模の約3倍に相当するという。 同調査では、回答者の92%がCOBOLを戦略的な言語として捉え続けていることも明らかになった。また前年の調査では回答者の52%が、所属組織におけるCOBOLベースのアプリケーションが少なくとも今後10年間は残り続けると答えたという。 筆者はCOBOLプログラムが増殖する日本の現場を見てきた。 COBOLコードの行数はプログラム1本当たり平均1000行といわれるが、ある企業のシステムでは平均の10倍である1万行のプログラムが散見された。既存のプログラムを理解して修正するのは困難なため、改修のたびにGO TO文(飛越し文)による分岐を繰り返してコードを追加していた。
「GitLab 15.0」では、Wiki用のWYSIWYGマークダウンエディタにおいてワークフローを高速化するためのいくつかの改善が行われており、コードブロックにて正確にシンタックスハイライトされ、好みのシンタックスハイライトのテーマを継承することが可能になるとともに、WYSIWYGエディタでのリンクやメディアの操作が容易になっている。 さらに、オープンソースのElasticsearchフォークであるOpenSearchに対応し、Advanced SearchでOpenSearchの機能を最大限に活用できるようになったほか、1つのグループが複数のイテレーションを同時に管理する機能が追加され、それぞれのチームがイテレーションケイデンスにおいて各イテレーションの開始日と期間を設定可能になった。 ほかにも、イシューに関する主要な詳細を公開したまま、特定のユーザーにのみ表示されるべき内部データまた
関連キーワード アプリケーション開発 | 開発プロセス | プログラマー | プロジェクトマネジメント | スキル 「スクラム」は、開発チームのメンバーに役割やタスクを割り振り、メンバー同士の連携を取りながらプロジェクトを進める開発手法だ。スクラムにおいて、チーム全体の調整役を担う人を「スクラムマスター」と呼ぶ。 IT担当者に「スクラムマスターの専門家」と称することを認めるオンライン学習コースや試験は複数ある。ただしスクラムマスターには明確な業界標準がない。そのため認定資格の質や難易度、認定資格が保証する能力は、認定資格ごとに大きく異なる。 本連載は、スクラムマスターとして職務経歴書に記載できる5つの認定資格を紹介する。スクラムマスターとして成功を収めたい、あるいは次期プロジェクトでスクラムマスターのプロフェッショナルを雇用したいと考える開発者の参考になれば幸いだ。 認定資格1.Profe
皆さんこんにちは。今回は、2022年4月30発売の『良いコード/悪いコードで学ぶ設計入門』を読み終わったので、書評という形で感想と紹介を述べたいと思います。筆者はもともと技術書を読まず「ネットでいいやん」派だったのですが、このたびTypeScript入門書を出版したこともあり、それを過去の話として葬り去るべく技術書を読んでいくことにしました。せっかくなので、読んだ技術書の感想等を紹介します。 おことわり: この記事では、「筆者」とはこの書評を書いた人を指し、『良いコード/悪いコードで学ぶ設計入門』を書いた人のことは「著者」と呼びます。また、この記事の内容はすべて筆者の個人的な見解であり、本の内容や本を読んで得られる知識について何らかの保証をするものではありません。 筆者について筆者はフロントエンドエンジニアで、TypeScriptとReactを専門としています。業務では何だかんだで設計の番
template< class T > const T& min( const T& a, const T& b ); template< class T, class Compare > const T& min( const T& a, const T& b, Compare comp ); // C++11 template< class T > T min( std::initializer_list<T> ilist ); // C++11 template< class T, class Compare > T min( std::initializer_list<T> ilist, Compare comp );
Notionを使ったプロダクト開発管理のノウハウを紹介する「実践!プロダクトづくりとNotion活用事例」。ここで株式会社TechBowlの大木氏が登壇。PM目線から見た、Notionのメリットと活用法を紹介します。 自己紹介 佐々木真氏(以下、佐々真):じゃあやっていきたいと思いますので、よろしくお願いします。タイトルが「Notion×プロダクト作り最強活用法」というところですが、今日は15分しか時間がないので、できるだけエッセンスをお伝えできればなと思っています。 あらためて自己紹介です。私はTwitterにはこのアイコンでいます。佐々木真と申します。プロダクトマネージャーで、PM Clubの主催者をしています。過去に事業売却したり、起業したり、現在はIT企業で顧問をしたり。あとは、シンガポールの法人で取締役をやっていたりもするので、「何やってんだかよくわかんねぇ」みたいなこともありま
"固定ポインター" を宣言します。これは共通言語ランタイムでのみ使用されます。 すべてのランタイム (この言語機能にはランタイムに適用される特記事項がありません。) Windows ランタイム (Windows ランタイムでは、この言語機能はサポートされていません。) 共通言語ランタイム "固定ポインター" は、指されているオブジェクトがガベージ コレクション ヒープに移動されないようにする内部ポインターです。 つまり、固定ポインターの値は、共通言語ランタイムによって変更されることはありません。 これは、マネージド クラスのアドレスをアンマネージド関数に渡すときに、アンマネージド関数呼び出しの解決時にアドレスが予想外に変更されないようにする場合に必要です。 構文 [cli::]pin_ptr<cv_qualifiertype>var = &initializer; パラメーター cv_qu
HTTPガイドHTTP の概要HTTP の進化典型的な HTTP セッションHTTP メッセージメディア種別一般的な種別HTTP の圧縮HTTP キャッシュHTTP 認証HTTP Cookie の使用HTTP のリダイレクト条件付きリクエストRange requestsクライアントヒント圧縮辞書転送 Experimental ネットワークエラーログ記録 Experimental コンテンツネゴシエーション既定の Accept 値UA 文字列によるブラウザーの判定HTTP/1.x のコネクション管理プロトコルのアップグレードの仕組みプロキシーサーバーとトンネリングプロキシー自動構成ファイル (PAC)HTTP セキュリティHTTP Observatory実践的なセキュリティ実装ガイド権限ポリシー Experimental Cross-Origin Resource Policy (CORP)
Rust のモジュールシステムは私の知る中でもトップクラスによくできた仕組みだと思います。特にリファクタリングによってモジュールを再構成するときのやりやすさは他の言語では経験できないものです。例えばそれなりの規模の Python プロジェクトを回帰バグを導入せずにモジュール構造のリファクタリングするのは不可能に近いですが、 Rust ではそのような不安を覚えたためしがありません。 Rust のモジュールシステムがどういうものかは、 The book にも書かれていますし、すでに大量のガイドが書かれていると思います。しかし、どのように使うべきかについては意外なほど情報が少なく感じます。 ベストプラクティスというのもおこがましいですが、数年使ってきて Rust のモジュールシステムを使う上でスムーズに感じる方法をまとめておきたいと思います。 Rust のモジュールシステム 本稿の主題はモジュー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く