新しい技術が出てきたとき、大多数の若い人よりも圧倒的にスピーディーに使いこなすおっさんは珍しくない。 新技術を習得する能力は、年齢よりも、「スキルを獲得するために必要なスキル」、すなわち「メタスキル」に大きく依存するからだ。 たとえば、ある開発ツールを導入すべきかどうか若い人に相談されたので、「まず、ドキュメントを読もう」と言ったら、「ドキュメントを読んでもよくわからなくて。。」と言う。ググったらすぐに公式サイトの至れり尽くせりのドキュメントが出てきたので、「これ読めばいいじゃん」と言ったら、こんなに大量の英語のドキュメントを読むのは無理だと言う。 あるいは、AIを導入するという話になったとき、「AIがよく分からないので教えて欲しい」と言ってきた若い人に、良質の入門書を勧めたら、数式が分からないので読めないのだという。数式の読み方を教えてみたら、数式以前に、そこで使われている数学概念自体を

0 Get notified when this content is updated. Follow Please wait...

そもそも既存はどんなロジック？ RDBなんだからWhere句使ったら？ なぜファイルにすると速くなるのか？ 並列化と分散処理による高速化の可能性 COBOL使う必要あったの？ Javaとかじゃダメだったの？ まとめ TLを見てると以下の記事が少し話題になってました。 tech.nikkeibp.co.jp tech.nikkeibp.co.jp 対象の記事は有料会員じゃないと見れないのだけど事例としては以下みたい。 リソース - ユーザー事例 - COBOL製品 ユーザー事例 : マイクロフォーカス さて、この記事の驚きポイントは「１億レコードくらいのDB処理をRDBからCOBOL + CSVに変更してUnixサーバからWindowsサーバに変える事で性能を維持しつつコストを1/5くらいにした」という事でしょう。 「せっかく7割もあったSQLを全部COBOLに変えるとか時代に逆行しすぎ！」

2019年5月21日、GoogleはG Suiteに保存されたパスワードの一部に問題（ハッシュ化が行われていなかった）が確認されたとして利用者へ案内を行っています。ここでは関連する情報をまとめます。 Googleの発表 cloud.google.com この問題の影響はビジネス向け利用者（G Suite ユーザー）が対象。 無料のGoogle アカウントへの影響はない。 2つの問題が確認され、いずれも修正されている。 問題を悪用した兆候は確認されていない。 確認された2つの問題 No 発生原因 保存内容 影響期間 問題① 管理コンソールのパスワード設定・復元機能バグ パスワード平文のコピー 2005年以降 （問題のツールは削除済） 問題② ユーザーサインアップ時の暗号化された内部システムへの誤保存 パスワード平文の一部 2019年1月以降 （保存は最大14日間） Googleは問題①を20

2019年4月27日、Dockerはコンテナ共有サービス「Docker Hub」が不正アクセスを受け約19万件のアカウントに影響が及んだとして情報漏えいの可能性について発表しました。ここでは関連する情報をまとめます。 公式リリース success.docker.com 被害の状況 Docker Hubのデータベースが不正アクセスを受けた。 不正アクセスにより一部のユーザー情報が盗まれた恐れがある。 影響を受けたのは約19万件のアカウント。全ユーザー数の約5%未満。 Dockerは不正アクセスの時間は短時間と説明。 2019年4月25日にDockerがDocker Hubデータベースへの不正アクセスを把握。 この侵害によるDockerの公式イメージへの影響はない。 不正アクセスの手口については明らかにされていない。 メール届いた場合は影響を受けた恐れ Dockerから連絡メールが届いた場合は

static おじさんと呼ばれる人がいたそうだ、あるいはいるそうです。インスタンスの生成を嫌がって、何でも static メソッド にしてしまう人のことです。static メソッドと呼ぶよりも関数と呼んだ方がよいかもしれません。 インスタンスの生成を嫌がるのは、気持ちはわかります。メモリ管理が GC 任せで、速度にどう影響するかわからないのが嫌なのでしょう。現在では、細かいメモリ管理が本当に必要な場合はほとんどないので、ほとんどの場合インスタンスの生成なんて無視してよいでしょう。しかし、ひとつひとつの処理に対してコスト感覚を持つこと自体はよいことです。問題があるとすれば、その感覚が誤っていることでしょう。 ただ、おそらく static おじさんと嘲笑されたのは、コスト感覚の誤りからよりも、未知のものがわからない、覚える気がない態度からでしょう。いつか私も Java おじさんとか Linux

