タグ

ソフトウェアに関するasa_ca3のブックマーク (32)

  • 「Platform Engineeringへの招待」、開発者の生産性を高めるプラットフォームを作り、運営していくための考え方とは(前編)。Platform Engineering Meetup #1

    急速に注目を浴びつつある新しいムーブメント「Platform Engineering」についてのコミュニティイベント「Platform Engineering Meetup #1」が3月9日に都内でオンラインとオフラインのハイブリッドで開催されました。 Platform Engineeringとは、クラウドネイティブ時代においてソフトウェアエンジニアリング組織にセルフサービス機能を提供するためのツールチェーンやワークフローを設計し構築する技術分野とされています。 その最初のセッションとして行われた、イベントの主催者である草間一人氏の「Platform Engineeringへの招待 - Platform Engineeringって何? 何故今注目なの?」の内容を紹介しましょう。 記事は前編と後編に分かれています。いまお読みの記事は前編です。

    「Platform Engineeringへの招待」、開発者の生産性を高めるプラットフォームを作り、運営していくための考え方とは(前編)。Platform Engineering Meetup #1
  • クラウド関連ソフトウェアエンジニアの平均年収は18万2000ドル(約2370万円)、6割以上がフルリモートワーク。米国でオライリーが調査

    クラウド関連ソフトウェアエンジニアの平均年収は18万2000ドル(約2370万円)、6割以上がフルリモートワーク。米国でオライリーが調査 米国でクラウドを活用したソフトウェアデベロッパーやアプリケーション開発者、運用スタッフなど、同社が「クラウドプロフェッショナル」と呼ぶITエンジニアの平均年収を始めとした各種調査結果「2022 Cloud Salary Survey」を、米オライリーが発表しています。対象は米国在住の18歳以上で、回答数は1408、有効回答は940。 The O’Reilly 2022 Cloud Salary Survey -- Are you paid what you’re worth? 7% of the respondents earned over $300,000 per year. Get the answers to your salary questi

    クラウド関連ソフトウェアエンジニアの平均年収は18万2000ドル(約2370万円)、6割以上がフルリモートワーク。米国でオライリーが調査
  • ソフト開発での多重下請、公取委が取り締まり強化へ 「優越Gメン」が立ち入り調査

    公正取引委員会は6月29日、ソフトウェア関連企業の下請取引などに関する実態調査報告書を公開した。資金3億円以下のソフトウェア関連企業2万1000社を対象にアンケート調査などを行ったところ、違反行為が多重下請け構造によって連鎖していることを確認したという。そのため、多重下請構造の下で生じる問題への対応を強化する方針を示した。 下請代金を巡っては、エンドユーザーや上流発注者からの買いたたきや減額、支払遅延などの違反行為を確認。ソフト開発の取引では「使いやすい機能」などのオーダーが発注者ごとに異なり、当事者間の共通認識を形成しづらい。そのため不当な給付内容の変更、やり直しなどが起こっている。これらの行為が業界の多重下請構造によって、サプライチェーン上で連鎖していたと分かった。

    ソフト開発での多重下請、公取委が取り締まり強化へ 「優越Gメン」が立ち入り調査
    asa_ca3
    asa_ca3 2022/06/29
    発注する方もわかってるやってるからな
  • 及川卓也の『ソフトウェア・ファースト』というアンチパターン|ソフトウェア・ファースト制作委員会

    2019年10月10日に発売した、及川卓也の著書『ソフトウェア・ファースト あらゆるビジネスを一変させる最強戦略』。このnoteでは、出版の経緯や書籍づくりの裏話、発刊時に削った原稿の公開など、制作にまつわるさまざまな情報を発信していきます。 こんにちは、及川卓也のマネージャーの酒井と申します。今でこそ多くの方にご愛読いただいている『ソフトウェア・ファースト』ですが、制作中はプロダクト開発におけるアンチパターンをいろいろやってしまいました。この経験は、その後の私たちの仕事で「これ、進研ゼミでやったやつだ!」的な効力を発揮し、立ち止まって考える機会を与えてくれています。どれもあるあるで、皆さまのお仕事を振り返る際にもお役に立てるのではないかと思い、整理してみました。 ここからは、酒井真弓著『ルポ 日DX最前線』(集英社インターナショナル)を再構成してお届けます。 筆者(酒井)は独立を機に

    及川卓也の『ソフトウェア・ファースト』というアンチパターン|ソフトウェア・ファースト制作委員会
    asa_ca3
    asa_ca3 2022/02/12
    いい本だと思ったのにダメ出しなのかと思ったらいい話だった
  • 文化からツールまでを扱ったタイトルに違わぬ大著『Googleのソフトウェアエンジニアリング』を読んだ - こまぶろ

    昨年11月末に発売された『Googleのソフトウェアエンジニアリング』を読みました。 Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術文化、プロセス オライリージャパンAmazon 細かい内容についての感想はTwitterの方に放流しているので、ブログでは簡単に。 とりあえず一周した。17章以降は基「いやーGoogleさんすごいっす」という感じだったが、ところどころ役立つ話があったし、「エンジニアリングを発展させていった先の一つの形がこうなのか」という面白さは大きかった。逆に前半は実践的にかなり勉強になったのでちゃんと復習しよう…… #swebookjp— こま (@koma_koma_d) 2022年1月3日 全体の構成 書籍全体の構成は、以下のようになっています。 分量としては、「第4部 ツール」が最も大きな部分を占めています。 第2部から第4部に

    文化からツールまでを扱ったタイトルに違わぬ大著『Googleのソフトウェアエンジニアリング』を読んだ - こまぶろ
  • ジャストシステムが一太郎負けて最近低迷してるかと思いきや株価も上がって給与も最高水準だった

    一太郎がWordに負け低迷してると思ってたジャストシステムのこの数年右肩上がりでしかも給与が最強クラスで不死鳥のごとく復活してた。 それにしても、みんなジャストシステム好きだなw

    ジャストシステムが一太郎負けて最近低迷してるかと思いきや株価も上がって給与も最高水準だった
    asa_ca3
    asa_ca3 2021/07/14
    時代の流れにもどんどん乗ってるし未来見えてるやつでもいるんじゃないかと思う
  • コードが読めるソフトウェア開発者 - As a Futurist...

    僕はコードを読むのは得意な方だけど、それが過ぎてコードを書かなくてもシニアソフトウェア開発者になってしまった。実はコードをちゃんと読めるソフトウェア開発者って希少価値が高いのではないか、と思ったので自分がどんな感じでシニアになったのかをまとめてみた。似た様な人の参考になれば幸いだ。 同意。僕は未だ書く方はほとんど機会なく成果もないけど、コードを読み尽くして、負荷試験や番で挙動を把握し続け、メトリクスでとことん確かめていった結果、Sr. Engineer になれた。 https://t.co/KXtMdEaRr8 — Ryosuke Iwanaga (@riywo) April 16, 2021 コードを書かなくてもシニアソフトウェア開発者になれた 僕は今 Amazon の Sr. Systems Development Engineer という職種で働いている。いわゆるソフトウェア開発職

    コードが読めるソフトウェア開発者 - As a Futurist...
  • クリーンアーキテクチャ完全に理解した

    clean_architecture.md 2020/5/31追記: 自分用のメモに書いていたつもりだったのですが、たくさんのスターを頂けてとても嬉しいです。 と同時に、書きかけで中途半端な状態のドキュメントをご覧いただくことになっており、大変心苦しく思っています。 このドキュメントを完成させるために、今後以下のような更新を予定しています。 TODO部分を埋める 書籍を基にした理論・原則パートと、実装例パートを分割 現在は4層のレイヤそれぞれごとに原則の確認→実装時の課題リスト→実装例という構成ですが、同じリポジトリへの言及箇所がバラバラになってしまう問題がありました。更新後は、実装時の課題リストを全て洗い出した後にまとめて実装を確認する構成とする予定です。 2021/1/22追記: パートの分割と、クリーンアーキテクチャという概念の定義について追記を行いました。大部分の実装例パートを中心

    クリーンアーキテクチャ完全に理解した
  • 「ITの開発現場によくいるやっかいな人」の対処法をタイプごとに解説したサイトが登場

    ソフトウェアの開発プロジェクトにはさまざまな経歴や役職を持つ人が関与するので、我が強い人や性格に難がある人が問題になることもしばしば発生します。ソフトウェア業界のよもやま話を語るブロガーのニール・グリーン氏が、ソフトウェア開発プロジェクトの中で問題になりがちな人をタイプごとにまとめつつ、それぞれのタイプの特徴と管理職向けの解決策を解説しました。 How to Deal with Difficult People on Software Projects https://www.howtodeal.dev/ 上記のサイトにアクセスしたのが以下。上から「プロダクトマネージャー」「デザイナー」「プロジェクトマネージャー」「開発マネージャー」「開発者」「品質保証(QA)」の6カテゴリに分かれていて、それぞれの役職の中によくいる「問題のある人」のタイプが動物のアイコンで示されています。例えば、「プロ

    「ITの開発現場によくいるやっかいな人」の対処法をタイプごとに解説したサイトが登場
    asa_ca3
    asa_ca3 2021/03/19
    自分が当てはまるやつがあるんじゃないかと思って見てしまう小心者
  • 成長の早いジュニア・ソフトウェアエンジニアの特徴 - junebox

    こちらが伝えた内容から不要なことを邪推しないというか、文字通りに「真っ直ぐ」である人は、望ましい行動に最短経路で向かっていくので効率的な行動を選択していくな、と感じます。「なにかわからないことがあったら、すぐに質問してくださいね」と言われたときに、実際にすぐに質問できる人はどんどん前に進んでいきます。余計なことを考えない分、リソース効率がよいのでしょう。 ぼく個人は、人間はもともと素直な生き物なんじゃないかと思っています。それが、イヤな体験を重ねるたびに少しずつ防衛的になって、だんだんと素直さに蓋をしてしまうケースがあるイメージです。「それくらい自分で調べろ、いちいち質問するな」と怒鳴られるようなことがあったら「すぐに質問してね」と言われてもなかなか実行に移せなくなりそうですよね。そういう人は「自分は、そういう状況である」というのを自覚することから始めるとよいでしょう。「質問してよかった」

    成長の早いジュニア・ソフトウェアエンジニアの特徴 - junebox
    asa_ca3
    asa_ca3 2020/12/06
    ただの教えてちゃんではない。どうやって考えるか知っている人はエンジニアでなくてもうまく仕事していける。
  • テスト、正常系から書くか異常系から書くか - hitode909の日記

    今週は同僚と毎日長時間ペアプロしていた。 おもしろかったのが、同僚のテストの書き進め方で、一番複雑な正常系のテストをちゃんと書いてから、その複雑なテストをもとに、いろんな条件を削っていって異常系のテストを作っていく、というところ。 僕は逆で、入力が空なら何も起きない、とか、一番簡単な異常系のテストを書いて、そこだけ通るのを確認して、よしよし、と進めていって、メソッド来の動きは最後に確認して終わる。 変な進め方だな〜(主観)と思って眺めていたけど、たしかに正常系のテストが通っていれば、あとはバリデーションまわりのチェックとか、例外となる場合のチェックをすれば終わりで、異常系のテストがすごい速さで書かれていておもしろかった。 …という話をしたら、チームメンバーたちは正常系のテストから書きはじめるという人が多くて、正しくことを確認してから、1個ずつ前提となる条件を外してみて試す、と聞いて、同値

    テスト、正常系から書くか異常系から書くか - hitode909の日記
  • Programming Quotes

    There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies. — C.A.R. Hoare, The 1980 ACM Turing Award Lecture The computing scientist’s main challenge is not to get confused by the complexities of his own making. — E. W. Dijkstra The cheapest, fa

  • CTOの大切な役割の一つ|Matsumoto Yuki

    久々に記事を書いてみました。スタートアップの経営者やCTOというポジションを今担っている人、これから目指す人向けに私見をまとめた乱文です。直近はCTOというよりも、もはやポジション名もわからないなにかになってしまい、人事や総務、マーケティング、各事業の経営管理など職責を広げすぎてしまいましたが、今回は自分にとってのCTOの職責として重要なものとは何かを考えてみました。 要点事業をスケールさせるためには、まず組織とプロダクトの設計が相互に影響し合うことを理解する。その上で事業構造の理解から、より素早く改善すべきレバレッジが効くポイントを見出し、その改善が最も素早く進む組織とプロダクトのアーキテクチャを同時に設計する。こうしたプロダクトと人、事業の3つを理解しながらアーキテクチャ設計することがCTOとして重要な職務の一つだと考えています。 事業とCTO先日、スタートアップ界隈を見ていて下記のも

    CTOの大切な役割の一つ|Matsumoto Yuki
  • 個人的なアプリケーション設計のバイブル3選 - Runner in the High

    自分が格的に設計を意識するようになったのは、2015年の夏に現職であるFringe81株式会社で開催されていたサマーインターンに参加してからだ。 インターンではDDDとクリーン・アーキテクチャ*1を一から勉強してAPIサーバーに実装する、というカリキュラムであったが、いま思うと2週間という比較的長いインターンで僕が学べたことと言えば当に微々たるものだった。つまるところ、それくらいには設計というものは奥が深い。常になんらか特定のデザイン・パターンなりアーキテクチャ・パターンを適用することでアプリケーション開発がうまくいくということはなく、それらの様々な知識から少しづつ応用されたものが最終的なアプリケーションの設計に対して真の洞察を与えてくれるものというのが、僕自身のいまの認識である。 設計はまさに Connecting the dots そのものだ。多くを知れば知るほど、アプリケーション

    個人的なアプリケーション設計のバイブル3選 - Runner in the High
  • メテオフォール型開発 - 実践ゲーム製作メモ帳2

    今日は、日の代表的なソフトウェア開発手法について紹介しよう。 その名も、メテオフォール型開発である*1。 第一節 通常のウォーターフォール型開発におけるプロジェクトはこのような形を取るが、 メテオフォール型開発ではこのような形が取られる。 そしてこうなる。 これはアジャイル型開発手法におけるサイクルであるが、 神の前では無力である。 神の一声は全てを崩壊させ、 民は一生懸命これを再建す。 これが、メテオフォール型開発*2である。 第二節 全てのスケジュールは天界の都合によって決まる。これを黙示録と呼ぶ。 ソフトウェア開発においてフィードバックは重要なファクターだが、 神にフィードバックは届かない。 ただし、祈りを捧げることはできる。この祈りはごくまれに届く。 神は様々な姿を取る。 外から現れることもあれば、 内に棲んでいることもある。 あるいは、まだ会っていない or 会うことすらできな

    メテオフォール型開発 - 実践ゲーム製作メモ帳2
    asa_ca3
    asa_ca3 2018/05/31
    畳み掛けてきて良い
  • 情報セキュリティ管理基準 (平成28年改正版)

    - 0 - 情報セキュリティ管理基準 (平成28年改正版) - 1 - Ⅰ.主旨 (1) 情報セキュリティ管理基準の策定 インターネットをはじめとする情報技術IT)が組織体の活動や社会生活に深く浸透することに伴い、 情報セキュリティの確保は、組織体が有効かつ効率的に事業活動を遂行するための必要な条件、安全・ 安心な社会生活を支えるための基盤要件となっている。一般に組織体に求められる情報セキュリティ対 策は、組織、人、運用、技術、法令など多様な観点からみた具体的な対策が要求されており、ITが浸透 した企業においては、これらに加えて内部統制(法令順守、情報管理等)の仕組みを情報セキュリティ の観点から構築・運用する体制の確立も強く望まれている。 このような状況を踏まえ、経済産業省では、平成15年に、組織体が効果的な情報セキュリティマネジ メント体制を構築し、適切なコントロール(管理策)を整備

  • 【2016年版】Androidのおすすめrootアプリ32選

    2016年もあけましておめでとうございます。皆さん働いてますか?ハマコー(@hamako9999)です。 2014年から書いているこのAndroidのrootアプリまとめ記事ですが、新アプリの追加、古いアプリの削除でリライトをかけて2016年版作成しました。今後共、よろしくお願い致します。 rootedアプリの動作検証端末は、Nexus5。OSバージョン6.0で、カスタムROMのカタクリズムを導入しています。 更新履歴 2014/07/25 ファイル復元アプリ「DiskDigger」を追加 2014/07/25 バッテリー管理アプリ「BetterBatteryStats」を追加 2014/07/25 LogCatのビューアアプリ「CatLog」を追加 2014/08/19 ファイラーを「ESファイルエクスプローラ」から「SolidExplorer」に変更 2014/10/06 アプリ権限管

    【2016年版】Androidのおすすめrootアプリ32選
  • iceiv+putty

    2023/12/19 版 putty-gdi-20231219.zip 2023/08/29 版 putty-gdi-20230829.zip 2022/11/04 版 putty-gdi-20221104.zip 2023/12/19 修正内容 0.80 の公開に追随。 2023/08/29 修正内容 0.79 の公開に追随。 プライベートキー定義で Enter BackSpace などのモディファイアキー無しに何らかの割り当てを設定している場合、login 時の user や password の入力に支障が出る可能性があります。 2022/11/04 修正内容 とりあえず 0.78 の公開に追随。 2022/05/30 修正内容 0.77 の公開に追随。とりあえず build は通しましたが、一部の機能は正常に機能していないかもしれません。そろそろ抜的にどうにかしないと無理そう。

  • [Think IT] 第1回:そもそも言語仕様って何だ? (1/3)

    【新・言語進化論】プロの言語仕様の読み方 第1回:そもそも言語仕様って何だ? 著者:シンクイット編集部 公開日:2007/11/6(火) 膨大なドキュメント「言語仕様」とは この世には、プログラミング言語の極意が記されているドキュメントが存在する。入門書の元でありながらも書かれることが少なく、プログラミング言語の根幹ともいえるもの、それが「言語仕様」である。 言語仕様というのは、簡単にいえば、そのプログラミング言語の文法・記号などの意味を厳密に規定したドキュメントのことである。Javaにしろ何にしろ、プログラミング言語には必ずといっていいほど言語仕様が存在している。厳密な規定とは「誰が読んだとしても、同じ意味としてとらえることが可能である」という意味だ。 読者の皆さんも、業務で利用する言語仕様については一度は読んだことがあるのではないだろうか。しかし、その膨大なドキュメント量に圧倒され、読

  • ソフトとかハードとか関係ございません

    Developers Summit 2015(デブサミ2015) 佐藤由紀 発表資料。 ******************************************************************************************* 2015年注目のワードと言われている「データレイク」。 「ビッグデータ」よりも想像力を掻き立てる良いワードだなぁと個人的に感じています。 100億件/日ものデータを毎日新たに蓄積し、そのデータを広告配信ロボットに活かし続けているマイクロアド。 これまでマイクロアドがどのようにデータを活用して広告配信を展開してきたか、そして、これから目指す世界のために構築を進めているマイクロアドなりの「データレイク」とはどのようなものか、ゆかりのある琵琶湖のことを織り交ぜつつお話いたします。

    ソフトとかハードとか関係ございません