職場でもよく話題になるけど、今の20代以下の子に濃厚にある「失敗したくない」というもはや執念とさえ言える感情の出どころって、何かあればLINEやネットでボッコボコに隣の誰かにぶっ叩かれるのを見て育ってるからなのはほぼ間違いないようなので、その辺から解さないと難しいかなとも思う。

What are the biggest delusions that computer science students have? というQuoraの質問にあった画像。 ...を出オチのようなところに、Life of a Programmer in Simple Jokes That Will Make You Laugh (プログラマジョーク集) およびそのリンクから集めてしまったジョーク、meme等です。 趣旨 基礎的なプログラミングと英語の知識がある人がクスッとできるかもしれない meme です。プログラミング知識は増えません。自分の英語やエンジニアリングの知識をテストする程度ですが、息抜きに。 meme (ミーム) とは、ネタの意味が分かるとクスッとしてしまう画像のこと。 海外で通用するエンジニアがクスッとしてしまう17の meme 、エンジニア向けMeme　も過去記事参考です

REST API の呼び出し結果を、集中的に何度も使いたいような場合、API のレスポンスをキャッシュするのではなく、Promise をキャッシュすることで、API が 1 回だけ呼ばれることを保証できます。 何もキャッシュしない場合 まず最初に、何もキャッシュしない場合を見てみます。 import axios from 'axios' class App { /** * API に GET リクエストを送信するメソッド。何もキャッシュしないバージョンです。 */ async request(url) { return await axios.get(url) } /** * API を使ってなにかするメソッドです。 */ async doSomethingWithAPI(url, index) { const result = await this.request(url) consol

はじめに Qiitaで新人プログラマ応援企画があるということで，自分の経験をもとに学生時代のプログラミングと仕事上でのプログラミングの違いを書いてみることにしました。 私自身はの今までの経験は，以下のような感じです。 - 10年近く商用ソフトウェアの開発を経験 - アプリケーションではなくその基盤となるミドルウェアの開発が中心 - 使用してきた言語はC/Javaなどが多い（最近はRuby/Python/JavaScriptなども。。。） わたしの主観による内容ですので，「いやいや違うよ！」とか「本当かなあ？？」と思われるところもあるかと思いますが，「こういう考え方もあるのね！」と思っていただければ幸いです。

これはなに？ 社内ネットワークで問題が起こった時に、私が調査する観点を書き出してみた。 各組織、各人のやり方はあると思いますが、何かの参考になれば。 #無線に明るくないため、無線は割愛 調査概要 レイヤー L1 -> L3(L4) -> L2 -> L7 の順番で見る。 何はなくとも物理層。障害の大半はここ。 次いで IPアドレス周りやフィルタ。 各レイヤーで見ることは後半で。 切り分け観点 問題が起こっているのは一人か？複数か？ 複数の場合どの単位か？島、セグメント、など。 問題は一時的？常時？ 一時的なら何と相関するか？トラフィック量、日時、など。 今まで使えていたのか？新たに使おうとしてだめなのか？ 物理障害？論理障害？ どこまで疎通できるのか？ デフォルトゲートウェイ(デフォゲ)？ISPのルータ？8.8.8.8？ 調査に使う代表的なコマンド/ツール ifconfig ipconfi

はじめに 私は十年近く前、レビューで大量の指摘を登録することが何度かありました。 当然、大量の指摘修正をしてもらうという行為は、手戻りであり、それだけプロジェクトの進捗を遅らせることになりました。 とても恥ずかしい話ですが、当時の私は、レビューで大量の指摘で手戻る原因が、レビューイにあると思い込んでいました(本当にごめんなさい)。 しかし、今、振り返ってみると、手戻りの原因はレビューアである私にあったと思います。 そのような恥ずかしい自分の行動を戒めるために、どれだけ当時の自分が残念だったのかを紹介します。 要するに反省文のようなものです。 今回対象とするレビューの前提条件 今回紹介するレビューは、以下の条件を満たすものでした。 レビュー対象の成果物は、以下のいずれか。 外部仕様書 設計書 テスト仕様書 ソースコード レビューイは、レビュー対象成果物を作成した経験が浅い(数回の経験)。 レ

より良いものをより早く作るのに役立つ、あまり知られていないリポジトリ。 Photo by Juan Rumimpunu on Unsplash はじめに 私たちは、汎用ツールやリソースが数回タップするだけで手に入る時代に生きています。しかも幸いなことに、そのほとんどが無料です。 新しいツールやより簡単な方法が見つかり、面倒で複雑なタスクを実行できれば、誰にとっても、特に開発者には嬉しいことです。 でも、より良く賢い方法があり、予想外の方法で時間を節約できることを知らない場合もあります。 この2年間で見つけたGitHubの素晴らしいリソースは、私をかなり助けてくれました。これらのうちいくつかは、その必要性さえ知りませんでした。 そこで、あなたもおそらく必要になるGitHubリポジトリのリストを作りました。 1. 33 JS concepts ソース 私はプログラミングをJavaで始め、その後

新しい記事もよろしくやで！ 5歳娘「パパのReact、めっちゃ遅いね！」 とある平日 娘（5歳）「パパ、今日は何のお仕事してるの？」 ワイ「おお、娘ちゃん」 ワイ「今日はな、ショッピングサイトを作ってんのや」 今日のお仕事内容 ワイ「↓このデザインの通りに、コーディングをせなあかんのや」 娘「なるほどー」 娘「このショッピングサイトで商品を売りたい！っていうお店があったとして」 娘「そのお店の人が、最初にお店の情報を登録するためのページだね！」 ワイ「せやせや」 まずはデザインを眺めてみる ワイ「この店舗登録ページにはなぁ」 ワイ「↑こんな感じの」 ワイ「項目名と入力欄がセットになったパーツが何度も登場するから」 ワイ「そのためのコンポーネントを作ろうかなー、って」 ワイ「そう思ってたとこなんや」 娘「ふーん」 娘「ラベル付きテキストフィールド的なコンポーネントってことだね」 娘「どこまで

水道修理業者、ぼったくりの業者もあるのでどこに頼めばいいか全然わからない。「たのしい水道やさんドットコム」みたいなテンションのホームページが続々出てくる。Googleマップでレビューを見ると便座取り外しで25万円請求される最悪の業者、とかいろいろ書かれている。 指定工事事業者から選定しようかと思ったけど、順番に電話をかけたり、いつ来てもらえますか、とかもめんどうなので、レキシの土器の歌に登場することで認知していたクラシアンに電話して来てもらった。当日直してもらえて、最初からこうしたら良かった…。 追記 管理会社に連絡したところ、自分らで手配して直して、かかった費用は建て替えて後日請求してください、という投げやり管理会社で、自分たちでなんとかしたのだった。管理会社が仕事してくれたことは基本的になくて、部屋のオーナーに伝言してくれているだけのように見える。エアコンも買ってくれなくて、ここ一年で

重要な追記 sparse checkout して、git diff で判定、というのがこの記事の主な趣旨だけど、自分が on.push.paths の存在を知らなくて、これを使うと、次のように sparse checkout するだけでよかった。 # .github/workflows/foo-test.yaml name: foo-test on: push: paths: systems/foo/** env: SPARSE_CHECKOUT_DIR: systems/foo jobs: test: runs-on: Ubuntu-20.04 steps: - name: sparse checkout run: | git clone --filter=blob:none --no-checkout --depth 1 --sparse https://${GITHUB_ACTOR}

express-router-dependency-graphという、ソースコードを静的解析してexpressのルーティングと使ってるmiddlewareの一覧を出してくれるツールを書きました。 azu/express-router-dependency-graph: A static code analysis tool that creates a dependency graph for express routing. 次のように globでexpressを含むソースコードを指定することで、 そのディレクトリ以下にあるソースコードからexpressのuse,get,post,delete,putなどでのルーティングの一覧を作成します。 [ { filePath: "<root>/src/game.ts", routers: [ { method: "get", path: "/ge

Intro Public Suffix List (PSL) は、現在の Web プラットフォームの一端を支えている非常に重要な要素だ。 実はこれが、少数のボランティアにより GitHub でメンテナンスされた、単なるテキストリストであることは、あまり知られていないかもしれない。 最近、このリストへの追加リクエストがあとを絶たず、問題になっている。 そもそも PSL とは何であり、今どのような問題が起こっているのかについて解説する。 Public Suffix List とは何か PSL を解説するには、まず関連する用語について整理する。 Top Level Domain (TLD) 例えば、このブログのドメインは blog.jxck.io であり、これは筆者が取得したドメイン jxck.io のサブドメインだ。 jxck.io は、 .io という TLD のサブドメインを販売しているレ

ビル・ゲイツによる、地球温暖化対策についての本です。邦訳も夏頃に出るらしい。教科書のように整理してまとまっているので、現状と今後を知るのに便利です。特に大切と思われる項目をメモします。 現在世界中で人類は 510 億トンのグリーンハウスガス(温室効果ガス)を排出している。 温室効果ガスにはメタンのように二酸化炭素の 120 倍も温室効果が高い物もあるので、二酸化炭素に換算した数値を排出量とみなす。 目標は、先進国が 2050 年までに温室効果ガスの放出を実質ゼロにして、発展途上国もそれに続く事。 グリーンプレミアム (温室効果割増金) ある製品やサービスについて、温室効果ガス放出ゼロを達成するために追加で必要な費用の割合。 この本の中核となるアイデアで、目標達成までの困難度を測る指標。 例えばジェット機の燃料として、石油で作った普通の燃料の代わりに温室効果を排出しないバイオ燃料を使うと燃料

If you landed on this blog, you’ve probably seen our announcement for GUI applications support in the Windows Subsystem for Linux being available to Windows Insiders and looking for more details on how WSLg was built. If so, you’ve come to the right place! 情報源: WSLg Architecture | Windows Command Line 雑に翻訳。 このブログにたどり着いた方は、Windows Insidersに提供されるWindows Subsystem for LinuxのGUIアプリケーションのサポートについての発表をご覧

概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: The Citadel Architecture at AppSignal | AppSignal Blog 原文公開日: 2020/04/08 著者: Thijs Cadier サイト: AppSignal DHHが「シタデル（Citadel: 要塞、とりで）」という用語を命名しました。これは私たちAppSignalでアプローチしている技術を表すうってつけの用語となっています。「うちでやってるのはまさにこれだよ！ついに名前が付いた」と話題になったものです。 In addition to the Majestic Monolith, someone should write up the pattern of The Citadel: A single Majestic Monolith captures the majority

週刊Railsウォッチについて 各記事冒頭には🔗でパーマリンクを置いてあります: 社内やTwitterでの議論などにどうぞ 「つっつきボイス」はRailsウォッチ公開前ドラフトを（鍋のように）社内有志でつっついたときの会話の再構成です👄 お気づきの点がありましたら@hachi8833までメンションをいただければ確認・対応いたします🙇 TechRachoではRubyやRailsなどの最新情報記事を平日に公開しています。TechRacho記事をいち早くお読みになりたい方はTwitterにて@techrachoのフォローをお願いします。また、タグやカテゴリごとにRSSフィードを購読することもできます（例:週刊Railsウォッチタグ） 🔗Ruby 🔗 YJIT: もうひとつのJITコンパイラ（Ruby Weeklyより） 元記事: YJIT: Building a New JIT Com

こんにちは、hachi8833です。RailsConf 2021をすっかり見逃してました😇。 We must and will do better in the future. pic.twitter.com/qYTF7ljUX5 — RailsConf (@railsconf) April 9, 2021 つっつきボイス:「RailsConf 2021、そういえば開催時期だったか」「つっつき中の今日（04/15）がラス日でした🙇」「キーノートのページにコミットでよく見かける顔が並んでますね」 サイト: RailsConf 2021 セッション: Sessions | RailsConf 2021 - 60件 ワークショップ: Workshops | RailsConf 2021 -- 11件 「RailsConf 2021のfaqを見た感じでは有料イベントのようですね」「あ、そうでし

JSer.info #536 - ReactとVueに対応したスタイルなしコンポーネントライブラリであるHeadless UI 1.0がリリースされました。 Headless UI v1.0 – Tailwind CSS tailwindlabs/headlessui: Completely unstyled, fully accessible UI components, designed to integrate beautifully with Tailwind CSS. Headless UIはTailwind CSSと一緒に使う目的で開発されているため、コンポーネント自体にはスタイルは含まれていません。 Headless UIにはReactとVueの実装がそれぞれあり、今回のリリースでそれぞれが1.0としてリリースされています。 Comparing the New Generat

A year ago at BUILD 2020 we introduced our goal to bring Linux GUI applications to the Windows Subsystem for Linux (WSL) to run Linux GUI applications. We are proud to announce the first preview of this highly anticipated and open source feature! 情報源: The Initial Preview of GUI app support is now available for the Windows Subsystem for Linux | Windows Command Line 雑に翻訳。 1年前のBUILD 2020では、LinuxのGUIア

オブジェクト指向は最近もなんか議論になっているけど、とりあえず読むと良いかなーと言う本をまとめておきます。 オブジェクト指向、特にオブジェクト指向プログラミングに関しては本当に”Don’t think, feel.”なんで、書いているうちに体で気づくしかないものではあるのだけど、まぁそれもあんまりなので、読んどいた良い本はあります。古い本もあります。

All of our product development begins and ends with you—whether you posted on Developer Community, filled out a survey, sent us feedback, or took part in a customer study, thank you for helping to continue to steer the product roadmap for Visual Studio. 情報源: Visual Studio 2022 | Visual Studio Blog 64bit化とともに刷新されるVisual Studioにわくわくしますね！ 以下雑に訳しました。 Developer Communityに投稿していただいた方、アンケートにご協力いただいた方、フィード