マイクロソフト、Excel関数ベースのローコード言語「Power Fx」をオープンソースで公開。さまざまなソフトウェアでの採用が可能に
マイクロソフト、Excel関数ベースのローコード言語「Power Fx」をオープンソースで公開。さまざまなソフトウェアでの採用が可能に Power Fxはマイクロソフトにとって初めてのローコード開発向けのプログラミング言語です。 Power AppsやPower Automate、Power BI、Power Virtual Agentsなどから構成される同社のローコード／ノーコード開発ツール製品群「Power Platform」のロジックの記述に用いられるプログラミング言語として、今年の3月に発表されました。 Introducing Microsoft Power Fx, a single computer language for logic customization across the #PowerPlatform. Learn how you’ll be able to go
リリースするたびに「影響範囲の考慮漏れ」によるトラブルを起こす。こういう症状は、既存のソフトウェアシステムに追加開発を繰り返す組織によく見られるのではないかと感じます。コードやシステムの変更が影響を及ぼす箇所を見逃してしまい、未修正な箇所が残されたまま本番リリースされたために発生するトラブルです。 このようなトラブルが頻発すれば、関係者らは不満を感じます。エンジニアたちの能力に不信感を抱くかもしれません。 しかし、不満の矛先をエンジニアに向けたところで問題が解決することはありません。そもそも原因を見誤っているからです。根本的な原因は、もっと奥深くにあります。 影響範囲の考慮漏れの多発は、ソフトウェアシステムが大きな問題を抱えていることを知らせるサインです。このサインを見逃して表面的な対策ばかりを続けていると、症状が良くなるどころか、かえって悪化し続けることになるでしょう。 問題/原因の3層
この本で、著者のRobert Martinも、次のように述べています。 この10年間の間に この業界では多くのことがありました。1997年当時、テスト駆動開発などという言葉は誰も聞いたことがありませんでした。ほとんどの人にとって、単体テストというのは動作をひとたび『確認』したら捨ててしまうものでした。苦労してクラス メソッドを書き上げ、それらをテストするためのその場しのぎのコードをでっちあげていたのです。 『Effective Java』で有名なJoshua Blochは、この本の中のインタビューで、次のような会話を行っています。 「デバッグの話をしましょう。あなたが追いかけた最悪のバグはどのようなものでしたか」 それに対して、Joshua Blochは、 「最初に勤めた会社で私が開発したソフトウェアですね。ソフトウェアのデバッグに1週間半費やしました」 という話をしています。 1週間半費
筆者撮影、2019春先日、他社からのオファーを断った。非常にエキサイティングな海外の会社（勤務地も海外）だったのだけれども、その決断に際して3週間くらいうじうじと迷っていた。 この記事は、入社エントリでも退社エントリでも年収エントリでもない。少し変わった選択をした26歳のソフトウェアエンジニアが、会社をどう選んでいくのかに関して自分なりに整理した。ついでに、まだあまり情報がないTRI-ADという会社についても少し触れる。 20代でキャリアに関して悩むことは多い。大学院か就職か、どの国・地域でどんな人々と働きたいのか、そもそも何がしたいのか。そんななかで、なぜトヨタを選択したのか、会社の選択とリスクってなんなのか、TRI-ADや自動運転が抱える挑戦はなんなのか、という順に話を構成する。キャリアについて悩む人や、TRI-ADに興味がある人の何かの助けになると嬉しく思う。 注意会社の見解ではない
スタートアップでソフトウェアエンジニアとして10年たって大事にしていることリスト - tomoima525's blog
今から10年前の2014年4月に、いわゆるIT系大企業のDBエンジニアを辞めてメルカリでソフトウェアエンジニアとして働き始め、そこから紆余曲折を経て10年たった。 当時の予定通り、まだ現役でコードを書いている。海外に拠点は移り、色んな国の人たちと仕事をするようになり、役割もテックリード、マネジャー、CTOと変わってきた。ソフトウェア開発について考え方もさまざまな変遷を経ているが、少しずつ培ってきた、大事にしていることをあげてみる。 ソフトウェア/アーキテクチャ/コード ソフトウェアは他者の価値(i.e. 課題を解決する/コストをカットする)を生み出してなんぼ。コードが綺麗でも売上は立たない。 アーキテクチャやプログラミング言語のトレンドは変化する。追いかけるよりも、その時々のチームやプロダクトに合った設計やプログラムを選択する。 遊び心は大事。チームやプロダクトにそれほど合ってなくても新し
ソフトウェアテストの学び方に関して書籍やウェブサイト、そしてそこから伸びる某かについて自分なりにまとめ直してみるかーと。思いました。これを全部読めとかではなくて、まぁ自分が今まで読んできて役に立ったものリストくらいの感じです。 また、このリストの解説をスクフェス新潟でプレゼンしたいと思い公募に出しました。リンク先でLikeしてもらえるとプレゼンできる確率が上がるのでよければぜひ押していってください。 ソフトウェアテストで参考にしている67のモノ #scrumniigata https://confengine.com/conferences/scrum-fest-niigata-2022/proposal/16369/67 まずは、リストを。後半に各カテゴリの所感とかを。 発端は先日、Twitterでリプライをいただいて、7年近く前に「テストエンジニアの品格」という煽ったプレゼンをしていた
XLsoft エクセルソフト : activePDF 無料 PDF 作成/変換ソフトウェア PrimoPDF 4.1 日本語版 - ホーム
DX を推進する次世代ソフトウェア PDFTron Web、モバイル、デスクトップ、サーバー等のあらゆるフレームワークやアプリケーションに、正確な PDF の表示、アノテーション、編集、作成機能を提供します。サード パーティのサーバーへの依存を心配することなく、独自のインフラストラクチャに展開することで、ドキュメントとデータのライフサイクルを完全に管理できます。 PDFTron は、高性能ドキュメント処理技術の主要なグローバル プロバイダーです。市場をリードする PDFTron の SDK は、次世代のソフトウェア アプリケーションを強化します。 詳細はこちらから
Web翻訳の結果をオープンソースソフトウェア(OSS)の翻訳に突っ込んではいけませんという話 - いくやの斬鉄日記
オープンソースからハイスクールフリート、The Beatlesまで何でもありの自称エンターテインメント日記。 最近TransifexとかLaunchpad (のRosetta)とかPootleなどなどを採用し、オープンソースソフトウェア(OSS/FLOSS)の翻訳がWebでできるようになっています。 同時にWebの翻訳サービスも多数存在し、どんどん精度が上がってきています。 ではWeb翻訳の結果をOSS翻訳に突っ込めばいいのではないかというと、それは違います。Web翻訳にも当然利用規約があり、そのようなことは禁止されてることが多いです。世の中すべてのサービスのライセンスを確認するのは不可能ですが、概ねその傾向にあるのは事実でしょう。具体的にはExcite翻訳の利用規約だと第6条で明記されています。 OSSの翻訳にするということは、そのOSSのライセンスに従うということで、それは > 私的利
※この記事はWeb 2.0：次世代ソフトウェアのデザインパターンとビジネスモデル（前編）の続きです。 3. データは次世代の「インテル・インサイド」 重要なインターネットアプリケーションには必ず、それを支える専門のデータベースがある。Googleのウェブクロール、Yahoo!のディレクトリ（とウェブクロール）、Amazonの製品データベース、eBayの製品／出品者データベース、MapQuestの地図データベース、Napsterの分散型楽曲データベースなどだ。昨年、Hal Varianは個人的な会話の中で、「SQLこそ、次のHTMLだ」と語った。データベース管理は、Web 2.0企業のコアコンピタンス（中核能力）でもある。このため、これらのアプリケーションは単にソフトウェアではなく、「 インフォウェア（infoware）」と呼ばれることもある。 この事実は、ある重要な問いを投げかける。それは
1年半のソフトウェアエンジニア長期インターンで出会ったオススメ本をたくさん紹介します - Qiita
イントロ ABEJAアドベントカレンダーの4日目に一昨日飛び込みました、長期インターン生の佐藤(Twitter: @TodayInsane)です。 去年は機械学習を通して、TWICEというK-POPグループへの愛を語りました。 ABEJAには昨年4月、「本当に何も出来ないけど、休学してプログラミングとかエンジニアの経験を積みたいんです」という何とも不安な主張をするぼくを受け入れていただきました。 この1年半のエンジニア / リサーチ両インターンの過程で出会った良い本をどしどし紹介します。 ちなみにインターン開始時は プログラミング、Pythonだけならちょびっと書けます！(ABCのB問題とか機械学習ライブラリの写経) HTMLってどんな風になってるんですか？(？) サーバ...？？リクエスト...？？ JavaScript、名前は聞いたことあります 英語の論文しんどい、2時間ぐらいかけてI
本ブログ「Lean Baseball」開設10周年企画*1かつ, ちょっとした近況報告となります. お世話になっている皆様へ(TL;DR) 東京（の西側*2）で家を買いました, 引っ越しました. この決断とオチ, 未来に至るまで, 自分のキャリアとアウトプット, そしてこのブログは不可欠でした. 現職から前職以前の同僚（元同僚）, アウトプットや色んなことを応援してくださった皆様そして何よりも家族と友人に心から感謝御礼申し上げます🏚 お祝いはこちらからお待ちしています. 44歳独身ソフトウェアエンジニア、家を買う。 作業環境（まだ作ってる最中） こちらが購入したお家...で最初に作った作業環境です💻*3 （人生の一般的なアレとして）「家を買う（家の主となる）」事は一つの大切なライフステージのイベントなので, お世話になっている皆様へ(TL;DR) 44歳独身ソフトウェアエンジニア、家を
がくり（ソフトウェア関連垢） on Twitter: "昔、Googleのテスト自動化マネージャみたいな人が、日本に招待されて講演後、 日本人「コスパ悪いのをどう解決してますか？」 Google「解決していないです」 日本人「え！？」 Google「？」 日本人「コスパ・・・」 Goo… https://t.co/mWGWIQ7H9p"
昔、Googleのテスト自動化マネージャみたいな人が、日本に招待されて講演後、 日本人「コスパ悪いのをどう解決してますか？」 Google「解決していないです」 日本人「え！？」 Google「？」 日本人「コスパ・・・」 Goo… https://t.co/mWGWIQ7H9p
သည်စိတ်လှုပ်ရှားစရာများနှင့်စိတ်လှုပ်ရှားမှုနှင့်ပြည့်နှက်နေသောမတူနိုင်သည့်အတွေ့အကြုံများကိုပေးသည်။ bigwin66 ရွေးချယ်ရန်လောင်းကစားရုံဂိမ်းအမျိုးမျိုးနှင့်အတူကစားသမားများသည်လောင်းကစားခြင်းလောကတွင်သူတို့ကိုယ်သူတို့နှစ်မြှုပ်ခြင်း, သင်ဟာရာသီအလိုက်လောင်းကစားသူလား, မင်းရဲ့ကံစမ်းတာကိုကြိုးစားကြည့်ဖို့ရှာနေတာလား မှာလူတိုင်းအတွက်တစ်ခုခုရှိတယ်။ Dargon88 လောင်းကစားရုံသည်အဆင့်မြင့်နည်းပညာနှင့်အသုံးပြုရလွယ်ကူ
6月12日に日本経済新聞に掲載された記事「コナミを去るクリエーターたち 王国の遠心力」に、信じられないことが書かれているとネット上で話題になっています。元コナミの小島秀夫さんが立ち上げたコジマプロダクションが、コナミの取締役人事本部長である東尾公彦さんが理事長を務める「関東ITソフトウェア健康保険組合（ITS）」に申請書の受理を断られたというのです。そんなことがあり得るのか、コジマプロダクションと関東ITSに話を聞きました。 関東ITソフトウェア健康保険組合公式サイト 日本経済新聞「コナミを去るクリエーターたち 王国の遠心力」 申請書の受理を断られるということ 今回の件で先に注目しておくべき点として、コジマプロダクションがITSに「加入を断られた」ではなく、「申請書の受理さえも断られた」と日経が記載していることがあります。ITSは通常の全国健康保険協会（協会けんぽ）に比べ保険料が安かったり
尾藤正人です ラボブログではウノウのエンジニアで1日1人1エントリ(早く書くのはあり)で書いてます。おかげさまでウノウも順調にエンジニアの数が増えて、僕の順番に回ってくるのが少しずつ遅くなってきました。でもまだまだウノウではエンジニアを大募集中です!!我こそはと思う方はぜひご連絡ください。 前回のベンチャー流サーバ構築のススメ(ネットワーク編)ではネットワーク周りについて書きました。前回のエントリで言ったように、今回はソフトウェア周りのことについて書きたいと思います。 ソフトウェア周りで重要なのは、同じ構成にする、これにつきます。web サーバにだけ apache をインストールしたりとか、DB サーバにだけ MySQL をインストールしたりだとかいうことはしません。全てのサーバに同じパッケージ、同じプログラムをインストールします。それによる管理コストの軽減ははかりしれないものがあります。
■ [Security] Webとセキュリティとソフトウェア工学 超久しぶりに、かつ真面目な内容で更新です。 徳丸浩さんのTwitterでの 何度でも言うが、自力でトラブルシューティングできない人や組織は、自前でWordPres立ててはいけない / “一般ブロガーがAmazon Web Service(AWS)で独自ドメインのWordpressサイトを10分で作る方法…” に対して、 山田さんの（恐らく）達観したコメント「こうやってセキュリティが素人プログラマーや、見習いプログラマーを殺すんだろうなぁ。想像していたとはいえ、現実になってくると絶望しかない。」 を、 奥くんのコメント経由で見たわけです。 正直なところ、徳丸さんの元のコメントには100％同意で、山田さんもわかった上での達観なんだと思うのです（少なくとも「批判」ではないと思う）が、 ソフトウェア科学→セキュリティ→ソフトウェア工
2021.02.02 一般社団法人コンピュータソフトウェア協会(CSAJ) 一般社団法人コンピュータソフトウェア協会（略称「CSAJ」、東京都港区赤坂）は、各種メディアで報道されている、クラウドサービス「GitHub」について、正しい理解と対応に向けた文書を発表いたしました。 はじめに 各種報道のとおり、ソフトウェアのソースコードをホスティングするクラウドサービス「GitHub」において、大手金融機関の業務システムのソースコードの一部が公開されていた事象が発生しました。クラウドサービスにおいては、情報の公開範囲などの設定の誤りが、セキュリティインシデントにつながることがあり、利用においては十分な配慮が必要です。その上で、クラウドは危険であるので使わせないという判断にならないよう、GitHubをはじめ、外部のクラウドサービス利用の萎縮につながらないよう、各社の節度ある情報セキュリティ設計を要
600ページ以上あり結構長いので方針としては第１部だけは一通り読んでみて、その先は各章結論から読んでいき、気になった部分だけ遡って拾い読みしていく戦略でいく方が良さそう。
「設計書」というのは、作るものの構造を抽象的に表現したものと言うことができます。 ただ、ソフトウェアの抽象化の仕組みはプログラミングコード自体に備わっているので、ソフトウェア生成可能な抽象的表現というのはコード表現ができるはずですね。コードで表現しておくと、整合性のチェックとかも行いやすいです。 でも、コードではない「詳細設計書」というものが一部業界には必要とされているので、その「詳細設計書」というのは実際はなんなのか考えてみます。 ※ 最初はタイトルは「設計書」としてましたが、話を限定するため「詳細設計書」に変更しました。 追記：納品物に関する記述を追加しました。 表現を変えたコーディング ソフトウェア生成可能な抽象的表現というのはコード表現ができるわけですが、文字で表記する必要もなく、ダイアグラムで表現することもできますね。 代表的なのがER図やクラス図で、これは文字表現との相互変換が
仙石浩明の日記 「ソフトウェア開発」は「モノ作り」ではない
いつのころからか、 ソフトウェア開発がモノ作りに喩えられるようになった。 典型的なのは、製造業(例えば自動車製造)と IT 業界とを比較して、 前者が高度にシステム化されているのに対し、 後者がまるで家内制手工業のようだ、という批判である。 日経ビジネス online の記事に次のようなくだりがあった: 「というより、何といいますか、経営トップからすると、 ITはとにかく非常識な世界だ、としか思えないのではないかなあ。 例えば大きなシステム開発プロジェクトに取り組むと、 すぐ100億円を投資する、という話になってしまう。 100億円の経常利益を出そうと思ったら本当に大変。 ところが、100億円を投じたのに、期限までに完成しない、 出来上がってきたものが当初計画と違う、 直そうとするとさらに金がかかる。 こんなことが起きるわけですから、『一体なぜなんだ』と経営トップは思うわけです」 IT業界
「Xanadu(ザナドゥ)」は1960年に開発がスタートしたシステムで、2014年4月後半にこれまで54年間のプロジェクトの成果物としてひっそりと「OpenXanadu」というソフトウェアをリリースしました。Xanaduは、現在インターネット上で使われているハイパーテキストシステムであるWorld Wide Web(ウェブ)のポジションに就いて、現在のインターネットを構成する基本システムになっていたかもしれないものなのですが、開発が遅すぎてもはやそれも夢物語状態です。しかし、Xanaduの産みの親であるテッド・ネルソン氏にはまだ大きな野望があるようです。 World's most delayed software released after 54 years of development | Technology | theguardian.com http://www.theguard
© NISHI, Yasuharu 同値分割ってなんだろう？ 九州ソフトウェアテスト勉強会（仮） Vol.7 2014/5/28（水） 電気通信大学 大学院情報理工学研究科 総合情報学専攻 経営情報学コース 西 康晴（Yasuharu.Nishi@uec.ac.jp, http://qualab.jp/） © NISHI, Yasuharu 2 Profile Assistant professor: the University of Electro-Communications, Japan (also providing consultancy service to industry on testing and TQM) President: Association of Software Test Engineering, Japan (ASTER) President: Jap
先日、某VC投資先の方々に対して、「ソフトウェアエンジニアの採用時にコーディングテストをやりたいがどうしたら良いか？」ということについて語ってきたので、こちらにもエッセンスをまとめたいと思います。 コーディングテストの目的 なぜ我々はコーディングテストをやるのでしょうか？ もちろん、第一目的はソフトウェアエンジニアの採用候補者のスキルを見極めるためです。 過去に、経歴も良さそう、技術的な議論もスムーズにできる、なのにコードが書けない候補者に、私は何度か出会っています。「コードが書けない」のレベルは、（ある程度易しい）論理をプログラムに翻訳できず、まともな if 文が書けないというレベルを言っています。熟練者でもド・モルガンの法則をうっかり間違えるぐらいはあると思いますが、そういう話ではありません。コードが書けない候補者は、そもそも条件が書き下せません。このような候補者を雇ってはいけません。
Gmail の TIPS，裏技，アクセスキー，活用方法，ソフトウェア等を URI 参照系でなるべく多くあげていってください。回答の重複 OK ですが，なるべく多くが原則でお願いしま..-人力検索はてな
Gmail の TIPS，裏技，アクセスキー，活用方法，ソフトウェア等を URI 参照系でなるべく多くあげていってください。回答の重複 OK ですが，なるべく多くが原則でお願いします。 FireFox の Gmail スキン配布サイト，アカウント招待サイト，Gmail Drive (だっけ？) は別に紹介してもいいですが単独回答はやめてください。なるべく多くが原則。ポイント配分もその原則と内容の善し悪しに従います。 はてなの所持ポイント少なめなので，のっかりはてながあれば出来る限り質問を延長し得ます。
manabusakai さんの下記の記事を読んだ感想。 blog.manabusakai.com Twitterにも書いたけど僕は信頼されるエンジニアをずっと目指してきたし、そのために僕に必要なことがここには詰まっていた。 ほんとみんなに読んでほしい。 このエントリーの中の信頼を得ているエンジニアの姿を引用する。 有言実行である 仕事の納期をきっちり守る どんな仕事でもムラがない 困ったときに快く相談に乗ってくれる 皆がやりたがらないタスクを拾ってくれる チームの雰囲気を良い方向に導いてくれる etc... まさに。 ではソフトウェアエンジニアとしてこの他に当たり前にやるべき事って何があるだろう？ ソフトウェアエンジニアとしてやるべき事 僕らは技術で問題を解決することで価値を高めたり、対価を頂いている。 例えば使っているOSSにバグがあったらどうだろう？ これは自戒をかなり含むが不満をSN
OKIは、LINE Pay株式会社（代表取締役社長：前田 貴司、本社：東京都品川区、以下LINE Pay社）が提供する送金サービス「LINE Pay かんたん送金サービス」と連携できるソフトウェア開発キット（以下「LINE Pay送金SDK」）を金融機関向けに販売します。本商品は、同サービスとの連携に必要なプログラムをパッケージ化したもので、「LINE Pay かんたん送金サービス」の通信方式や暗号方式などを意識することなくアプリケーション開発を行うことが可能です。また、従来ゼロから開発しなければならなかった通信や暗号などのプログラム開発および単体試験を削減し、開発を簡略化することができます。金融機関は、運営している公式スマートフォンアプリからLINE Payに直接送金ができる「LINE Pay 残高送金機能」を容易に実現できます。 キャッシュレス決済の利用は近年広く浸透してきており、今後
ソフトウェア開発委託基本契約書の不備により、未払い200万円の被害を受ける - Moonmile Solutions Blog
フリーで作業をしたり小さな会社で請け負い作業をするときには「ソフトウェア開発委託基本契約書」を結ぶことになると思うのだが、これを結んでしまった後、トラブルが発生したときに「請負側」が被害を蒙っている、という現状です。 本日、弁護士に相談したところ「ソフトウェア開発～」の条項から、「違約金などは取れない」旨の通知を受けたのですが、かなり納得がいかないので、ここにフリーランスという立場の防御のために事案を晒しておきます。 # 上の図は「給与」って書いてあるけど、実際は報酬/委託金です。 今回のソフトウェア開発は、発注元Lから元請けGに製品開発を依頼しています。この中で株式会社Eの仲介があって個人事業主のM（＝私）にところに話が来ている状態です。それぞれの契約は、 発注元Lと元請けGの間の契約 元請けLと株式会社Eの間の契約 株式会社Eと個人事業主Mとの契約 に分かれます。どれも請負契約で、最終
「HRTの原則」という言葉をご存知だろうか。 これは書籍 Team Geek ―Googleのギークたちはいかにしてチームを作るのか で紹介されている言葉であり、本書ではほぼ一冊すべてをかけてこのHRTの原則とその実践方法とを様々な角度から紹介している。 1. 謙虚(Humility) 2. 尊敬(Respect) 3. 信頼(Trust) の3つの価値が大切にされており、エンジニアとしてもチームや組織、顧客との対話においてこれらの価値を重んじていくことが成功につながる、というものである。 あらゆる人間関係の衝突は、謙虚・尊敬・信頼の欠如によるものだ Team Geek p.15 プログラマとして成功するには、最新の言語を覚えたり高速なコードを書いたりするだけではいけない。プログラマは常にチームで仕事をする。君が思っている以上に、チームは個人の生産性や幸福に直接影響するのである。 Team
Forkwell Library #14 2023.1.25 のスライドです。 https://forkwell.connpass.com/event/271212/
ソフトウェア開発者に必要な考え方 / Necessary mindset for software developers
「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」の輪読会のススメ - そーだいなる輪読会キックオフ / soudai-kickoff
Linearは、Asana以上の機能とJira以上の使いやすさとレスポンスの良さを実現する、タスク管理ソフトウェアを開発している。現在はクローズドベータテストを行っており、2021年に正式版のリリースを目指す。今回はCo-founderのTuomas Artman氏に話を聞いた。 ウィークリーユーザー2000人、参加企業700社のクローズドベータ運用中 ――まずはLinearについて教えてもらえますか。 Linearは、AsanaやTrelloなどの、タスクをチームメンバーに割り当て、その進捗状況を管理するためのツールと、Jiraのような、ソフトウェア開発プロジェクトの中期計画、追跡、管理を実行できる多機能ツールの中間的な存在となることを目指しています。 小規模なエンジニアチームをターゲットに開発を始め、現在はクローズドベータテストを行っています。ベータテストには、約700社が参加しており
特に学術的にソフトウェア工学に触れたことはないのですが、むしろそうではなく現場にいる身としては、ソフトウェア工学は失敗しているように見えます。 「成功していない」ように見えるのではなく「失敗している」ように見えるのです。 もちろん、いまソフトウェア開発で使う技法やツールなど、ソフトウェア工学の産物はたくさんあり、現在のソフトウェア開発がソフトウェア工学から生まれたもので支えられていることには間違いありません。 でも、そうやって築き上げてきたものが、1999年以降ガラガラと崩れて、そしてうまく再構築できていないように見えます。 1999年、なにがあったかというと、XPエクストリーム・プログラミング入門という本が発行されたのです。リンク先は2版ですが、日本語版でも初版は2000年12月になっています。 ここからソフトウェア工学がガラガラ崩れた気がしています。 では、ここまでソフトウェア工学がど
そろそろ大規模ソフトウェア開発に一言いっておくか。デイリービルドとリグレッションテスト 2010-03-12 - 未来のいつか/hyoshiokの日記
会社の勉強会で自分の今までの経験からテストについてお話をした。その資料を公開する。自分が関わった、Oracle8、DEC Rdb、日本語COBOL、そしてSamba3.0国際化プロジェクトでのテストやディリービルドなどについて紹介した。 テストファースト開発など、最近広く知られるようになってきたが、ディリービルドとリグレッションテストの実行という方法論は昔からソフトウェア製品開発の現場では行われていたベストプラクティスである。そのリズムとか雰囲気を伝えたかった。 テスト勉強会よしおか100311 1View more presentations from Hiro Yoshioka. テストがある開発現場ってのは、こんな感じなんだ〜という雰囲気が伝われば幸いだ。 アジャイル開発方法論としてXPの手法とかいろいろ知られているが、このディリービルドとリグレッションテストというプラクティスもその
【続】ソフトウェア設計についてtwada技術顧問と話してみた 〜 A Philosophy of Software Design をベースに 〜 - NTT Communications Engineers' Blog
はじめに 本記事は前回の記事である「ソフトウェア設計についてtwada技術顧問と話してみた 〜 A Philosophy of Software Design をベースに 〜 - NTT Communications Engineers' Blog」の続編です。 前回の記事の内容がベースとなっていますので、「APoSD って何だっけ？」という場合はぜひ前回の記事をご覧になってから、以下にお進みください。 ということで、後編の対話パートにさっそく入っていきましょう！ Pull Complexity Downwards iwashi: APoSD では、複雑性を下に追いやる(Pull Complexity Downwards)という話が出てきます。何らかの処理が複雑になる場合、それを隠蔽してインターフェースを極力シンプルに保つ、というのがAPoSDの主張です。 こちらに関しても、社内勉強会中で
ソフトウェアの技術革新って必要なのかな？
プログラマの間では昔から、この手法は処理が遅いだとか、無駄が多いだとか、再利用を心がけろだったりとか 様々なやり方で、ソフトウェアをチューンナップして処理速度を上げるためのやりとりが際限なく 繰り返されているけど、だいたいどれもハードウェアの技術革新によって記録は塗り替えられてないかな。 そりゃ、ミドルウェアレベルでは全てのパフォーマンスに影響してくるので、ちまちまとした 改良が加えられるべきなんだけど、ソフトウェアレベルではどうなの？ Ｉ／Ｏに引きずられるから、Ｉ／Ｏの処理は最低限に抑えるってのが昔から定説だけど それもSSDの登場で、かなり緩和された感があるし、結局プログラマの努力って ハードウェアの努力には追いつかないし、無駄なのではないかと思ってる。 １０年前を支えたプログラム技術で今も生きているものってある？ オブジェクト指向とかプログラムのわかりやすさを追求したものは別でね。速
読書をしていると、書籍に記された新たな知識や考え方を取り入れることが可能で、時には人生に影響を与えるほどの印象深い書籍と巡り会えることもあります。世界に無数に存在する書籍の中でも「ソフトウェアエンジニア人生を変えた5冊の書籍」をネオバンク「Nubank」のソフトウェアエンジニアであるジュリアーノ・リマ氏が紹介しています。 Five Books that Changed My Career as a Software Engineer https://julianogtz.github.io/my-personal-blog/posts/five-books-that-changed-my-career-as-a-software-engineer ◆1：情熱プログラマー ソフトウェア開発者の幸せな生き方 リマ氏は、人生を変えた書籍の1冊目として「情熱プログラマー ソフトウェア開発者の幸せな
ITmedia エンタープライズ：遅れた日本のソフトウェア開発 その原因はここにあり!?：作業環境を改善せよ さもなくば日本のエンジニアは壊滅する！ (
作業環境を改善せよ さもなくば日本のエンジニアは壊滅する！：遅れた日本のソフトウェア開発 その原因はここにあり!?（1/3 ページ） 米グーグルでは食事がタダに。米マイクロソフトではソフトドリンクが飲み放題。そのほか、米国のIT企業の多くでソフトウェア開発者は全員、個室を与えられている――こんなこと、日本の企業であるだろうか？ 驚愕!? 海外企業における個室の作業スペース 米国のみならず先進諸国においては、ソフトウェアエンジニアの労働環境は総じていい。世界一巨大なソフトウェア会社のマイクロソフト、欧州最大のソフト開発会社として有名なSAPで働いた経験から、そう感じる。どちらの会社も、さまざまな側面において一部から厳しく評されることもあるが、そんな評判とは裏腹に、エンジニアの労働環境は良かった。 ご存知かもしれないが、米マイクロソフト本社のオフィススペースは筆者が勤めていた当時、完全な個室型
こんにちは、みんなのウェディング 高井です。 みんなのウェディングやクックパッドといったインターネットサービス企業では、オープンソースソフトウェアは欠かすことのできない存在です。LinuxやMySQL、Ruby、Railsといった主要なものをはじめとして、テクノロジースタックのほとんどがオープンソースソフトウェアによって構成されいるといっても過言ではありません。 ですから、企業としてどのようにオープンソースソフトウェアに向きあうかということが、とても重要な問題になります。そして、そのための指針が、オープンソースソフトウェアポリシーです。 今回は、クックパッドがどのようにオープンソースソフトウェアポリシーをつくったか、その背景も含めてをご紹介いたします。 クックパッドとオープンソース 今でこそクックパッドは、多くのオープンソースソフトウェアを公開したり、その開発に貢献したりする会社となってい
(ゲームの話は一切知らん) いつのまにか「Webフロントエンドの動きが速い」とか誰も言わなくなってることにふと気付いた。なんというかソフトウェアをどう作るか、という問題にたいして大枠の部分では完全に固まってしまって、あとは個別の事情をどうやっていくかみたいな話しか残ってないように見える。 端的にいえば、宣言的UIとkubernetesは聖杯だったのではないかな。 k8sにかんしては「Cloud Runみたいのでいいじゃん」みたいな話はあると思うんだけど、Envoyほしいとかなってくると結局事実上k8s必須だし、今新しくアプリ作るときに宣言的UIじゃないフレームワーク使うこととかほぼ考えられんよな。で、こういう構成が定番ですね、みたいになってなんかもう数年は経つ気がする。結果として日本語でソフトウェア開発の話になるとチームビルディングがどうのみたいな話しかなくなってきていて、なんかつまんねー
chriskiehlのブログより。 考えを改めたもの 過去の自分なら言い争っていたであろうことが、今では信じられるようになったこと。 様々な経験レベルを持つ人がいるチームで仕事をする場合は、型付き言語の方が適している スタンドアップは、実際に新人を注目するのに役立つ スプリント・レトロスペクティブは、実際の軌道修正のためのものであって(「つまり、なんてこった、うまく行かなかった!」)、皆の時間を無駄にするようなアジャイル/スクラムマスター的なものでない限り、その場に相応しいものである ソフトウェア・アーキテクチャは、おそらく他の何よりも重要である。優れた抽象化のクソみたいな実装は、コードベースに正味の害を与えません。悪い抽象化や欠落したレイヤーは、すべてのものを腐らせる Javaはそれほどひどい言語ではない 巧みなコードは通常、良いコードではない。明瞭さは、他のすべての懸念事項に勝る どん
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「影響範囲の考慮漏れ」によるソフトウェアトラブルの多発はビジネス継続性に対する危険信号｜mtx2s
手動テストだけのソフトウェアは腐っていく: 柴田 芳樹 (Yoshiki Shibata)
ソフトウェアエンジニアとしてのトヨタという選択
ソフトウェアテストで参考にしている67のモノ 2021 #scrumniigata｜kyon_mm
Web 2.0：次世代ソフトウェアのデザインパターンとビジネスモデル（後編） - CNET Japan
44歳独身ソフトウェアエンジニア、家を買う。 - Lean Baseball
フリー（無料）CMS／オープンソースソフトウェアの比較・紹介ならCMSナビ
日経報道「関東ITソフトウェア健保」申請書受理拒否、コジマプロダクション否定せず 健保理事長はコナミ取締役
ウノウラボ Unoh Labs: ベンチャー流サーバ構築のススメ(ソフトウェア編)
Webとセキュリティとソフトウェア工学 - こめんと(2016-06-20)
GitHubに関する対応とお願い | CSAJ 一般社団法人コンピュータソフトウェア協会
Googleのソフトウェアエンジニアリング - 技術メモ
ソフトウェアの「詳細設計書」とはなんなのか - きしだのHatena
開発に54年間もかかったソフトウェア「Xanadu」がついにリリース、その秘めたる野望とは？
ソフトウェアテスト技術（実践編）
ソフトウェアエンジニア採用におけるコーディングテストのススメ - MAYAH
ソフトウェアエンジニアが当たり前にやるべき事 - そーだいなるらくがき帳
「LINE Pay かんたん送金サービス」と連携できるソフトウェア開発キットを金融機関向けに販売｜プレスリリース｜OKI
HRTの原則 〜ソフトウェア開発はバーでしっとり語り合うように 〜 : 小野和俊のブログ
ちょうぜつ改め21世紀ふつうのソフトウェア設計
エンジニアが作る、エンジニアが“使いたがる”タスク管理ソフトウェアLinear
ソフトウェア工学は失敗している - きしだのHatena
現役プログラマーが選ぶ「ソフトウェアエンジニア人生を変えた5冊の本」とは？
オープンソースソフトウェアポリシーをつくろう - クックパッド開発者ブログ
ソフトウェア開発の進歩完全に止まったような気がする
業界6年目で考えが変わったソフトウェア開発のトピック