ユーザーまたはメーカーが独自に作成して登録した文字。 ユーザー定義文字とも呼ぶ。 JISコード表に含まれていない、異字体や記号などを利用したい場合に作成する。 Windows 98などでは、付属する外字エディターで外字を作成し、登録できる。 ざっくり言うと、「文字コードで表現できないので、独自に拡張した文字」のこと。 いつ使うのよ 多くは人名・地名でのマイナー漢字。 あと「㌢㍍」よろしく独自記号を使いたいなんて場合にも使われるけど、これは今回の話の対象外です。 人名における外字の具体例 マイナー漢字 漢字はJISの規格で第1～第4水準に分類されます。 このうち第3水準、第4水準の漢字はShift_JISの文字コードで定義されていないものが多い。 そういった漢字を使用する際に、外字として登録しているケース。 ※ 実際に遭遇した例としては、「㐂」とか「昱」とか。 ※ 「第2水準だけど、その文字

障害の再発防止策は、 1. メカニズム 2. ツール 3. ルール 4. チェックリスト の順番に検討せよ。 上記は、私が20年前に所属していたパッケージソフト開発会社の標語です。 ※転職したので現在の所属会社ではありません。 当時はまだインターネットが今ほど普及しておらず、修正パッチはCD-Rで配布していました。 特に、データ破損系の障害の場合は、 お客様にファックスで障害内容を報告し、 緊急ホットラインを開設し、 データ異常が見られる場合はバックアップを預かって修正後に返却し、 上記と同時並行でバグの原因調査と修正を行い、 パッチをCD-Rに焼いて配布する。 という障害対応を行っていました。 各パッケージの利用社数は数万〜10数万社に上りますので、大変な騒ぎでした。 そして事後に、障害の再発防止策を検討し報告する義務が課されるわけです。 メカニズム 仕組みとして、障害原因を封じ込める対

再発防止策を書くのは難しい。 良い再発防止策 良い再発防止策について、順位付けするとしたら、 その種類の問題について二度と意識することがなくなる解決策 その種類の問題を開発時に自動的に検知することができる解決策 その種類の問題が発生しても自動的に復旧することができる解決策 その種類の問題が発生しても影響が局所化される、フールプルーフ、フェールセーフになる解決策 と言うのは意識したいと思いつつ、やはり難しい。 再発防止はむずかしい 障害の再発防止策は、 メカニズム ツール ルール チェックリスト の順番に検討せよ。と言われても、急いで書けなんて言われると「次回からは複数人でチェックします。」とか「チェック項目を追加します。」とかいう徹底できなそうな「反省文」になってしまう。 まさにこの有名な猫...。 **「なぜミスを繰り返すのか」「どうすればミスを防げるのか」を真剣に考えていないことがミス

昨日、上野宣（@sen_u）さんがパスワードの総当りに要する時間の表をツイートされ、話題になっています。 総当たり攻撃時のパスワード最大解読時間の表を日本語化した。https://t.co/cVSNUZkAKv pic.twitter.com/rtS8ixwOqi — Sen UENO (@sen_u) August 17, 2021 1万件を超えるリツイートがありますね。大変よく読まれているようです。しかし、この表は何を計測したものでしょうか。上野さんにうかがってもわからないようでした。 何ですかね？パスワード空間が大きくなると解読に時間が掛かるということくらいがわかりますかね。 — Sen UENO (@sen_u) August 17, 2021 一般に、パスワードの総当たり攻撃（ブルートフォースアタック）というと、以下の二通りが考えられます。 ウェブサイト等でパスワードを順番に試す

こんにちは、Barry（ばりゅー）と申します。 いきなりですが言わせてください。 このサービスは今読んでいるあなたのために作ったサービスです！ はじめに リモートワークが当たり前になった今、みなさんはどんなデスクで作業してますか？ 「もっと快適にしたい。」「もっとオシャレにしたい。」 デスクワーカーなら一度、いや、二度三度思ったことがあると思います。 そんなとき、他人のデスクが参考になったりしますよね。 そこでこんなサービスを開発しました。 どんなサービス？ デスク周りに特化した写真投稿サービス「Buildesk（ビルデスク）」です。 【サービスURL】https://buildesk.app 【GitHub】https://github.com/en-Barry/buildesk Buildeskの一番の特徴は、使ってるアイテムも登録できること。投稿者がどんなアイテムを使っているのか瞬時

