米CrowdStrike（クラウドストライク）は、同社製品「CrowdStrike Falcon」（以下、Falcon）が原因で2024年7月19日（米国時間）に発生したシステム障害に関する「根本原因分析」（RCA：Root Cause Analysis）の結果を公表。システム障害に至った詳細や今後の対策を明らかにした。 既にほぼ全てのシステムが復旧 根本原因分析とは、問題の根本的な原因を特定し、対策を講じて再発を防止するためのプロセスを指す。根本原因分析の結果は、クラウドストライクのWebサイトで米国時間2024年8月6日に公開された。 米Microsoft（マイクロソフト）は、今回のシステム障害で約850万台のコンピューターが影響を受けたと推定。クラウドストライクによると、米国時間2024年7月25日時点で約97％、同7月29日時点で約99％が復旧したという。 システム障害の原因となっ
世の中にはプログラマー35歳定年説というものがあった。昔からそんなのはないという人と、あるという人がいた。40代も半ばになったときに「あぁ、これが35再定年説の根拠か」というものがなんかちらほら見えるようになってきたので書いてみようと思った。 世の中にはものすごいプログラマーというのはやっぱりいる。なんなら死ぬまでプログラミング書いていられるという人たちもいる（ブラック的な意味ではなく）。そんな彼らからしたらプログラマー35再定年説とか意味がわからない都市伝説にしか映らないだろう。 だが、普通に職業プログラマとして生きている俺のような人からすると、この35歳定年説はかなりの真実味を帯びている。 だが、そんな俺でも40代半ばまで延命できたのはやはり技術革新のおかげかもしれないが、結局平均寿命が伸びただけとも言えるだろう。 まず、技術に対する姿勢が変わる。正直言うとプログラミングとかもうしたく
www.ntt.com これを見てちょっと最近の流れと違うなぁとしみじみ思ったので全力で反論してみる。。 僕自身は８１年代生まれ、小学校6年生のときにPC98シリーズのN88Basicで独学でBasicから入って、中高とDirectX使ってゲーム作ったりして、大学のときにバイトで実務のプログラムを初めて〜、と何故かまぁ小さいながらも経営者として傍らまだ炎上した案件とかに入って消火活動に勤しんでたりしてる。まぁ後半はどうでもいいけど、この世代では日本海外とわず独学で勉強するのは至って普通だと思う。クロアチアだと勿論PC98じゃなくてAmigaとかドイツ製のPCが主流のよう。 で、一方で最近の新入社員たちを見てると最初からスクールに通って、大学で授業を真面目にうけて、インターンでメンターに面倒を見てもらって、バイトも常にメンターがいつつ実務に関わってって流れが普通。プログラミングは常に勉強とし
この記事は、Merpay Tech Openness Month 2020 の6日目の記事です。 メルペイでBackendエンジニアをしている柴田（@yoshiki_shibata）です。この記事では、Go言語のtestingパッケージに用意されている並列化の機能について説明します。 Go言語では、テストコードを作成するためのtestingパッケージが用意されています。一般に開発するソフトウェアの規模が大きくなるに従って、作成されるテストコードの量も多くなり、すべてのテストが終了するまでの時間も長くなっていきます。特に、データベースへアクセスするようなテストでは、データベースへの通信時間がテスト時間の多く占めますので、テストコードを逐次実行するよりは並列実行することで、テスト時間を短縮できます（厳密には用語「並行」ですが、t.Parallel()メソッドの説明なので、この記事では用語「並列
本当に迷惑なんだ。 センスがない奴の何が問題かというと、技術がないとか、ベストプラクティスを知らないということではなく、根本的に「頭がおかしい」ことなんだ。 センスのない奴は、普通の人間が到底思い付かないことを平然と行う。所詮、本に書いてあるようなアンチパターンは、「経験のない人は典型的にこういうことをしがち」という例であるが、センスのない奴はそういう典型的なアンチパターンにすら当てはまらないほど意味不明なことをする。だから、「センスのない奴は典型的にこういうことをする」という具体例を挙げることが非常に難しいし、「ここがダメだから直せ」という指摘もできない。 最近見た例を書いてみる。2次元のテーブルを扱うJSONだ。 普通の人なら、何も考えず以下のような実装をするだろう。フィールドの定義とデータが分かれているのは、ユースケースによってフィールドが可変だからだ。 [ {fieldName:
TypeScriptは、JavaScriptでも大規模なアプリケーションを開発しやすくすることを目的に開発されたプログラミング言語です。 確かにJavaScriptは元々、大規模な開発を想定した設計ではありませんでした。それでも、JavaScript自体が進化して、大規模開発に対応してゆけば良かったはずです。しかし、実際はそううまくは行きませんでした。代わりに、大規模開発の一部はTypeScriptが引き受けることになったのです。 なぜ、そうなったのでしょうか？その答えはJavaScriptの歴史にあります。TypeScriptが必要な発明で、そして、今もなお必要とされている理由が見えてきます。それでは、TypeScript誕生以前の歴史をひも解いていきましょう。 1990年代JavaScriptの誕生JavaScript誕生以前は、簡単なフォームのバリデーションをするのも、サーバーサ
「な、なんじゃこりゃあああぁあっtっt！！！！」 ・・・ ・・・ ・・・ 読みやすいコードを書きたい 複雑な条件分岐は、書いている本人も、後からそれを読む他人も非常に疲れるものです。 令和プログラマー*1である私自身、なるべく気を付けようと思っていますが、ついつい条件反射でif-elseを書いてしまいそうになります。 （*1: 令和になってからプログラミングを知った人。初心者のこと。） if - elseを使わない条件分岐のレパートリーを増やす if - else文が絶対ダメということでは決してありません。 たくさんのレパートリー、つまり引き出しを持っておけば、適切な読みやすいコードをかける可能性が上がるかなと思うのです。 文と式 JavaScriptには「文」と「式」があります。 この2つの違いを意識することが重要ではないかと思います。 「文」は、マシンへの命令です。 「式」は数学的な値
![【JavaScript】本日未明、[ if - else ]さんが死体で発見され... - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/6189b7c62c1fc92d2ef19a614c58949db9c63b2f/height=288;version=1;width=512/https%3A%2F%2Fsiteproxy.ruqli.workers.dev%3A443%2Fhttps%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-1150d8b18a7c15795b701a55ae908f94.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark%3Dhttps%253A%252F%252Fqiita-user-contents.imgix.net%252F~text%253Fixlib%253Drb-4.0.0%2526w%253D840%2526h%253D380%2526txt%253D%2525E3%252580%252590JavaScript%2525E3%252580%252591%2525E6%25259C%2525AC%2525E6%252597%2525A5%2525E6%25259C%2525AA%2525E6%252598%25258E%2525E3%252580%252581%25255B%252520if%252520-%252520else%252520%25255D%2525E3%252581%252595%2525E3%252582%252593%2525E3%252581%25258C%2525E6%2525AD%2525BB%2525E4%2525BD%252593%2525E3%252581%2525A7%2525E7%252599%2525BA%2525E8%2525A6%25258B%2525E3%252581%252595%2525E3%252582%25258C...%2526txt-color%253D%252523333%2526txt-font%253DHiragino%252520Sans%252520W6%2526txt-size%253D54%2526txt-clip%253Dellipsis%2526txt-align%253Dcenter%25252Cmiddle%2526s%253D14f38d2a33c88df06d0407b5c69769c0%26mark-align%3Dcenter%252Cmiddle%26blend%3Dhttps%253A%252F%252Fqiita-user-contents.imgix.net%252F~text%253Fixlib%253Drb-4.0.0%2526w%253D840%2526h%253D500%2526txt%253D%252540impl_s%2526txt-color%253D%252523333%2526txt-font%253DHiragino%252520Sans%252520W6%2526txt-size%253D45%2526txt-align%253Dright%25252Cbottom%2526s%253D7f0989a2a3e19e7a29422b3278fe987f%26blend-align%3Dcenter%252Cmiddle%26blend-mode%3Dnormal%26s%3Dc563a262385af1441cceca54579995d3)
2020/5/13追記 **オブジェクト指向と哲学の関係について書いた記事ではないです。**せっかくだしQiitaっぽいタイトルつけようと思ったら結果的に釣りっぽくなってしまった 概要 オブジェクト指向とは何か？ということを真面目に調べていくと、オブジェクト指向には二種類ある、という話に突き当たる。sumim氏のQuora回答などを参照。 Smalltalkの設計者アラン・ケイによる、メッセージング重視のオブジェクト指向 C++の設計者ストラウストラップによる、クラス重視のオブジェクト指向 今回はこの前者のオブジェクト指向について、アラン・ケイの書きものを読んで調べた結果をまとめ、コメントを付す。 参考文献は最後にまとめて出す。参照元は「（AOO）」のように略記で示す。 アラン・ケイのオブジェクト指向 OOPは私にとって、メッセージング、状態処理の局所的な保持・保護と隠蔽、そしてあらゆる事
世界は60年前の言語で動いている。米コロナ失業申請がクラッシュ、COBOLの古兵が大忙し2020.04.17 22:0040,466 Joanna Nelius - Gizmodo US ［原文］ （ satomi ） コロナでギークが一番驚いたのがこのニュース。 失業給付金の申請者が史上最悪の1680万人に達して全米で業務システムがクラッシュ！ 化石のプログラミング言語COBOLを操る古参プログラマーが現場の最前線に駆り出され、｢こんなこともあるんだな…｣、｢コロナって計り知れないな…｣とIT業界を驚嘆させています。 絶滅すると言われ続けて60年COBOLは1959年、インターネットが生まれる遥か以前のメインフレーム時代に生まれたコンピュータ言語です。大学で教わるようなものではなく、使いこなせるのは現場で覚えた生き残りの人たちだけ。完全自動処理ではなく、手動で実行する処理も多く、早くから
ネット上をうろうろしていたら、ジョエル・テストにたどりついた。 ずいぶん昔Joel氏の文章読み漁った記憶がある。 今回あらためて読んでみると、確かにいい事がたくさん書いてある。 ジュエルテストの記事は2000年に書かれた物であるが、今の時代でも通用する考えだ。 というか、コンピュータ業界って、ドックイヤーと言われるが、７年経っても進歩しているのか疑問 プロジェクト管理に関しては、色々と考え、実践してきたわけだが、ぐるぐる回って、結局Joelさんの所に再びたどり着いたというちょっと悲しい現実 ジュエルテスト 1.バージョン管理システムを使っているか？2.１オペレーションでビルドを行えるか？3.毎日ビルドを行っているか？4.バグトラッキングシステムを持っているか？5.新しいコードを書くまえにバグを修正しているか？6.更新可能なスケジュール表を持っているか？7.仕様書を持っているか？8.プログラ
Jeff Atwood / 青木靖 訳 2007年2月26日 レジナルド・ブレイスウェイトが書いていることを読んだとき、私はそんなわけないだろうと思っていた。 私と同様、この著者は、プログラミングの仕事への応募者200人中199人はコードがまったく書けないということで苦労している。繰り返すが、彼らはどんなコードも書けないのだ。 彼が引用している著者というのはイムランのことで、彼は単純なプログラムも書けないプログラマをたくさん追い払っているということだ。 かなりの試行錯誤の末に、コードを書こうともがいている人たちというのは、単に大きな問題に対して苦労しているのではないことがわかった。やや小さな問題(連結リストを実装するというような)に対して苦労するということでさえない。彼らはまったくちっぽけな問題に苦労しているのだ。 それで、そういった類の開発者を見分けるための質問を作り始め、私が｢Fizz
Help us understand the problem. What is going on with this article? みんな、プログラミングしてる？ Rxがまた賑やかだなって時代なので実際UniRxを使った運用経験があるのでちょっとそのことについて書く。 UniRx？なにそれ？って方は以下の記事参考にしてください。 Qiita記事: UniRx入門 個人の感想 地獄そのものでした。 自身がLとして開発入る時は二度と採用することはないです。 UniRx自体はとても素晴らしいものですが、使うものによっては神にでも悪魔にでもなれるマジンガーZみたいな存在です。 この記事はUniRxを貶しているわけではなく、UniRxを使いこなす自信がない場合は採用を考えたほうが良いという記事です。 UniRxの良いところ シンプルにかける 可読性が上がる 制御実装が楽になる よく見かけるのはこ
何が良いプログラムかという点はもちろん人やコンテキストによって異なりますが、少なくともプログラマーとしての私の信念としては、 機能拡張や変更が容易なプログラム 単体試験によって正しく動作することの検証が容易なプログラム どういった内容が記述されているか理解しやすいプログラム といったものこそ、「品質の高い」プログラムが持つべき性質として、まず真っ先に挙げるべき事項であると考えています。もちろん、前提として顧客の要件に従うということは大切なことです。しかし、一般に要件は長期にわたって変更されるものですし、使い捨てのプログラムを除けば、プログラムを長期にわたって保守するコストという点も見過ごすべきではありません。したがって、ユーザーの目には触れない上記の性質をもっと重視すべきだと思うのです。 DRYの原理 上記のような性質を満たすプログラムを作る上で大切になってくる原理として、DRYの原理とい
わたしはこれまで、C言語、Visual Basic、SAP ABAP、最近になって ASP.NET C# などの言語を使ってきた。 「自分でクラスを作ってオブジェクト指向っぽいことをしている」なんてことはまったくない。特に「メンバー関数をstatic宣言すればインスタンス宣言をしなくてもいい」ということ知ってからは、メンバー関数を従来のファンクションのように使っている。共有変数も、pubulic static宣言していまう。したがってプロパティなんて作らない。 staticを理解していない人のコードを見ると、いちいちインスタンス宣言しているので笑ってしまう。データベースにアクセスするアプリケーションをC#で書いているのだが、Visual Studioで供給しているSQL関係のクラスを使えばできてしまうのだから。 オブジェクト指向の入門書では、クラスが持つ隠ぺい性が強調されているが、これは他
「staticおじさん」という言葉をご存じでしょうか。「static」というのは、Javaのstaticメソッドのことです。Javaでメソッドを呼び出すときにはクラスからインスタンスを生成してインスタンスのメソッドを呼び出すのが普通です。一方、staticメソッドはインスタンスを生成しなくてもクラスから直接呼び出せます。このため、オブジェクト指向プログラミングを理解していない古いタイプのプログラマは、Javaでもstaticメソッドを多用します。これを揶揄して「staticおじさん」と呼ぶのです。 staticおじさんについては、わかりやすく解説したブログエントリが有名です（参考リンク）。実際のシステム開発の現場でstaticおじさんに苦しめられている様子をまとめたページもあります（参考リンク）。 なお、Javaのstaticメソッドを多用する人に限らず、古い感覚にとらわれて周囲に迷惑をま
Object-Oriented Conferenceの発表資料です。 https://fortee.jp/object-oriented-conference-2020/proposal/1224f293-8624-4448-866f-5d1b991d377f カンファレンスの感想はこちら。 …
1995年まで：イノベータとアーリーアダプターの時代； 1995-2005 ： オブジェクト指向ブームと混乱の始まり； 2005-2015 ： さらなる混乱と収束の兆し； 2015- ; 現在の状況とこれからの２０年
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
