タグ

関連タグで絞り込む (138)

タグの絞り込みを解除

softwareに関するvanbraamのブックマーク (434)

  • 世界規模でWindowsデバイスが次々とブルースクリーン（BSoD）に！ 大規模障害発生中【17:10追記】／「CrowdStrike Falcon Sensor」に含まれるドライバーが原因か

    世界規模でWindowsデバイスが次々とブルースクリーン（BSoD）に！ 大規模障害発生中【17:10追記】／「CrowdStrike Falcon Sensor」に含まれるドライバーが原因か
    vanbraam
    vanbraam 2024/07/20
    この規模の障害でも(ソフトウェアだと)免責なのかな. 賠償責任負わせたらたぶんCrowdStrike社余裕で吹っ飛ぶくらいの金額になると思うんだけど
    リンク

  • Javaで書いた4行のコード、依存関係をたどると51万行に――超複雑化するソフトウェア構成、SBOMで探るには

    ＠IT編集部は2022年8月22日、デジタルイベント「＠IT ソフトウェア品質向上セミナー」を開催した。基調講演では、「SBOMによるサプライチェーン攻撃対策～自社ソフトウェアのリスク、把握していますか？～」と題して、JFrog Japanの横田紋奈氏（デベロッパーアドボケイト兼Java女子部・JJUG運営）が、企業におけるオープンソースソフトウェア（OSS）の使用に潜むリスクにはどのようなものがあり、それにどう対処していけばよいかについて解説した。 ソフトウェアのセキュリティで注目されるソフトウェアサプライチェーン攻撃 SBOMとソフトウェアサプライチェーンの話題の前に、横田氏はDevSecOpsとは何かから話を始めた。DevOpsは、開発者と運用者が協力してサービスを改善していくもの。ユーザーからのフィードバックなどを受けて取り組みを繰り返し、改善を継続する。そのための考え方であり、組

    Javaで書いた4行のコード、依存関係をたどると51万行に――超複雑化するソフトウェア構成、SBOMで探るには

  • DDD is dead. God is in Twitter #scrumsapporo


    Scrum Fest Sapporo 2021でプレゼンしました。 私達の愛したDDDを取り戻すための苦悩と挑戦について紹介します。本作品はマリリン・マンソン Rock is dead オマージュ作品となっております。 DDDはその構造上、デザイン思考やリーンスタートアップやディスカバリーといったものを考慮しておらず、デリバリーフェーズを意識した手法になっているのですけど、これはチーム開発のボトルネックを生み出す原因になりがちではないでしょうか？ デリバリーにおいてはドメインを語れる人がいく人かおり、それをベースにそこそこの規模のシステム設計やアプリケーション設計をしていく。その過程でDDDを実践したという経験がつくわけですが、その人に対して、新規事業であったり、若々しい状態の事業のサポートをお願いすると、劣化したDDDのような設計をベースに進めつつ、現場のプログラマーを説得する行為に走る
    DDD is dead. God is in Twitter #scrumsapporo
    vanbraam
    vanbraam 2021/11/08
    "Scrumの主戦場"が"シリーズA前"以降という辺りで???となった.この人のスクラムの定義は自分とは違うらしい.スライド#17がこの発表の独自性の肝なのだろうが(それ以外は引用多数),ここがオレオレ解釈過ぎて納得感薄い
    リンク

  • 銀行の基幹系システムはなぜ古臭いのか？｜つっちーさん

    タイトル詐欺である。今回も反省せずに続きといきたい。 前回も示したが、ざっくりとした銀行の基幹系システムは「勘定系」「情報系」「チャネル系」の三つの構成になっているという図が上である。ざっくりとしたものなので、実際にはもっと複雑(特にメガバンクでは)だし、これがあるのにアレがない、とかいったものはある。細かいところを気にしすぎると禿げるぞ。 今回は、銀行の基幹系がなぜ古臭いのかという話をしたい。古臭いと言ってもいろいろあって、特にエンジニア界隈からは「メインフレームを使ってる」とか「COBOLみたいなカビの生えた古代言語を使ってる」とか、とにかくイケてないシステムの代表例のように言われることが多い。対して、預金者の側からはネットとの親和性だとかサービス面の不満からくるイケてないという話が多いと思うのだが、これはどちらかというとシステムの話ではなくて、サービス設計とかその背景になるビジネスモ

    銀行の基幹系システムはなぜ古臭いのか？｜つっちーさん

  • 「共同創業者（エンジニア）を探している」という相談に対しての僕の回答｜suthio

    「共同創業者になってくれるエンジニアを探している」と起業家（準備中含）から相談されてだいたい同じことを回答してる気がするので僕の考えを書きます。 想定読者・起業を考えていて自分自身はエンジニアではない ・試したい仮説はあって、検証するためにはプロダクトを開発する必要がある ・現在、コミットしてもらえるエンジニアもいない ・どういうエンジニアを探せばいいかわからない 結論 結論から書きます。 検証するためのプロダクトをあなた自身で書いていきましょう。 創業者が優秀なエンジニアになれという話ではなくて、 一人目のエンジニアを採用するためには自分自身でプロダクトを作るのが一番の近道という話です。 ソフトウェア開発について一定の理解を得ることができる ソフトウェアの開発を行う時にどういうことを考えて、結果どういうものを作っていくかのフローを一度経験しておくことにより、 エンジニアを採用した後に自分

    「共同創業者（エンジニア）を探している」という相談に対しての僕の回答｜suthio
    vanbraam
    vanbraam 2021/03/02
    口だけの人間は信用されないってだけでは; これが例えばゲームなら,壮大なアイディアだけ披露して,共同創業者(エンジニア)に"作って"とだけ言うのがどんな人間かだいたい想像できるのでは?
    リンク

  • Clubhouse リアルタイム配信の仕組みについて (解説編)

    Cloubhouse はすでに OSS である Janus Gateway に切り替えており Agora は使用していないようです ライセンス Creative Commons — 表示 - 非営利 - 改変禁止 4.0 国際 — CC BY-NC-ND 4.0 前提 ざっくりと雑に解説。 どんな技術を使っていてこんな感じだろうという妄想は以下をどうぞ。 Clubhouse リアルタイム配信の仕組みについて (妄想編) 著者 商用 WebRTC SFU 開発者 WebRTC プロトコルスタック実装者 End to End Encryption プロトコルスタック実装者 Clubhouse の仕組みはとてもシンプルで配信者が N 人で、それを数千人が聞くという co-streaming と呼ばれる仕組みの一つ。この方式は今までは主に映像ありでパネルディスカッション的な使い方が主だっだ。それを

    Clubhouse リアルタイム配信の仕組みについて (解説編)

  • 最近見かける新しいライセンスについて - Kengo's blog

    Elastic社のブログをきっかけに、最近見かける新しいライセンスについて個人的に調べてみた。私は専門家ではないので要注意。公開情報も隅々まで追えているわけではないし。 なお一部ライセンスはOpen Source Initiative (OSI)による承認を受けていないので、ここではオープンソースライセンスではなく単に「ライセンス」と書くことにする。 新しいライセンスが誕生している背景 従来のオープンソースライセンスが再頒布以外の利用をあまり想定していなかった。 Open-core modelないし完全オープンソース戦略を採る企業が自衛策を必要とした。 既存のライセンスが難解なため、理解しやすいライセンスが求められた。 OSS活動を収入に繋げるためのモデルが試行錯誤されている。 新しいライセンスを導入しているプロジェクト（一例） プロジェクト ライセンス Elastic SSPLと独自ライ

    最近見かける新しいライセンスについて - Kengo's blog

  • 面接における「Linuxできますか？」の意味 - orangeitems’s diary


    ﹁Linuxできますか？﹂ ﹁Linuxできますか？﹂という言葉はIT業界であれば面接でよく問われる質問だと思います。私も過去問われたことがありますが、この、できますか？、って言う質問はかなりあいまいな問い方だと思います。何ができればできるなんでしょう。勝手な判断でできると答えていいものかどうか。 現場経験を重ねて来た立場から、この﹁できますか﹂が示す内容を説明してみたいと思います。 期待していること コマンドでファイルの操作ができること Linuxには一応グラフィカルインターフェースも付属していますが、かなりの操作をSSHプロトコル経由でコマンドプロンプトにて行うことが多いです。WindowsだとリモートデスクトップでGUIが標準なので、ここは大きく違うところです。 さて、コマンドで何をするかと言うと、9割がファイル操作だと思います。テキストエディタでファイルを修正する。ファイルのコピー
    面接における「Linuxできますか？」の意味 - orangeitems’s diary
    vanbraam
    vanbraam 2020/12/04
    個人的にはこんな技術的に曖昧な質問を面接でされたらこっちから断る. 技術において曖昧であることの危険性を全く理解していないと思う
    リンク

  • 仕事を丸投げしてしまうことに関して - karaage. [からあげ]


    仕事の丸投げ 以前ツイートして結構反応のあったものです。 別のグループの人から、ソフト開発がうまくいかないのでアドバイス欲しいと相談うけたので、とりあえずコード見たいなと言ったら、全て外注に丸投げでコード一行も見たことないと言われた。 そういうとこだぞ— からあげ (@karaage0703) November 4, 2020 こう書いたものの、同時に丸投げする人だけ責めても仕方がないところはあるとも思っています。特にソフトが弱い製造業の大きな会社だと、ソフト開発を製造・作業と捉えているので基本的に﹁社員はコード書くな﹂というカルチャーだったりすると風の噂に聞きました︵少し柔らかい表現を心がけています︶。 丸投げ体質というのは、何もソフトウェアに限ったことではないです。私の最初のキャリアはハード屋だったのですが、回路設計を外に丸投げで、回路の読めないハード屋がたくさんいるという、まことしや
    仕事を丸投げしてしまうことに関して - karaage. [からあげ]
    vanbraam
    vanbraam 2020/11/20
    "コード一行も見たことない"って検収どうしてたんだろう? 納品物の品質は「バグ収束曲線」なんかではわからないぞ; 他ブコメのAppleの例,真偽は別として,納品物の中身を理解しようとするか否かが重要だと思う
    リンク

  • 『要はアジャイルは行き当たりばったりってことですか？』へのコメント

    どちらにしても会計法と予算制度の想定からは外れているので、アジャイル開発よりも前に調達制度を見直さないことには聳え立つ糞を建立し続けることになりますぞ、と

    『要はアジャイルは行き当たりばったりってことですか？』へのコメント
    vanbraam
    vanbraam 2020/09/20
    なぜ調達制度が関係するのだろう? もしかして外注前提?; あと会計法はともかく,予算制度の想定って金科玉条のように遵守が必要なものなのだろうか?; 百字では不明点が多すぎるので,より詳しい説明を期待
    リンク

  • プライベートメソッドのテストは書かないもの？ - t-wadaのブログ

    この文章の背景 この文章はプライベートメソッドのテストを書くべきか否かに関する knsmr さんのご質問に対して 2013/03/13 に QA＠IT で回答したものです。残念ながらQA＠IT のサービス終了（2020/02/28）と共にアクセスできなくなってしまったため、運営を行っていたアイティメディア株式会社様、開発を行っていた永和システムマネジメント様、そして質問をされた knsmr さんに許可とご協力をいただき、当時の回答をサルベージしてブログに転載する運びとなりました。 プライベートメソッドのテストはよく議論になるテーマですので、当時の回答を再編集し、knsmr さんのご質問も含め、ご利用いただきやすいライセンス CC BY（クリエイティブ・コモンズ — 表示 4.0 国際 — CC BY 4.0） で公開いたします。 目次 この文章の背景 目次 knsmr さんのご質問 私の回

    プライベートメソッドのテストは書かないもの？ - t-wadaのブログ
    vanbraam
    vanbraam 2020/04/10
    だいたい納得; 結局テストは契約の一種. 請負契約なら,アウトプットだけが問題で,それをどうやって成し遂げるかは契約の対象外. そこを縛りたくなるのは権限の委譲 or 責務の分解のどちらかが不十分
    リンク

  • ソフトウェアのもっとも重要な品質は発展性 - ソフトウェア設計を考える

    ソフトウェアでもっとも重視すべき品質は「発展性」なんだと思う。 機能要求や非機能要求は、時間とともに変化する。その要求の変化に対応してソフトウェアを発展させていける能力、つまり発展性こそがソフトウェアの価値を大きく左右する。 発展性に問題があり変化ができないソフトウェアと、発展性に優れ変化と成長を続けやすいソフトウェアの価値の差ということだ。 発展性の価値 顧客のニーズは変化する。また、市場の競合関係も変化する。そういう事業環境の変化にあわせて、ソフトウェアにも変化を続ける能力が求められている。 また、顧客のニーズや市場環境の変化がゆるやかだとしても、事業活動をすれば組織は経験を通じて学び成長していく。開発チームに限っても、ソフトウェア開発運用の経験を積むことで、開発の考え方とやり方にさまざまな学びと成長がある。そうやって学んだ知識を適切にかつ迅速にソフトウェアに反映できるほど、事業により

    ソフトウェアのもっとも重要な品質は発展性 - ソフトウェア設計を考える
    vanbraam
    vanbraam 2020/04/06
    一方でソフトウェアの世界にはYAGNIという言葉もある.バランスが大事
    リンク

  • 『日本のITの未来を担うSES、あるいはプロダクトオーナーの重責について - GoTheDistance』へのコメント

    スクラムの教科書的にはPOは顧客じゃないほうがいいって話じゃなかったっけ。/ https://www.ryuzee.com/contents/blog/7143　で書かれてるような印象がある。/ ソース https://scruminc.jp/training/owner/ POは顧客でない想定に読める。 <blockquote class="hatena-bookmark-comment"><a class="comment-info" href="https://b.hatena.ne.jp/entry/4683781687071625954/comment/tpircs" data-user-id="tpircs" data-entry-url="https://b.hatena.ne.jp/entry/s/gothedistance.hatenadiary.jp/entry/202

    『日本のITの未来を担うSES、あるいはプロダクトオーナーの重責について - GoTheDistance』へのコメント
    vanbraam
    vanbraam 2020/04/05
    ryuzee氏の記事の上3つは内製想定,最後のだけ外注想定だと思うので,そりゃ上3つより"辛さが満載"になるのは仕方ないのでは
    リンク

  • 日本のITの未来を担うSES、あるいはプロダクトオーナーの重責について - GoTheDistance


    先日、アジャイル開発を推進するために大変有意義な資料が公開されています。ESMの木下さんといえば、アジャイル開発の現場にずっと携わってきた著名な方です。 note.com でも、令和2年にこちらの記事が何百もはてブされるのも、おいおいマジかよって思う所がありまして。今までどうやってたのだろうか...。準委任(時間単位のチャージ)以外の選択肢がないやり方だと思っていたので。請負でアジャイルを取りに入れるわけないですよね。一般的なSIerさんでは、どういう理解をされて、どう取り組んで来たのだろう。 アジャイルと受託開発の相性は最悪では ムービング・ターゲットを請負で追いかける自傷行為を誰がやるんだって話と、要件固めて下請けに出せないから誰もやりたがらないよねという話を書き散らしています。10年前に書いた記事の内容がまだ通用してしまうのも、自分でも少し寂しい気持ちがあります。 gothedis
    日本のITの未来を担うSES、あるいはプロダクトオーナーの重責について - GoTheDistance
    vanbraam
    vanbraam 2020/04/05
    そもそも日本のITの未来をSESが担っちゃダメでしょ. 本来的には内製が最適解なのに,記事内に全く"内製"の文字はなし; POが重要なのは同意するが,そこに正当な評価と権限を与えられない企業はagilityを諦めればいいだけでは
    リンク

  • 海外のOSS なWebRTC SFU 開発者たちがコミュニティに絶望してる話


    WebRTC コミュニティの問題これ以外にも webrtc-discuss や react-native-webrtc などのコミュニティでもドキュメントを読めば分かる質問、回答を書いても反応がない、助けて！とだけ書かれた投稿などがとても多いです。 この理由は OSS よくあるといえばそれまでなんですが、それ以外にも問題があると思っています。 WebRTC って音声や映像をリアルタイムに送受信する技術なわけですが、誰が見てもわかるんです。音が来ないもすぐわかるし、映像が遅延してる、表示されないもすぐわかってしまうんです。 つまり技術者じゃなくても問題が起きていることに気づけてしまうんです。 で﹁なんか音声が流れてこない！このソフトウェアは問題だ！﹂となってしまうわけです。 これに対応する場合、作者たちは﹁WebRTC という技術の難しさをよくわかっていない人たち﹂へ無料のサポートを提供しな
    vanbraam
    vanbraam 2020/04/03
    多少の差はあるだろうが,WebRTC固有の問題でもない気が; 教えて君を"コミュニティ"のメンバーにカウントするのも違和感ある. 真面目な人ほど疲弊するので,機械的に切り捨てないと重要な問題まで見落としてしまいそう
    リンク

  • 『Tetsu Kinomura on Twitter: "しつこいですが、これはほんっっとに質の高いロードマップだから知って欲しい。 せっかく和訳したのにあんまり反響なくて悲しいです笑 #プログラミング #ロードマップ https://t.co/VCJvLG5lp3"』へのコメント

    テクノロジー Tetsu Kinomura on Twitter: "しつこいですが、これはほんっっとに質の高いロードマップだから知って欲しい。 せっかく和訳したのにあんまり反響なくて悲しいです笑 #プログラミング #ロードマップ https://t.co/VCJvLG5lp3"

    『Tetsu Kinomura on Twitter: "しつこいですが、これはほんっっとに質の高いロードマップだから知って欲しい。 せっかく和訳したのにあんまり反響なくて悲しいです笑 #プログラミング #ロードマップ https://t.co/VCJvLG5lp3"』へのコメント
    vanbraam
    vanbraam 2020/03/30
    これを"質が高い"とか"良い"と評価する人は本当に中を読んだのかな?と思う. "Learn about APIs"-"Caching"-"Web Security Knowledge"を繋ぐ線に,どういう意味があるというのだろうか?
    リンク

  • ジョエル・テスト


    こんにちは。 タオソフトウエアの杉山です。 今回は炊飯について取り上げます！ 電気からガスへ 慣れると戻れない できるだけ大きな家電を買わずにすますため、 島へ移住の話︻家電品 – 使わなくなった電子レンジ– ︼ で触れた通り、もともと電子レンジで炊飯していました。これが水や米が変わっても使えそうな炊飯釜などを調べている中で、炊飯にガスを使うようになりました。 子どもの頃の実家のご飯も電気釜で、人生のほとんどは電気で炊飯されたご飯を食べてきました。ガスで炊飯するのは小学生の授業での経験ぐらいしかなかったですが、普段の生活で電気からガスへ変えてみたら意外と早く時間短縮になるので驚いています。 ガス代は少し上がりますが急上昇するようなことは無く、電気代が下がったので安上がりになりました。大島はプロパンガスのため、都市ガスだともっと安くなるかなと感じています。 昔のガス釜の炊飯器は壊れず美味しい

  • 開発と理想主義 vs 現実主義 - Qiita

  • 開発と理想主義 vs 現実主義 - Qiita


    TL;DR Qiitaで現実主義的な立場の方が書いた﹁現実は甘くねえんだよ！﹂な記事がランクイン その記事の筆者とコメントでやり取りをしていた方が理想主義的立場で記事を書き、これまたランクイン 実際はどちらも大事だよ、という話をしたかった はじめに 開発者の格差を書いたある記事がQiitaでランクインしました。 現在その記事は何らかの理由でコミュニティガイドライン違反として非公開となってしまっております。 個人的に記事内容には同意できましたし、開発にも有用なものだったので、理由は定かではないのですが…… 確実に言えることは、その方はいわゆる﹁現実主義的な﹂立場から記事を書いていました。 そしてその記事のコメントでやり取りをしていた方が新たに記事を書き、そちらもQiitaでランクインしました。 エンジニア業界を少し外から眺めて こちらはまだ公開されております。 その方は、実際に記事を読んで頂
    開発と理想主義 vs 現実主義 - Qiita
    vanbraam
    vanbraam 2020/03/29
    b:id:entry:4682612114689585634 => b:id:entry:4682776584115551394 => b:id:entry:4683275200061999618 => これ, と全部議論のポイントが前の記事とズレてる気がする. 技術の採用とチーム・マネジメントの話は本来別では?(技術教育を介して関係するが)
    リンク

  • エンジニア業界を少し外から眺めて - Qiita

  • 1 2 3 4 5 6 7 8 9 10 次のページ

お知らせ

もっと読む

公式Twitter

  • @HatenaBookmark

    リリース、障害情報などのサービスのお知らせ

  • @hatebu

    最新の人気エントリーの配信

はてなブックマーク

公式Twitter

はてなのサービス

  • App Storeからダウンロード
  • Google Playで手に入れよう
Copyright © 2005-2024 Hatena. All Rights Reserved.