④git pull -r ブランチを最新化する。 ※git pullとの違いについてはこの記事の最後にまとめています。

はじめに どんな仕事でも強い人は存在する。 でも最初から強い人は珍しい。 これは、web 業界に身を置いてみて、信じられないくらいムキムキになっていった人たちを見てきた私が送る こうしたら強くなれるかもしれない？指南書である。もしエンジニア職に興味があるのであれば、一考になるかもしれない。 最初から強いやつの特徴 平日の稼働時間以外も勉強 or 開発する 土日も勉強 or 開発する 公式ドキュメントをちゃんと読む 以上のような当たり前のことは、最初から強い人じゃなくてもやるので特徴に入れません。 1. 読解能力が異常に高い 国語の力です。 これは、ちゃんとドキュメントに書いてあることが理解できると同義です。 そしてこれが本当に大事です。 強い人に質問すると必ず「ん？ Docs 読んだ？」って聞いてきます。私は (...読んだわ！) って内心思ってますが、それは読んだだけです。内容をちゃんと

WebAssembly で画像のリサイズ処理をやってみたら JavaScript + Canvas API より遅かった話JavaScriptRustOpenCVTypeScriptWebAssembly WebAssembly(WASM) は JavaScript より計算処理が速いという話題がしばしば聞かれます。 では、単純な数値計算ではないけれど、JavaScript を利用した通常のフロントエンド開発だと時間がかかる処理を移植するとどうなるのでしょうか1。本記事ではその一例として、巨大画像（4K～）を指定したピクセル数までリサイズする処理を書いてみました。 リポジトリ: https://github.com/yokra9/wasm-image-resizer JavaScript + Canvas API でリサイズしてみる まず、比較のため JavaScript でリサイズ処理を

CRUDのWebApi開発は不要！JsonでWebApiを作れるシステム「versatileapi」を作った話JavaMongoDBWebAPIRESTfulversatileapi はじめに タイトルの通りです 定義を設定するだけで、CRUDのRESTWebapiを作れるシステムです 似たようなもので、FirebaseのRealtimeDatabaseやFireStoreがありますが 色々と制限が多く、バリデーションが難しいようだったので作ってみました Java(Spring Boot)とMongoDBで作りました ここで使ったシステムです エンジニア・プログラマにしか使えないSNSを作ってみた話 2020/07/20 ソースコード公開 https://github.com/HawkClaws/versatileapi フロー図 フロー詳細 WebApi定義を登録 管理者用WebApiを

はじめに PowerDNSを用いて、物理的、地理的に冗長化(※)された権威DNSサーバの構築例を紹介します。本稿では「さくらのクラウド」上に構築していますが、同等の構成をとれる環境では同じ設定が可能かと思います。 PowerDNS自体の説明は、Wikipediaやその他わかりやすいサイトや資料が多数あるため、本稿では割愛しますが、 権威DNSサーバとして動作する PowerDNS Authoritative Server DNSキャッシュサーバとして動作する PowerDNS Recursor の2種類があります。ここでは権威サーバとして使用するため前者を導入します。 ところで、冗長化したからといって必ずしも高可用性を実現できるわけではありません。冗長化はその必要条件にすぎないからです。ことDNSの可用性については、DDoS対策、オペレーション、バックアップ体制など、他にも重要な要素が多々

