タグ

論と*資料と運用に関するch1248のブックマーク (33)

  • 誰も教えてくれないSIの本質、SIerの世界観

    記事について 国内の IT 業界について、ネット上では「SIer」VS「Web系」の構図がしばしば見られる。記事は前者、SIer の世界観をひとりの当事者として雑多にまとめたものである。記事としては読み物、特にポエムの類。 対象読者 以下を想定する。 ITエンジニアまたはその卵で、 SIerを知らないWeb系の人 SIerに入社した新人や中途入職者 SIerにてSEまたはマネージャーして働いている者 SIerにてSEではないが裏方で働いている者(開発、研究、調査、教育、管理など) 学習や就労の初歩として参考にしてもいいし、議論やキャリアのダシに使っても良いだろう。 筆者について 吉良野すた: https://stakiran.github.io/stakiran/ 国内の大手 SIer に勤めるサラリーマン。現場には出ておらず、裏方で支えてメシをべている。SI にも IT にもさほど

    誰も教えてくれないSIの本質、SIerの世界観
    ch1248
    ch1248 2024/08/12
    大変良かった。「OIerが出てくるかも」はなるほどとなったし、顧客側が変わらざるを得ない状況にならないとSIer側も変わらないだろうね。
  • コードを書き始める前からテストをずっと考える ─ 継続的テストモデルとシフトレフトなテスト活動をアジャイルにどう取り入れるか - Agile Journey

    読者の皆さんは、テストについてどのようなイメージをお持ちでしょうか。「開発の後に行う確認作業」といったイメージを持たれている方もいるかと思います。 しかし、開発しようとしているソフトウェアに不具合の混入を防ぐには、もっと早い段階でテストについて考えることが必要です。こういったテスト活動は、プログラムを1文字も書いていないときから始めることができるのです。 記事では、2016年に提唱された継続的テストモデルを紹介しつつ、アジャイルとも親和性のあるシフトレフトなテスト活動について解説していきます。 DevOpsにおけるテストの考え方 DevOpsのループ図とは何か? 継続的テストモデルとは何か 継続的テストモデルにおいてテストは「活動」である シフトレフトなテスト活動とシフトライトなテスト活動 シフトレフトなテスト活動としてのテスト駆動開発 コード実装を始める前から行うテスト活動 シフトレフ

    コードを書き始める前からテストをずっと考える ─ 継続的テストモデルとシフトレフトなテスト活動をアジャイルにどう取り入れるか - Agile Journey
  • ユーザーが『アイドル』を歌うとサーバーが停止する - Qiita

    起きたこと 僕が運営している『オンライン絵しりとり』というサイトで起きた話となります。 これは訪れたユーザー同士で絵しりとりを楽しめるサービスです。 ある日、このサービスをホスティングしているConoHaVPSより、規約に違反しているため利用を制限した旨のメールが届きました。 お客様のVPSにおきまして、弊社会員規約に反するコンテンツが 検出されましたので、ご利用サービスの制限をさせていただき ましたこと、ご連絡申しあげます。 そして、メールが届いたほぼ同時刻にサーバーが停止され、サービスへアクセスできない状態になりました。 メールによると、JASRACより著作権侵害に対する防止措置の申し出があったとのことです。 指摘対象のコンテンツを確認したところ、ユーザーがサイト内のチャットでYOASOBIの楽曲である『アイドル』の歌詞の一部を投稿しておりました。 ご覧の通り、話の流れで流行りの曲をみ

    ユーザーが『アイドル』を歌うとサーバーが停止する - Qiita
    ch1248
    ch1248 2024/05/27
    ConoHaの問題っぽく見えるな……
  • 暗証番号を設定不要なマイナンバーカードと2026年の新カード【鈴木淳也のPay Attention】

    暗証番号を設定不要なマイナンバーカードと2026年の新カード【鈴木淳也のPay Attention】
  • 実践要件定義入門以前 - 勘と経験と読経

    最近ネットを見ていると要件定義入門的な記事が目についたので思ったことを書いてみる記事。ITシステム開発における要件定義に関するあれこれ。 【2023/10/10追記】続編の記事を書きました。実践要件定義入門 - 勘と経験と読経 目次 要件定義に関するおすすめ書籍 その要件定義は必要か 要件は決められるのか 要件定義をすることがルールで定められているから要件定義をする必要がある 要件は定義できるのか 現行の業務マニュアルをベースに要件定義をするつもりのあなたへ 現行システムをベースに要件定義をするつもりのあなたへ 外部業者を呼ぶ前に考えるべき事 どこから外注するかを考える 要件定義の作業期間を見積もる 要件定義に関するおすすめ書籍 この後に何度も引用することになると思うので、最初に要件定義のおすすめ書籍を紹介しておく。と言っても紹介するのは1つだけだ。 ユーザのための要件定義ガイド第2版 作

    実践要件定義入門以前 - 勘と経験と読経
    ch1248
    ch1248 2023/10/10
    非常に良い記事だった。要求定義の外注は高難易度だし、まだ自分達でやった方がマシなのよね。
  • 医療事故調査制度についてチーム医療:ダブルチェックの有効性を再考する(pdf)

    ダブルチェックの有効性を再考する 京都大学医学部附属病院 医療安全管理部部長 松村由美 平成30年度医療安全セミナー 主催:厚生労働省四国厚生支局 サンポートホール高松 平成30年12月7日(金)13時00分 ダブルチェックとは? 説明してみよう! 2 誤薬の防止 各業務プロセスの中でのダブル チェックなど,・・・が重要である 日看護協会 医療安全推進のための標準テキスト 論理・文脈チェック 表層チェック 3 各業務プロセス:薬剤の場合 処方 調剤 与薬 時間差 ダブルチェック 同時 ダブルチェック ダブルチェックなし または 研修医,指導医など または カンファレンス(論理・文脈チェックに向く) 業務として定めていない 処方鑑査業務 4 看護師は,同時ダブルチェックが多い ~注射薬のダブルチェックを例に~ • 方法は様々・・・ 指示簿とラベルと薬剤を二 人で一緒に同じものをみて います

  • 人生を仕組み化していったら結婚できた件 - Amosapientiam

    この記事はにレビューしてもらっています。 概要 この春結婚しました。 我々二人の生活は、多くの仕組み化・組織化を実行しているという点でかなり変である、ユニークだと思います。この記事では我々が導入している仕組み化を紹介していきたいと思います。 経緯 とは一年ほど前から人生をよりよく生きるためのアドバイスをし合う朋友・盟友的関係を築いていました。 お互いの人生には課題が山積しており、それを抜的に改善する必要があったのです。 そのために我々は仕組みの力に頼ろうと、さまざまな人生の仕組み化を図りました。 改革は功を奏し、我々の抱えていた諸問題は対処可能になっていきました。 また、お互いの課題解決的なコミュニケーションが大いに促進され、相互理解が深まっていきました。 我々の協力関係が実り多いものであることを深く確信した我々は、お互いの人生に貢献したい、二人三脚でこの人生を楽しんでいきたい、一緒

    人生を仕組み化していったら結婚できた件 - Amosapientiam
    ch1248
    ch1248 2023/04/20
    素晴らしい。家事もこれに近付けたり、こうあるべきという姿勢があると、だいぶ違うよね。
  • C#によるクライアント/サーバーの開発言語統一がもたらす高効率な開発体制 ~プリコネ!グランドマスターズ開発事例~

    2022/08/25 CEDEC2022

    C#によるクライアント/サーバーの開発言語統一がもたらす高効率な開発体制 ~プリコネ!グランドマスターズ開発事例~
    ch1248
    ch1248 2023/04/12
    C#、本当に息が長いな……。Unityや.NET Coreの存在が大きかったというのはあるが。
  • プログラマーを解雇して新しい人員に置き換えることがソフトウェアにとって致命的になり得るという指摘

    IT業界は人材の入れ替わりが激しいことが知られており、有能な開発者は好待遇を求めてさまざまなチームを渡り歩いているほか、企業側も不景気時には積極的に人員整理を行います。ところが、ソフトウェア開発チームの運営に関する複数の著書を持つBaldur Bjarnason氏は、「プログラマー解雇して新しい人員に置き換えることは、ソフトウェアにとって致命的になり得る」と主張しています。 Theory-building and why employee churn is lethal to software companies – Baldur Bjarnason https://www.baldurbjarnason.com/2022/theory-building/ Bjarnason氏はソフトウェアのプログラマーを庭師にたとえた上で、「ソフトウェアは一時的な庭であり、その運命は庭師と密接に関わっ

    プログラマーを解雇して新しい人員に置き換えることがソフトウェアにとって致命的になり得るという指摘
    ch1248
    ch1248 2023/01/13
    システム開発(新規と保守)+運用、実は正社員の年功序列が最も効率的なんじゃないかと思うことがある。
  • 現代のソフトウェア工学を示す「継続的デリバリーのソフトウェア工学」 - Shin x Blog

    年末年始に「継続的デリバリーのソフトウェア工学」を読みました。新年を迎えて、気分を一新して開発を始めるのに良いでした。 ソフトウェア開発に役立つプラクティスを示した 学びのエキスパート 複雑さ管理のエキスパート 実践的なツール データに基づく指標 ソースコードに限らずに広く適用 ソフトウェア開発者としての矜持 TDD あちら側とこちら側 「継続的デリバリー」は 1 要素 さいごに ソフトウェア開発に役立つプラクティスを示した ソフトウェア工学とは、ソフトウェアの実際的な問題に対する効率的、経済的な解を見つけるための経験的、科学的アプローチの応用のことである。 1.2 「ソフトウェア工学と何か」 書では、ソフトウェア開発の現場で役立つプラクティスを、ソフトウェア工学としてまとめています。ここでいう科学的アプローチとは、「特徴づけ」「仮説の定立」「予測」「実験」という形で思考を組み立て

    現代のソフトウェア工学を示す「継続的デリバリーのソフトウェア工学」 - Shin x Blog
    ch1248
    ch1248 2023/01/09
    よさそう。
  • 窓ガラスの結露を確実に防ぐ~冬場の結露対策 | 創造の館マイホーム

    ch1248
    ch1248 2022/12/11
    結露対策について。これは勉強になった。
  • エアコンのカビを防ぐ~10年間やってみた対策と検証結果 | 創造の館マイホーム

    ch1248
    ch1248 2022/12/11
    エアコンのカビ防止策について。
  • 間違いだらけの24時間換気システム設計~個室が寒い 窓を開けると2Fが換気されない・・ | 創造の館マイホーム

    「換気口の風が寒い」「寝るとき寝室が冷え切っている」「キッチンのゴミ臭が充満」3種換気は単純でコストが安くできることから広く施工されている。しかし設計難易度は一番高い。施工後の調整が不可欠だが、大抵の建築業者は風量測定もせず「完成しました」といって引き渡してしまう。 設計のポイント 新築の換気設計はファンを作るメーカーに丸投げすることが多い。我が家の場合MAXが担当したが、出てきた計画がダメだったので自分でやることにした。自分で設計してみて気づいた24時間換気システムの設計のポイントと注意点をまとめてみた。 1種と3種のメリット・デメリット 住宅では1種(強制吸気+強制排気)または3種(自然吸気+強制排気)で計画される。それぞれのメリット・デメリットは次ようになる。 1種のメリット ・設計通りの換気が実現できる。 ・建物の気密が怪しくても問題なく機能する(屋外と室内に気圧差を生じないため)

    ch1248
    ch1248 2022/12/11
    第3種の24時間換気システムの設計、そんなに難しいものだったのか……。
  • ソフトウェアを完成させる - blog.8-p.info

    Why is building the Ruby environment hard? の、 ソフトウェアは何もしないと壊れる というのは事実ではあるんだけど、それが良いことかというと、どうなのかなあと思う。ほかにも、我々プログラマはつい「ソフトウェアは完成しない」とかいってしまうし、それは雇用のためには良いことなんだろうけど、でも当に完成しないんだろうか。 Gologrus の README には、こんな段落がある。 Logrus is in maintenance-mode. We will not be introducing new features. It’s simply too hard to do in a way that won’t break many people’s projects, which is the last thing you want fro

    ch1248
    ch1248 2022/09/15
    「枯れた」システムやツールというのは存在はするからねえ。更新を止める/止めない、の選択肢の存在は欲しい。
  • システム開発の内製化って本当に必要なのだろうか - novtanの日常

    comemo.nikkei.com そもそもの話としてなんですが「システム」という言葉が主語デカなんですよねえ、というところから話をスタートしたい。 来、システム開発の歴史をたどると、初期の大企業(銀行とか)はまあまあ内製化からスタートしていることが多いと思うんですよね。ただ、ここでいう内製化ってのは全部をその会社に所属している人が作っている、というわけでは当然ながら、ないです。ハードウェアはベンダーに依存しているし、開発自体もSIerの手を借りることは多かったはず。ただ、自分たちで要件を決めて、仕様を検討して、設計して、テストする、という意味においては間違いなく内製化をしていたはず。 そういう基幹系システムがコンパクトに中小企業に展開されるようになると、そんな体力は当然ないので実質パッケージみたいな形で導入されていったというところでしょうか。 こういう企業内システムはいわゆる「電算化」

    システム開発の内製化って本当に必要なのだろうか - novtanの日常
    ch1248
    ch1248 2022/07/02
    結論は同意。ただ、ITでメシ食ってる&既に技術力ある会社なら内製化は良い手段だと思う。ベンダー丸投げは中期的には保守開発やリプレース、運用周りでグダグダになる事が非常に多いのよね(結局そこで工数や金がかか
  • Oracle Cloud Infrastructureのアカウントが突然停止したので状況や調査内容を書いていく

    Oracle Cloud Infrastructureのアカウント停止発覚 最初にも書いたが、Oracle Cloud上で稼働させているサーバプログラムが応答していないことから、アカウントが一時停止状態にあることが発覚。 急遽停止してしまったサーバプログラムに対しては暫定対応をとり、事なきを得る。 ちなみにダッシュボード上には下記のようにアカウント一時停止の旨が表示されている。 Oracle Cloudアカウントの状況 最初に自身のOracle Cloudアカウントの契約状況を書いておくと、少し前にアカウント自体はトライアルから有料アカウント(Paid Account)にアップグレードが完了している状態。 請求なども想定通りに発生しており、アカウント自体は問題なく運用できていると思っていた。 そのためアカウント一時停止が発覚した際はなぜなのか?という疑問と、突然頭から氷水をかぶったような感

    Oracle Cloud Infrastructureのアカウントが突然停止したので状況や調査内容を書いていく
    ch1248
    ch1248 2022/06/12
    Oracle Cloud使うのはリスクでしかないな、これは。
  • 中田の質問箱です

    みずほ関係者の方でしょうか。連日のように繰り返されるシステム障害とその批判を目の当たりにして疲弊しているのだろうとお察しします。ただ、仰っている内容はどれも妥当性に乏しいので、公言されるとますます批判の声が強まってしまうことが危惧されます。ご自身の反論が有効かどうかを検証する有力な方法は「他の2メガバンクではこのロジックは通用するか?」という考え方です。以下、すべてこのアプローチでご説明します。 まず「銀行リテールの利益は250億円しかなく赤字のこともあるのだから莫大な設備投資をすることは株主にとって妥当ではない」というのは論理が全く逆で、莫大な設備投資をしたのですからもっと稼がなければならないのに稼げていないことが問題なのです。MUFGやSMFGをご覧頂ければ銀行リテールだけでも1,000億円単位で儲けていることがわかるでしょう。しかもシステム統合に要した費用はMUFGで3,300億円、

    中田の質問箱です
    ch1248
    ch1248 2021/09/10
    質問は何言ってんだ感があったが、回答がとても秀逸。
  • COCOA騒動メモ

    COCOA が動いていなかったことで大臣が謝罪してひと騒動起きている件について、開発者視点からのメモを残してみます。 なぜこのメモを書いたのか 世間的には不正確な情報で叩ければOKの風潮が強くてしんどいので、正しいと思われる情報を拾い集めたものです。中抜きwww 王子wwwww Xamarin wwwwwwww みたいな人にはあんまり興味ないかと思います。 調べ始めたきっかけはこのツイートと引用されたblog記事ですが、記事の内容が違うことはすぐに指摘されて撤回されていたのですが、実際どうだったのかさらに調べてみました。 接触通知アプリ COCOA とはなんなのか 仕組みとか何かは公式サイトでもみてもらうとして。この件で煽っている人でも一部理解できていない人がいるようなのですが、直接的な効果としては 保健所が濃厚接触者追跡をする際の手助けとなるためのアプリ ということになります。アプリをイ

    COCOA騒動メモ
    ch1248
    ch1248 2021/02/10
    Xamarinを原因と言う方もいるが、機能は1つなのに実装が2倍になる弊害も中々大きく、簡単に結論付けれる話でもない。
  • COBOL技術者を絶滅させても何も問題は解決しない | おごちゃんの雑文

    最初はもっとキャッチーなタイトルにしようと思ったんだが、そんなしょうもないことしてもしょうもないんで。 そろそろCOBOL絶滅のシナリオを考えようか 「語るに落ちる」とはこのことである。この人はCOBOLに親でも殺されたのだろうか? こんな炎上芸で問題が解決したら、何の苦労もない。 COBOLのメリットを一々挙げて反論する気はない。しかし、事実として現にCOBOLは多くの場所で使われている。その理由は何か。 あれこれあるのであるが、最大のメリットにして最大のデメリットとして挙げたいと思うのは、 後方互換性の高さ である。 後方互換性が高いことについてのメリットは、誰でもわかることだろう。COBOLもそれを売りにして来た。「古いCOBOL」のコードであっても、現代の最新のCOBOL規格から見てvalidであって、正しく同じ動作をするバイナリが出て来る。COBOLは実に60年近い歴史があるのだ

    ch1248
    ch1248 2019/04/09
    正しい。が、「世の中はITを中心に回ってない」事が開発の地獄っぷりの原因であるとも言えるので、今後の技術者の増加も踏まえるとITは基礎教養として世の中に位置付けられるべき。
  • チャットbotを導入して、「社内ヘルプデスクの電話対応」をやめてみた結果

    チャットbotを導入して、「社内ヘルプデスクの電話対応」をやめてみた結果:問い合わせが「10分の1」に(1/4 ページ) 社員向けのヘルプデスクは情シスの代表的な業務の1つ。しかし、度重なる同じような質問にうんざりすることも少なくないだろう。そんな中、チャットbotを導入して、ヘルプデスクの電話対応をやめたという会社がある。 「VPNにつながらないんですが、どうしたらいいですか?」「支給されたスマホの初期設定が分からないんです」 情シスの皆さんであれば、社員からこういった質問を受けたことがあるだろう。多くの企業で、情報システム部門は社内向けのヘルプデスクとしての機能を備えている。他の仕事もあるのに内線電話に追われて、一日中てんてこ舞い……なんて話も珍しくはない。 とはいえ、問い合わせに対応できずに社員の業務が止まってしまっては末転倒だ。そんな中、「毎週水曜日以降は、ヘルプデスクの電話対応

    チャットbotを導入して、「社内ヘルプデスクの電話対応」をやめてみた結果