はじめに 今携わっているプロジェクトで凄腕エンジニアさんと一緒に開発をさせていただいているのですが、その凄腕エンジニアさんから教えていただいた例外の話がとても勉強になり、 さらにこの例外の話を他のプロジェクトのエンジニアさんに伝えたところ、反応が良く、とても勉強になりました！という声をいただけたので、アウトプットしていきたいと思います。 （この記事の中で凄腕エンジニアさんのことはTさんと呼ぶことにします。） ※【凄腕エンジニアさんから学んだ例外の話】の補足 というQiita記事を書きました。 この記事を読み終わった後に疑問が残った人などは補足資料として読んでいただけると嬉しいです。 例外の考え方の源 Tさんの例外の考え方は http://diveintopython3-ja.rdy.jp/your-first-python-program.html#exceptions ↑こちらのPyth
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 目次 はじめに 個人を特定する情報が個人情報じゃない デジタル署名は暗号化しない TLS(SSL) は共通鍵を公開鍵で暗号化しない TLS(SSL) が使われていれば安全じゃない 変数は箱じゃない Python 等は「ソースコードを 1 行ずつ実行するインタプリタ方式」じゃない 日本語 1 文字は 2 バイトじゃない 動画が動いて見えるのは残像によるものじゃない 標本化定理は「2 倍以上の周波数」じゃない その他いろいろ はじめに 2022 年から高等学校で、プログラミング等を学ぶ「情報Ⅰ」が 必修 必履修科目になりました。1 さらには
はじめに シェルスクリプトで二重起動防止やロックをする方法を検索すると、いろいろな方法や書き方が見つかりますが、どれを使えばよいのか、本当に正しく動くのか、不安になりますよね？ ディレクトリ (mkdir) やシンボリックリンク (ln) を使った独自実装の例も見かけますが、エラー発生時や予期せぬ電源断、CTRL+C で止めたときなどでも問題は発生しないのでしょうか？ まず、ディレクトリやシンボリックリンクを使った独自実装はしない。これを肝に銘じてください。シェルスクリプトでのロック管理はとても難しく、一般的な排他制御の知識に加えて、シェルスクリプト特有の問題、シグナルやトラップ、サブシェルや子プロセスの問題、さらには特定のシェル固有の仕様やバグなどさまざまな問題に対処する必要があり大変です。独自実装の例では古いロックファイルが残ってしまい、それをいつどのタイミングで片付ければ安全なのか？
こんにちは、製造業でソフト開発エンジニアをやっているとみー(@tommyecguitar)です。 会社で納品物の説明ドキュメントを作ることがあり、その時にMarkdownでの組版をやってみたので、どう運用したか、困ったところ、いい点、悪い点をまとめてみようと思います。 Vivliostyleで組版したブログはたくさんあるので、見た目がどんな感じにできるかなどはそちらを見ていただくか、Vivliostyleのサイトをご覧ください。 Wordじゃだめなのか。 製造業で何かしら長大なドキュメントを作るとなったら、大抵はWordを複数人数で編集するという運用をしているところが多いと思います。 しかし、Wordにはいろいろと悪いところがあります。 チーム内で共同編集すると、編集したところが消えたり、フォントやデザインがなぜか統一されなかったりする。 セクションごとに担当を分けても、マージが手作業にな
表示されたプロセス一覧の中からCPU負荷を極端に使用しているプロセスを探したところありました。 「/tmp/kinsing」 「/tmp/kdevtmpfsi」 この2つのプロセスがCPU負荷300%を超えていました。 kinsing(kdevtmpfsi)マルウェア このDockerマルウェアは感染したDockerホストで仮想通貨をマイニングしてCPU負荷を掛ける仮想通貨マイニングマルウェアです。ここではマルウェア自体の機能と解析の解説は記述しません。 詳しくは以下のリンク先を参考にしてください。 脅威：コンテナ環境を対象としたマルウェア「Kinsing」が増加中 #AquaSecurity #セキュリティ #コンテナ #マルウェア コンテナを標的にしたマルウェア、Aqua Security Softwareが攻撃手法を解説 感染経路 誤って外部公開されたDocker APIが主な感染経
主に2つの答えがあります。 A. WCAGの考えではユーザーが適切な支援技術を利用することも含めてアクセシビリティであり、支援技術の入手やアクセシビリティ機能の利用に必要なITリテラシーを持たない人はアクセシビリティの対象ではない。（WCAG偏重派） B. うるせえ！！ なるべく多様な人に情報を届ける、それがおもてなしの心ってヤツだろうが！！（アクセシビリティはみんなの心にあるよ派） 筆者には、Aのようにアクセシビリティの範疇からITリテラシーを外すのはやや極端な考え方であるように思えます。しかし、アクセシビリティに詳しい方でもAのような考え方をしているのを見かけます。 この記事では、WCAGやその関連文書を読みながら、この問いについて考察していきます。 今回WCAGとして参照するのはWeb Content Accessibility Guidelines (WCAG) 2.1です。この記
Gitのワークフローについては自転車置き場の議論になりがちであまり乗り気がしないのですが、最近少し発見があったのと、実際に多くの現場で明らかにフィットしないのに git-flow を検討したり採用したりしようとして苦労をしている様を目撃することが多いので書くことにしました。 この記事で主張する内容はタイトルの通りですが、まず前提として以下を宣言しておきます: 全てのケースに100%フィットするようなワークフローは存在しない git-flowがフィットするケースも探せばあるかもしれない 例えばすでに何年もgit-flowでうまく回せてるよ、など どのようなワークフローを採用するかは最終的にはあなた（のチーム）が判断すべき さて、 git-flow は 2010年1月「A successful Git branching model」というブログポストによってバズり、以来多くの人が参考にしてき
[いわゆる退職エントリ] Microsoft を辞めることにしました（あるいはサポートエンジニア → Product Marketing Manager になるまでなど）退職エントリ 皆さんごきげんよう。ういこうと申します。 これまで日本マイクロソフト株式会社で Azure のフロントエンド領域を中心としたサービスの Product Marketing Manager をしておりましたが、6/30 日をもって退職することとなりました。 きっと Microsoft 界隈以外では、あなたどなた？という感じだと思いますので、少し自己紹介と、退職エントリ（のようなもの）を書くことにした理由を紹介させてください。ちょっと、いや...かな～り長いので、おやつでも食べながら読むものがないなーというときや、今エンジニアなんだけど、マーケティングなど、テクニカル ロール外の職種に転換しようと思ってる、あるい
![[いわゆる退職エントリ] Microsoft を辞めることにしました（あるいはサポートエンジニア → Product Marketing Manager になるまでなど） - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/bc81715cecfdae25ce86937791cb887e21778600/height=288;version=1;width=512/https%3A%2F%2Ffanyv88.com%3A443%2Fhttps%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCJUUzJTgxJTg0JUUzJTgyJThGJUUzJTgyJTg2JUUzJTgyJThCJUU5JTgwJTgwJUU4JTgxJUI3JUUzJTgyJUE4JUUzJTgzJUIzJUUzJTgzJTg4JUUzJTgzJUFBJTVEJTIwTWljcm9zb2Z0JTIwJUUzJTgyJTkyJUU4JUJFJTlFJUUzJTgyJTgxJUUzJTgyJThCJUUzJTgxJTkzJUUzJTgxJUE4JUUzJTgxJUFCJUUzJTgxJTk3JUUzJTgxJUJFJUUzJTgxJTk3JUUzJTgxJTlGJUVGJUJDJTg4JUUzJTgxJTgyJUUzJTgyJThCJUUzJTgxJTg0JUUzJTgxJUFGJUUzJTgyJUI1JUUzJTgzJTlEJUUzJTgzJUJDJUUzJTgzJTg4JUUzJTgyJUE4JUUzJTgzJUIzJUUzJTgyJUI4JUUzJTgzJThCJUUzJTgyJUEyJTIwJUUyJTg2JTkyJTIwUHJvZHVjdCUyME1hcmtlJUUyJTgwJUE2JnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz00ODU2YTNjNjM3NjI0ZTkwZTcxMzcxN2FjOTBhNTYzOA%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDB1aWtvdSZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9MDAyMDkxYmJhMGU4MzM4ODkxOTkyOTBhYjNmZGE2MWI%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3Db4afdd848b8c2478ef90e07d4b10533a)
自身のプライオリティによりますが、いくつか。 Markdownで幅広く再利用性を利かせたい、長期的に丁寧に版管理したい 自分自身の操作性、描きやすさと、見た目 俄然手軽に、短期的に、Onlineでいつでもどこでも いずれかという視点で考えると良いのかなと思い、並べてみました。 1. 長期的に: Markdownで幅広く再利用性を利かせたい、丁寧に版管理したいなら Markdownで描くことのメリットは再利用性。 将来的に追記・編集、自分以外の誰かが手を入れる可能性が高い。 現在のドキュメントだけでなく多種説明資料、媒体に転用する可能性がある。 ...という点で差分管理をしたいなら、以下。 VSCodeでPlantUML、Mermaid 上記参考で以下。 Alt+D でプレビュー起動。 Ctrl + Shift + P でコマンドパレットを起動し、出力。 png, svg, eps, pdf
何を言っているんだと思われるかもしれないですが、気軽にパスワードの1文字目に「~」を使わないほうがいいというお話です。 起こった問題 踏み台サーバー経由でサーバーAに接続して作業をしていた時の話です。 いわゆる多段 ssh 接続というもので、リモートワークになってからは結構使われる方も多いかと思います。 サーバーA上で root 権限になろうと sudo su - してパスワードを入力したら Connection to xxx.xxx.yyy.zzz closed. の文字とともにサーバーAから追い出されてしまいました。 なにかの間違いだろうと何度か挑戦していたのですが、結果はサーバーAから切断され踏み台サーバーに戻る羽目に。。。 そのときに入力していたパスワードが ~.xxxxxxxxxx のような ~ から始まるものでした。 調査 ~ って何か意味があったよなーと思ってどう調べようかと
悲劇は起こった… ある日のLINE A氏「IPアドレスについて教えて欲しい！」 B氏「IPアドレスっていうのは xxx.xxx.xxx.xxx っていうフォーマットの…」 A氏「このリンクなに？」ﾎﾟﾁｰ ＼ﾌﾜｰｵ♡／ B氏（YABE） 何が起こったのか LINE や Twitter などの SNS は投稿されたリンクを自動的に飛べるようにしてくれます。 今回不幸なことに、この .xxx というドメインは存在し、xxx.xxx というドメインは登録されていました。 参考： ドメイン (domain)とは |「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典 ドメイン名の種類 JPNIC そして .xxx ドメインの用途はよりによって… 用途 登録対象 > アダルトエンタテイメント業界用 < >> アダルトエンタテイメント業界用 << >>> アダルトエンタテイメント業界
はじめに 本稿は、日経クロステックにて筆者が昨年連載していた3回分の記事一部変更して1つにまとめたものです。 https://xtech.nikkei.com/atcl/nxt/column/18/01394/ 有料記事として配信されておりますが、無料でも閲覧できるようにということで日経クロステック様に許可を得てQiitaにも掲載しています。 第1回：技術的負債はなぜ生じるか。 第2回：ソフトウエア開発を「制御」する意外な処方箋 第3回：技術的負債への取り組みはなぜ「２つのDX」につながるのか。 第1回：技術的負債はなぜ生じるか。 年間12兆円ものマイナスの影響をもたらす技術的負債（あるいはレガシーシステム）はどのように生まれるのでしょうか。それを防ぐ方法はあるのでしょうか。第1回は、技術的負債をとりまく歴史をたどりながら、ソフトウェアエンジニアではない人にも理解できるようにその正体に迫り
「正直９年経ったいまでもfor文ググってる」 という議論記事があった。正直なところ私もググる方の人だ。私の感想: ポンとテキストエディタだけ渡された時に書けるか自信ないぞ...IDEがあればまあ大丈夫かなあ。 JavaScriptだけじゃない。言語色々扱うしという言い訳。正規表現とか毎度調べる。 だから世の中にチートシートというものがあるのだ。お気に入りチートシート多数。 実戦でどうしているか？結局周りのソースを見て馴染む書き方にしていますよ多分。 暗記するかしないかは受験勉強みたいなもので、コーディング面接に受かるなら必要。暗記そのものには意味はないとは思う。 競技プログラミングが使えないとかいう論もあったな。 ググり力も大事。 でも「最低限」もできないのはやはり恥ずかしい気持ちはある。 なんかこれ英語できるできないと似てるな。英語なんてGoogle翻訳、DeepL翻訳あればいいけど、実
オリジナルの TeX が誕生してから40年以上の歳月が流れ，そして日本語 LaTeX が現在主流の姿 (pLaTeX2e) になってからも25年以上が経過しました．この間 LaTeX は多くの人に使われ続けて来ましたが，その歴史の中でさまざまな変遷を辿り，明示的なドキュメントにはなっていないながらも，ユーザ間ではある意味「常識」として定着した知識が積み重なってきました． 歴史が長く，よくも悪くも「安定している」と評されるために見過ごされているかもしれませんが，日本語 LaTeX は今も開発が続く「生きた」ソフトウェアです．そのため歴史の中で培われた常識的な知識が古くなり，新しい知識が必要になる場合があります．そしてその傾向は特にこの数年顕著で，TeX コミュニティに属する人々が多く集まる TeXConf などの会議で，主に中上級者向けに新しい知識が啓蒙されてきました．本稿では，そのような日
#include <stdio.h> void fizzbuzz(int n) { int next; int i = 1; do { printf(i % 15 ? i % 5 ? i % 3 ? "%d\n" : "Fizz\n" : "Buzz\n" : "FizzBuzz\n", i); if (i++ >= n) next = 0; } while (next); } int main(void) { printf((char[]){""}); // この位置にprintfが無いとなぜか動かない fizzbuzz(100); } gcc 10.1.0 を使用し、コンパイラが感知したミスには警告を出力してくれる様 -Wall -Wextra を指定し、最適化指示なしでコンパイル、動作させたところ動作するが Wandboxで実行 main() の中の何も出力していない printf(
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? みなさんは GitHub でオープソースソフトウェア(OSS)を開発して公開する時、README をどのように書いているでしょうか？ GitHub が自動で作ってくれる README に含まれるのはタイトルだけですし、OSS 開発初心者の場合、そもそも README に何を含めるべきかわからないという方もいらっしゃるのではないでしょうか？OSS 開発に慣れている方でも、コードを書くのはいいけれど README を書くのは面倒だと思ったことはありませんか？今回はそんな README 難民の方々向けの Web サービスを作ってみました。 L
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 私は、不完全な人間です。 人より劣っているところ、弱みもたくさんあります。 しかしながら、なんとか、今日までエンジニアとして生きていくことができました。 私がこれまで、劣等感とどう折り合いをつけてエンジニアとして生きてきたか、説明したいと思います。 この記事で最も言いたいことは**「不完全な自分を認めながら、でも、自分の成長の可能性を失わない」**ということを伝えたいです。 劣等感にまみれたエンジニア人生 ふりかえると、劣等感にまみれたエンジニア人生でした。 「自分はダメなエンジニアなんだ…」 という想いが、思考の隅につきまと
皆さんは Web ページのスクレイピングって書いた事ありますか？私はあります。だってどんなに平和で平穏な生活を送っていても数年に一度はスクレイピングってしたくなりますよね。「うわーまじか！API ないのかよ…。」的な。 そうしたら HTTP クライアントと HTML パーサのライブラリを探してきてインストールした上でごりごり書くことになると思います。でも実際に書いてみると、そうやってライブラリのインストールをしたりサンプルコードで動作確認している時間よりも、HTML を解析して実際にパースしたところから対象の要素を取得して欲しい値を取り出す試行錯誤の時間の方が長かったっていう事はないですか？ 今日ご紹介する Node.js でお手軽スクレイピングは、その辺の試行錯誤の手間を極力減らすことが出来る方法です。2020 年夏の最新版です。 まずは環境から。特に古いものを使う理由もないので 202
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