はじめに 通常のSNSで胡散臭い人が多いと感じてしまいました プログラミングスクールが流行り、エンジニアになって億稼いでます！みたいな・・・ そこで、本当のエンジニア・プログラマしか使えないSNSを作ってみました！ つまり、WebApi提供のみのSNSです 一般ピープルが使うようなフロントエンドなんてありません！！ Postmanなり、なんなりを使って叩いてください エンジニア・プログラマしかWebApiが叩けないであろうという考えなので、 エンジニア・プログラマにしか使えないSNS！ということです この記事を見ている、プログラマ・エンジニアの方であれば使えますよね？😁 実際、WebApiが叩くことが出来れば誰でも使えてしまうわけですが・・・。 2021/07/20 更新 このWebApiを作ったシステムについて書きました ソースコード公開しました CRUDのWebApi開発は不要！Js

何があったか はてなブックマークは、コメント表示改善の一環として、Yahoo! JAPANの「建設的コメント順位付けモデルAPI」を導入し、攻撃的であったり不謹慎であるなど穏当でないコメントが人気コメントに掲載される問題を抑制する取り組みを開始しました。 実は、公式の発表が知れ渡る前にAnonymousDiaryというサービスで話題になり、喧喧囂囂の大騒ぎとなったのです。 誉れ高い増田市民としては、旧来の破滅的コメント順位を望みます。 Pythonによる解決 googleのcolabで作業してました。 記事の情報をAPIで入手 記事jsonからブクマした各ユーザの「コメント情報のURI」を生成する スター取得APIでコメントURIを指定し、スター数を算出 各コメントのスター数を出し、上位10個を表示 後述するjsonの概要を見るとイメージがつきやすいかもしれません。 import json

はじめに 先日、新入社員の方から次のような相談を受けました。 「エンジニアの方に質問をすると、いつもイライラされてしまって辛いです」 ・・・・・・・・・ 確かに、エンジニアに限らず、質問をすることは非常に難しい… 質問の仕方を間違えたために相手を怒らせてしまった、なんてこともしばしばあることでしょう。 彼らは「教えるプロ」ではなく、ただの技術者です。 そのため、問題の解決には、質問力(コミュニケーション能力)が欠かせません。 そこで、新入社員の子には質問の仕方を教えようと思ったのですが… 僕「質問の内容・構成は悪くないぞ」 ※ここでは、あえて「良い質問」、「悪い質問」の違いには触れないようにします。 ※その手の話題はみんなすでに飽き飽きしているからです。 そう、質問の仕方は問題なかったのです。 しかし… 要所に気になる文言がいくつかありました。 -- 本記事ではうちの新入社員に限らず、プロ

はじめに The Bezos Mandateという文書があります。日本語に訳すと「ベゾスのお達し」とか「ベゾスの勅令」でしょうか。 言わずと知れたAmazon.comのCEO、ジェフ・ベゾスが開発チームに通達した内容です。 これが（元Amazon.com従業員によって）公開されたのは2011年ですが、ベゾスがこのお達しを出したのは2002年前後です。17年経過した現在でも真理をついているどころかようやく時代がベゾスに追いついたかという感想です。 この記事ではThe Bezos Mandateの紹介と、僭越ながら補足説明も行います。 お達しの内容 原文は元Amazon.com従業員のGoogleエンジニア（公開当時）、Steve Yeggeによって公開されました。 Google+にStevey's Google Platforms Rantというタイトルで、Amazon.comと比べたGoo

GitHubにAPIのキーが書かれたファイルを上げてしまったので、対処の流れを書き残しておきます。 BFGを使用する方法とfilter-branchを使用する方法があるのですが、今回は後者をやってみました。 注意 外部にキーやパスワードなどを公開してしまった事に気づいたら、まずは対象のサービスを停止させて再発行を行ってください。その後、履歴を確認し悪用された形跡が残っていないか確認してから以下の手続きを行ってください。 対処するときプルリクがあるかどうかを確認して、ある場合にはすべてマージもしくはクローズしてから行うのを推奨しています。 自分のケースでは幸い1件もなかったので、そのまま行っています。 手順 1. ローカルにリポジトリをクローンする

