「『自由ソフトウェア』の開発にDiscordを使わないで」という主張
オープンソースソフトウェアの開発プロジェクトで連絡用プラットフォームとしてDiscordを用いる例が多くあります。しかし、自由ソフトウェア(FOSS)の推進者であるドリュー・デヴォールト氏は「『自由ソフトウェア』の開発プロジェクトにDiscordを使うべきではない」と警鐘を鳴らしています。 Please don't use Discord for FOSS projects https://drewdevault.com/2021/12/28/Dont-use-Discord-for-FOSS.html Discordはユーザーが「○○というゲームについて話し合うサーバー」「○○愛好会のボイスチャット用サーバー」「GIGAZINEの公式サーバー」といったように自由にサーバーを作ることができるコミュニケーションアプリで、各サーバーではテキストや音声で会話できるほか、ファイルをアップロードした
「アジャイルサムライ」の著者が語る、技術志向の企業が世界をどう見ているのか？ そしてソフトウェアテスト自動化を進化させる方法について（前編）。JaSST'22 Tokyo基調講演
「アジャイルサムライ」の著者が語る、技術志向の企業が世界をどう見ているのか？ そしてソフトウェアテスト自動化を進化させる方法について（前編）。JaSST'22 Tokyo基調講演 Jonathan Rasmusson（ジョナサン・ラスムッソン）氏はアジャイル開発における著名人の一人であり、さまざまな先進的ソフトウェア企業において開発やテストに携わってきました。 日本ではアジャイル開発の入門書として話題となった書籍「アジャイルサムライ」（オーム社,2011）や「初めての自動テスト」（オライリー,2021）、「ユニコーン企業のひみつ」（オライリー,2017）の著者としても有名です。 そのラスムッソン氏が2022年3月10日と11日の2日間、ソフトウェアのテストに関わる国内最大のイベント「ソフトウェアテストシンポジウム 2022 東京」（JaSST'22 Tokyo）の基調講演に登壇しました。
Jonathan Rasmusson さんインタビュー ( 前編 ) | オブジェクトの広場
永和システムマネジメントさんのご厚意により、去る 3 月に Agile Japan 2012 での基調講演を提供するために来日された Jonathan Rasmusson さんに対するインタビューを実施させて頂きました。 Jonathan さんは、「アジャイルサムライ」というアジャイル開発の入門書の著者です。 「アジャイルサムライ」は日本で空前のブームを巻き起こしており、現在日本の各地で勉強会（道場）が開催されています。 インタビューでは、以下の 4 つの分野に渡り、Jonathan さんに質問をしました。 1. Jonathanさんのこれまでの経歴 2. アジャイル開発一般 3. アジャイルサムライ 4. プライベートな生活 今月と来月の 2 回に渡り、Jonathan さんへの突撃インタビューの結果をお届けします。 1. Jonathanさんのこれまでの経歴について -- 今日は、イン
伸ばすのが難しい能力: 柴田 芳樹 (Yoshiki Shibata)
2018年6月1日に株式会社メルペイに入社して、4年が過ぎました。入社当時は、定年が60歳と聞いていたので、1年半の勤務だと思っていましたが、実際の定年は65歳であり定年まであと2年半です。 ソフトウェアエンジニアにとって重要な能力と（私は考えるが）、身に付けるのが難しいのが現実だと、この4年間で再認識したのは次の三つです。 開発の最初にAPI仕様をきちんと書けるソフトウェアエンジニアは少ない テストファースト開発を行っているソフトウェアエンジニアは少ないか、いない Tech Blogなどの執筆で、読み手を意識して、分かりやすい文章を書く、ソフトウェアエンジニアは少ない API仕様については、このブログでも何度か書いています（「API仕様を書く」）。テストファースト開発についても、「テストファースト開発」を書いています。分かりやすい文章については何も書いていないですが、「伝わる技術文書の書
電子手帳とKubernetes | IIJ Engineers Blog
社会人生活の半分をフリーランス、半分をIIJで過ごすエンジニア。元々はアプリケーション屋だったはずが、クラウドと出会ったばかりに半身をインフラ屋に売り渡す羽目に。現在はコンテナ技術に傾倒中だが語りだすと長いので割愛。タグをつけるならコンテナ、クラウド、ロードバイク、うどん。 デジタルデバイス黎明期のソフトウェア事情 今を遡ること30年ほど前、筆者はとある組み込みシステムの開発に携わっていたことがありました。そのシステムは電子手帳と呼ばれたスマートフォンのご先祖様のような製品だったのですが（無線、有線問わず通信機能はありませんけど）、これが今考えるとなかなかしびれる環境で、 OSは存在しないスタンドアロンシステム CPUは聞いたことがない、もしかしたらメーカーオリジナルのもの もちろん開発言語など存在しない。アセンブラすら存在しない シリーズ製品だったがソフトウェアの資産継承は存在しない。モ
形式手法はなぜ流行っていないのか - Qiita
はじめに みなさん形式手法をご存知でしょうか？ 名前くらいは聞いたことあるけどいまいち何かわからないという方が多いのではないでしょうか。 その通りです。形式手法はアカデミアではそれなりに研究されているものの、 一般の（特にWeb系）ソフトウェア開発者が携わることはなかなかないのではないかと思います。 この記事ではソフトウェア開発に形式手法が導入されないのはなぜなのかを考察します。 この記事ではアジャイルソフトウェア開発において形式手法を導入する際のハードルについて考察します。 追記 本記事について、「形式手法は流行っていない」というのは正確ではないのではないかという指摘をいただきました。組み込み系や社会インフラ系等バグを絶対に出せないシステム開発では形式手法がよく使われているそうです。 ちょっと古いデータですが活用事例です。 誤解を招く紹介となっていたことをお詫びします。 さらに追記 ku
オープンソースがわからない
OSS活動をしているエンジニアが採用で有利だったり、なんかエライとかカッコイイみたいな空気がある。 オープンソースを主軸にしている会社で働きはじめてから、人が何を前提として、何を指して「オープンソース」と言っているのか、どんどんわからなくなってきた。いったいなぜOSS活動が良いとされるのか。 可能性1 ▸ ソースがオープンである これは自明に思えるかもしれないが、本当にそうだろうか。ソースがオープンなのは良いことだという価値観は、そんなに広く受け入れられているだろうか。 たとえばうちの会社は「ソースはできる限りオープンであるべき」という信念を掲げているし、私にとってもそれは魅力的なポイントのひとつだった。さらには「すべてのソースはオープンであるべきで、オープンじゃないソフトウェアは使わない」という過激派も世の中には存在するが、いずれにしろこのようなオープンソース主義者が多数派であるとは思え
スマホアプリと米国輸出規制に関するメモ : DSAS開発者の部屋
記事の概要 スマートフォンの普及に伴いそれをターゲットとするソフトウェアベンダや開発者が増えています。スマートフォン向けのアプリケーションを公開する際には通常 Google Play や App Store 等のアプリケーションストアを使用しますが、これらのストアの拠点は米国にあるためそこでアプリを配布することは米国からの輸出に該当し 同国の輸出法の適用対象となることに注意が必要です。 米国の輸出規制の内容は EAR (Export Administration Regulations 輸出管理規則) に定められており、規制に該当するか否かは「何」を「どこへ」輸出しそれを「誰」が「何のため」に使用するかによって決まります。規制対象にあたる輸出を行う際には米国商務省へ申請を行い有効期限を伴う 輸出許可（Export License）を得なければならないケースもありますが、EAR にはある品目
アメリカの大学で受けたソフトウェア工学の授業が実践的ですごかった話 - stefafafan の fa は3つです
私はアメリカの大学で「インタラクティブメディアとゲーム開発」を専攻しましたが、その時受けたSoftware Engineeringという授業が色んな意味で素晴らしかったのでその授業がどう素晴らしかったのかを紹介していきます。 リアリティーがすごい まずこの授業、生徒数が80人ほどいます。ここから教授がみんなを約15人ずつの5つの会社に分けていきます。そうです、我々生徒は実は会社員なのです。 そして初日に出された課題は「自分たちの会社のミッションステートメントを考えてくること」です。 それだけでなく、プロジェクトマネージャー・プロセスエンジニア・リリースエンジニア・ドキュメンテーションマネージャー・クオリティーマネージャーの役割を会社のどの社員が取るのかを決めてこないといけないというのです。私たちは言われるがままにミッションステートメントを用意し、次の授業に備えました。 プロセスがすごい S
恐怖の JVM 大量メモリ消費！メモリリークの謎を追え！！ - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、ミドルウェア開発チームの青木(@a_o_k_i_n_g)です。将来の夢は川口浩探検隊に入ることです。 先日、弊社のアプリケーションサーバーで大量にメモリを消費するという現象に遭遇しました。アクセス頻度の低いサーバーがメモリを大量消費するという謎深いものでした。 発生当初の状況はこんな感じです。 アプリケーションサーバーでは Jetty が稼働 現象が発生した JVM は 5GB 程度のメモリを消費しており、明らかに通常ではない量のメモリを消費している 複数台のサーバーで発生していたが、全てで発生したわけではない。 また、発生したサーバーはいずれもアクセス頻度が少ないサーバーだった。 ヒープ、パーマネント、スタック ひとまず、JVM でトラブルが発生した時は何はともあれヒープダンプとスレッドダンプを見るに限ります。各種情報の取得をインフラ部隊へ依頼し、得られたヒープを解析すると、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
不確実性の時代に、アジャイル開発で向き合っていこう - ZDNET Japan
C++でできる！OS自作入門