使い回しを回避するパスワードの作成方法 ここでは、使い回しを回避するパスワードの作成方法の一つを紹介します。 1. コアパスワードの作成 まず、自分の趣味や興味のあることなどから決めた短いフレーズを基に、任意の変換ルールを適用して、憶えやすく、強度の高いパスワードを作成します。これを全てのパスワードに共通して使用する“コアパスワード”とします。 例えば、「テレビが好き」というフレーズを決めた場合、このフレーズをローマ字に変換します。ヘボン式ローマ字で変換すると、「terebigasuki（12文字）」となり、これだけである程度の長さ（桁数）を確保した憶えやすいパスワードが作成できます。 次に、ローマ字に置き換えた文字列の一部を大文字、記号、数字に置き換えたり、数字や記号を追加したりなど、任意の変換ルールを適用します。 例えば、図1の変換ルール1では助詞の「が＝ga」を大文字に変換し「GA」

KrebsOnSecurityが関係筋からの情報として、一部のFacebookユーザーのパスワードが暗号化されずに社内のデータストレージに読取可能な方式（平文）で保管されていたセキュリティ上の問題が生じていたと明らかにしました。Facebookはその後、この問題に関する見解を公開しています。ここでは関連する情報をまとめます。 KrebsOnSecurityの記事 問題を明らかにしたBrian Krebs氏の記事。 krebsonsecurity.com 明らかになった問題（Krebs氏の記事より） 一部のユーザーパスワードを平文で保存。 保存されたデータに対して2万人以上のFacebook従業員が検索可能な状態だった。 アクセスログから平文パスワードを含むデータに対して約2000人のエンジニア／開発者のアクセスが判明。 約900万の内部クエリが実行されていた。（悪用は確認されていない） 問

展望2020年のIT企業というシリーズ企画の記事を、たまたまTwitterで見かけました。 japan.zdnet.com この記事で語られるDX(デジタルトランスフォーメーション)ってものすごいオワコン臭で衝撃を受けました。汎用機をお守りする時代は終わった、これからはオープンなWeb技術を駆使して基幹システムではなく顧客の売上を支えるITを作るのだ、SO！それが！DX時代！ みたいなノリで書いてあって、1ミリも次世代感が無い。 生きている時間軸が違うんだなと思いました。 DXの妨げは社内システムにあるらしい 色んな定義をされているDXですが、ここでは経済産業省の提唱する「DXレポート」のサマリー版に書いてある問題点とDX推進のためのシナリオみたいなのを引き合いに出します。 DXレポート ～ITシステム「2025年の崖」克服とDXの本格的な展開～（METI/経済産業省） 簡単に言うとこうい

今回の記事は、最近考えていたことのメモです。 ここ最近いろいろ考えていたのですが行き詰まってきたので、とりあえず課題意識を説明する文章だけ書いてみました。結論はまだありません。 障害と異常の定義 話の前に、障害（failure）および異常（anomaly）という単語を定義しておきます。人によって定義は違うと思いますが、自分が文章を書くときは以下のように区別しています。 障害：サービスの停止や、サービス品質の深刻な劣化を引き起こすようなインシデント 異常：サービスに対する深刻な問題は引き起こさないが、通常は起こらないはずのインシデント この定義をもう少し詳しく説明するために、例として、ロードバランサと、その背後に5台のアプリケーションサーバがあるシステムを考えます。 これらのサーバが5台ともダウンしたり、半数を超える3台がダウンして応答時間が極端に長くなった（例えば10秒以上になった）場合は

OSI参照モデルとTCP/IPモデル なぜいまでもOSI参照モデルによる説明が多いか QUICは、TCP/IPモデルのトランスポートとはいえるが、OSI参照モデルのレイヤ4とはいいにくい HTTP/QUICモデル QUICをどう解説するか OSI参照モデルとTCP/IPモデル かつてぼくたちは、7つのレイヤに分かれたOSI参照モデルという姿でコンピュータネットワークを学び、その7層のモデルにそって各種のプロトコルを理解しようとしていました。 だから、「SONET/SDH上のATM回線でIPパケットをやり取りする」という構想をきけば、「つまり、SONET/SDHがレイヤ1で、ATMがレイヤ2で、IPがレイヤ3なのだな」という枠組みを頭に描いていました。 と同時に、OSIのレイヤとはいったい……、というアンビバレントな想いにさいなまれることもよくありました。 「SONET/SDHがレイヤ1って

2GBの Incremental CMS でぼちぼち動いていて、6GBも割り当てるのは避けたいという環境で、G1GCどないやろって試した記録。実用レベルにはなったのでしばらく動かしてみるけど、そこまでメリットは…という感じ。 -Xloggc:gc.log -XX:+PrintGCDetails -XX:+PrintGCCause を付けて起動しては GCViewer に食わせて眺めるの繰り返しをしていた。 起動完了時に FullGC を手動で実行しているっぽいが、今の構成ではそこまでメリットがないので1secをケチって -XX:+DisableExplicitGC をつける -> いい感じ Young:Tenuredをガッと1G:2Gにしてみる -> GC回数やトータルの時間こそ減っても、最大の停止時間が延びてしまった。恐らくレンダリング周りを中心に短命なオブジェクトが多いので、まとめて掃