先日、誰でも最短1分でYouTubeの切り抜きを作れるウェブサービスを公開しました。(※追記：22年7月にサービスを閉鎖しました) 私はプログラミングの勉強を始めて1年半の初学者ですが、個人開発でサービスを公開するまでに、数多くの失敗と苦労をしてきました(そして今もしてます笑)。後ほど詳しく書きますが、以下のような経験をしました。 ハッキングを受けデータを盗まれる α版をリリースするも作り直しを決意する 巻き返しのため海外フリーランサーを雇うも無駄金となる 公開前に本家が同じ機能を発表し諦めかける β版をリリースするも使われない 同じようにプログラミングの勉強をし始めたばかりの方や、個人開発でいつかはサービスを公開したいと考えている方の「転ばぬ先の杖」として、私の経験が役に立てばと思っております。 開発したサービス YouTubeの公式APIを利用してウェブ上で切り抜きを作成・紹介できるウ

これは何 の参加記事です。 エンジニアとして開発をしていく以上、設計についての知識を身につけていくことはとても重要です。 とはいえ設計という言葉からは何を勉強するべきかがいまいちピンときません。 この記事では、僕が読んできた設計に関するおすすめの本を網羅的に紹介しています。 これから設計を勉強する方の役に立てれば幸いです。 おすすめの本一覧 おすすめの本を紹介していきます。 他にもおすすめがあればぜひ編集リクエストをください！ オブジェクト指向設計実践ガイド 設計を始めに学ぶならこれ、という一冊です。 エンジニアとして開発を行なっている中で、オブジェクト指向設計は一番汎用的に使う設計知識なのではないでしょうか？ オブジェクト指向設計を学ぶことで、いわゆる「におう実装」と「良い実装」を見極めることができるようになると思います。 知らなかったら読んだほうが良いキーワード SOLID原則 Cle

1. はじめに 私のチームは2019年までは、同じフロアでチーム4人が集まって、ペアプログラミング/モブプログラミング中心で開発し、チームで情報を共有しながらお互いに助言し合って開発していました。 アジャイル開発のチームとして、わりと良い感じにコミュニケーションを取りながら開発できていたと思います。 しかし2020年に、コロナの影響で、突然チーム全員がリモートワークに変わり、それは崩壊しました。 チーム全員がリモートワークの初心者のため、リモートワーク初日は大変な事になりました。 今まで同じフロアで気軽に声をかけあっていましたが、それができなくなり、初日は「楽しくない」開発でした。 翌朝に、皆で初日の感想を話し合った結果、全員が疲労感と孤独感を感じており、今までの楽しかった開発が、一変してしまいました。 こんな状態で、この先、リモートワークを続けていけるのか、皆、とても不安を感じていました

Firefox / Safari MozillaはMozilla Specification Positionsというリストを公開しています。 IETFやW3C、TC39などが提唱しているWeb技術に対して、Mozillaはどのように評価しているかという立ち位置を表明したものです。 あくまで現時点での評価であり、もちろん今後の仕様変更などに伴い評価は変わる可能性があります。 Mozilla's Positions Mozillaはどのように評価しているかの分類。 under consideration 評価の検討中。 important 優れた概念であり、Mozillaにとっても重要である。 worth prototyping 優れた概念であるが、プロトタイプを作成し、フィードバックを得て磨きをかける必要がある。 non-harmful 有害ではないが、良いアプローチではなく、取り組む価値

はじめに どんなソフトウェアエンジニアも拡張しやすくメンテナンスしやすいソフトウェアを作りたいと思っているはずです。また、どんなプロダクトマネージャも同様に拡張しやすいシンプルな要求を作りたいと考えているはずです。 しかし、将来の不確実性や発展性に対して見通しを立てるのは難しいものです。そのため、開発チームの思いとは裏腹にソフトウェアの複雑性はどんどんと増大していきます。気がついたら技術的負債と呼ばれるような手もつけられない泥団子になってしまうということもしばしばです。誰もが生産性を下げるために機能を追加したいわけではなく、ビジネス価値を提供するために機能を追加したいだけなのにです。 このような状況を避けるためにはどうしたらよいのでしょうか。今回はその一つの手段として、要求には隠れた「意図」があり、それを発見していくことの重要性についてまずはお話しします。さらにわかりやすい要求が持つ仕様の