アーキテクチャの問題とは、システムをどこで分割 (decomposition) するかという問題と言い換えてよいでしょう。分割するのは、魚を捌くのと同じようなもので、包丁を入れるべき場所というのがあります。 分割するというからには、切り分けるサイズがありますが、今回は分割の単位の議論はしません。なぜかといいますと、ちゃんとつくれば、システムの部品は入れ子構造になっているはずです。再帰的に作られているという言い方もできます。つまり、システムを切り分けて出てきたものは、やはり同じやり方で切り分けることができます。マトリョーシカというか、フラクタル的といいますか、問題を切り分ければ同じものが出てくるはずです。明らかに正しいことが分かるサイズが最小単位で、そこに至るまで分割を繰り返されたものが、ちゃんとした仕事でしょう。 問題をバラすときにタテに切るかヨコに切るか、そしてその切り目はどこかというの

IT Leaders トップ ＞ テクノロジー一覧 ＞ システム開発 ＞ 事例ニュース ＞ 小田急トラベルが基幹サーバーを新ハードに入替、旧仮想OSが動くサーバーを製造して対応 システム開発 システム開発記事一覧へ [事例ニュース] 小田急トラベルが基幹サーバーを新ハードに入替、旧仮想OSが動くサーバーを製造して対応 2018年11月20日(火)日川 佳三（IT Leaders編集部） リスト 旅行事業会社の小田急トラベルは、基幹システムが動作する全58台の仮想サーバーについて、基盤となる物理サーバーを新サーバーへと移行した。旧版のサーバー仮想化ソフト「VMware ESXi 5」を使い続けるため、旧版ソフトが動作する新品のサーバー機を製造するファナティックのサービス「ファナティック ハード入替サービス」を利用した。ファナティックが2018年11月20日に発表した。 小田急トラベルは今回、

はじめに この記事は、身近なプログラマー仲間に向けて書かれたまとめです。 私的な、身内向けの解説文ではあるのですが、 仕事でプログラムを組む人全般に通じるように書く、つもりです。 主張 私は基本的に Perl プログラマーです。ですが仕事では、 Perl で 1ファイルで全部書けるような小さな案件でも、 Perl で書かれたモジュールと、 (上記を呼ぶ) Zsh で書かれたスクリプト のように、２つのプログラムに分けて書いたほうが良いと考えています。 この記事ではその理由を解説します。(この考えは Perl と Zsh の組み合わせ以外にも、応用できます) どんなコード量・規模を想定した話か分からないと納得できない人もいると思うので、 参考として、この考えに基づいて書いた昔のコードを載せておきます。 （コードの解説はありません。要望があれば書きます） github.com 仕事のコードを２

先日のエントリの反応として、多値の批判をしているように受け取られた方がいました。 実際には、多値の批判をしているのではなく、Go言語の「多値とそう見えるけど違うものがある」という仕様を批判したものでした。 また、タプルにこだわっているという受け取り方をした方もいました。 このエントリでは、「タプルにこだわっているのではない、多値にこだわっているのだ」ということを説明しようと思います。 このエントリで出てくるコードは言及がない限り妄想上のもので、実際の言語のコードではありません。 長いから3行で。 スタックマシンと多値は仲良し。継続と多値も仲良し。 多値は多値、タプルはタプル、みんなちがってみんないい。 多値とは、カンマで区切られた単なる複数の値だよ。妄想だけどね。 これで満足して仕事に戻っていただいて構いません。以下オマケ。 多値とタプルの違い まず、多値とタプルの意味的な違いについてをは

はじめに ドワンゴではniconicoの配信系サービスのバックエンドで利用するために、Frugalosという名前の分散オブジェクトストレージを開発しているのですが、この度OSSとして公開することとなりましたので、この場を借りて軽く紹介させて貰います。 FrugalosはRustで実装されており、現時点では以下のリポジトリが公開されています: raftlog_protobuf: raftlogへのProtocol Buffersサポートの追加 “Frugalos"って何？ “Frugal object storage"の略です。 “frugal"は日本語では「倹約な」や「節約する」といった意味となり、「読み書き性能を犠牲にせずに、膨大な数のBLOB（Binary Large OBject）を、容量効率良く保持する」ことを目指して開発されているオブジェクトストレージです。 提供されている機能は