タグ

heguroのブックマーク (634)

  • GitHub Actions 逆引きリファレンス

    1.この記事の立ち位置#自分がいつも調べていること、忘れがちな Tips や小ネタを列挙していく。そのため、網羅性は重視しない。 というのも、なにか調べていていろいろ読み漁った挙げ句、1周回って行き着くところは GitHub Actions の公式ドキュメントであり、たとえば Workflow の書き方は以下のページをよく開いている。 Workflow syntax for GitHub Actions - GitHub Docs それでも、公式ドキュメントで参照したい箇所を引っ張るための用語を知るまでに苦労することが往々にあり、この記事が、公式ドキュメントで参照したい箇所を導くための助けとなればと思い、書いていく。 2.Step と Job と Workflowの違いアレコレ#2-1.Step と Job と Workflow の違いの一行まとめ#Step < Job < Workflo

  • ゲームのじかん - インターネット

    ようやくPS5を買った。GT7をやるためである。 さて、GT7はレースゲームであり、またお手として「現実」があるタイプのゲームである。現実というのはつまるところ現実の自動車及びそのレースのことであり、基的にはこれらをどのようにリアルに再現するのかという点に心血が注がれている。もちろんのこのリアルさというのは世代が進むごとに強化されており、リアルなグラフィックと挙動というのが(GT7に限らず)リアル志向レースゲームの売りとなっている。 しかし、そんなリアルなゲームであっても意図的にフィクションを残している部分がある。それが時間である。 どういうことかというと、GT7の世界には少なくとも二つ以上の時間が同時に流れている。一つはラップタイムを司る時間──これは現実世界の時の刻みと同じである──そしてもう一つは「ゲーム内で流れているであろう時間」である。これは現実世界の時の刻みとは非同期なもの

    ゲームのじかん - インターネット
  • 第12回 自分の調べ物に最適の雑誌記事索引を選ぶには――記事索引の採録年代、得意ジャンルを知っておく | 皓星社(こうせいしゃ) 図書出版とデータベース

    小林昌樹(図書館情報学研究者) ■は今、わりあいと見つかる むかしは読みたいを見つけるのも一苦労だったが、現在では国会図書館NDL)の全国書誌データがネット検索できるようになって、ひととおり探すことが誰にでもできるようになっている。また、そこで分類や件名を使えば、見たことも聞いたこともないを見つけることもできるはず(第3回 見たことも、聞いたこともないを見つけるワザ)。 しかし、NDLに明治以来の和図書が1000万冊あったところで、自分の知りたいことがちょうど良く1冊のになっているとは限らない。その場合、どうするか? 雑誌の記事を探すということになる。 ■記事はまだまだ難しい 戦前の日には記事索引がほぼなかった。だから戦後、アメリカ図書館使節が衆・参議院に「調べ物のための図書館には、これこれの事業をさせなさい」と教えたなかに、汎用の雑誌記事索引があったのだ。そこで、創設翌年(

    第12回 自分の調べ物に最適の雑誌記事索引を選ぶには――記事索引の採録年代、得意ジャンルを知っておく | 皓星社(こうせいしゃ) 図書出版とデータベース
  • kifutownとかいう情報商材屋ヒャッハーなアプリがヤバイッ!二度美味し

    ZOZO前澤さんが金を配ったアレ。アレをシステム的に可能にしたのがkifutownというアプリ。 最初は慈善活動の団体やその支援者のために作られたアプリかと思った私はイノセントまっしぐらッ。 これはお金でフォロワーを合法的に買うシステムであり、詐欺師のために作られたとも思えるほどよくできたロンダリングシステム(後述)。 こんなしくみよ。 寄付する人が「総額10万円を10人に配りマース」と言う。 アプリ内では寄付の条件として、「条件は特になし」というやつと、「ツイッターで私をフォローすること」というメニューが組み込まれている。っていうか、そもそもそれ、変じゃね????そんなメニュー必要か?あ、慈善活動とかじゃないないのか。(お察し) そう。これは、お金を払ってフォロワーを買う合法的なシステム。「自由恋愛だからセーフ」みたいなノリと同じ。 いや、100歩譲って自由恋愛だからセーフだと思ってもい

    kifutownとかいう情報商材屋ヒャッハーなアプリがヤバイッ!二度美味し
  • Git 2.27.0 から git pull をすると表示されるようになった "Pulling without specifying how to reconcile divergent branches is discouraged." について - ESM アジャイル事業部 開発者ブログ

    最近の趣味はもっぱら L7 より下のお勉強、な @yucao24hours です。 梅雨入りもどこ吹く風の暑いある日、いつものように git pull を実行すると、以下のような警告が出るようになりました。 $ git pull warning: Pulling without specifying how to reconcile divergent branches is discouraged. You can squelch this message by running one of the following commands sometime before your next pull: git config pull.rebase false # merge (the default strategy) git config pull.rebase true # rebas

    Git 2.27.0 から git pull をすると表示されるようになった "Pulling without specifying how to reconcile divergent branches is discouraged." について - ESM アジャイル事業部 開発者ブログ
    heguro
    heguro 2022/05/26
  • ライブラリゼロの20行でReduxもどきを実装して、Reduxを完全掌握しよう!!

    はじめに Reduxは遠い昔に誕生したものなので、いまReduxを使っていない人も多いかもしれません。 Reduxは、出現当時はそれほど大きなソフトウェアではなかったのですが、ときが経つにつれて、いろいろな便利関数たちが現れてきて、そのせいで今からReduxを調べる人は、何が質なのかを調べるのが難しくなっていると思います。 そこで3分でReduxもどきを実装しました。こちらです。20行!! じゃーん! JavaScriptでうごきます!! // 実装 const createStore = (reducer) => { let state = 0; const listeners = []; const dispatch = (action) => { const newState = reducer(state, action); state = newState; listeners

    ライブラリゼロの20行でReduxもどきを実装して、Reduxを完全掌握しよう!!
    heguro
    heguro 2022/05/26
    "プログラミング言語では、reduceはたくさんあるものを1つにするというようなイメージ" 調べてみたらまとめ(られ)るって意味もあるのね
  • Reactでロジックをhooksにまとめないという選択肢 - Hello Tech

    javascripterです。ハローでは、プロダクトのローンチ前からAutoReserve の開発に関わっています。 突然ですが、Reactを使用する際、コンポネントのロジックや状態が増えてきたとき、みなさんはどうされてるでしょうか。 関数コンポネントでは、一般にcustom hooksとしてまとめて切り出すことが多く行われていると思います。 今回の記事では、useState/useRef + custom hooksという単位で切り出すのではなく、 クロージャを使いロジックや状態をコンポネントの外に持たせるようにリファクタリングすることで、コードの見通しが良くなる、という事例を紹介します。 JavaScriptにおけるクロージャとは、関数が外側のスコープの変数などへの参照を保持できる機能のことです。ここではクロージャとして実装しましたが、同等のことはclassを使っても実装できます。 A

    Reactでロジックをhooksにまとめないという選択肢 - Hello Tech
  • なぜNext.jsをやめたのか? - Hello Tech

    javascripterです。ハローでは、プロダクトのローンチ前からAutoReserve の開発に関わっています。 この記事では、AutoReserveウェブ版が、Next.jsを一度採用したがやめ、その後create-react-app + react-routerの構成に移行した経緯を書きます。 ウェブ版開発の背景 AutoReserve はAIが電話予約を代行してくれる飲店向け予約グルメアプリで、現在はiOS / Android / ウェブにサービスを展開しています。 元々はReact Native製のネイティブアプリのみ展開していましたが、ユーザ獲得の面でウェブ版が必要となったため、 追加でウェブ版を実装し、現在の3プラットフォームでの展開に至ります。 最初の技術選定 ウェブ版の最初のバージョンでは、フレームワークとしてNext.jsを採用しました。Reactで書け、SEOのた

    なぜNext.jsをやめたのか? - Hello Tech
  • 専門家と街の接着剤を見て歩く

    パッと見える視界の中に絶対とは言えないまでもほぼ確実に存在するものがある。空気や水、都市においては接着剤もその一つだろう。専門家と一緒に街を歩くシリーズ、なんと今日は接着と接着剤を見て歩くのである。 50年接着剤メーカーにいる専門家と歩く 今回一緒に渋谷を歩いてくれる木村修司さんは接着剤メーカー・セメダイン勤続50年超の最古参社員だそう。検索をすると「接着剤博士」という異名まで出てくる。 接着剤について聞くうえではうってつけの方である。 一方、不安もある。街の接着剤を見ると言ってもそんなに話すことがあるのだろうか。違いが微妙すぎやしないか。だが聞いてみるとおもしろい話がたくさんあった。 セメダインの木村修司さん(左)デイリーポータルZ林雄司(右) ビルのガラスは接着剤でついている 渋谷の駅前からスタートです 林:たとえばこの景色で接着剤使ってるところって考えると…。 木村:いっぱいあります

    専門家と街の接着剤を見て歩く
  • Layouts RFC

    This RFC (Request for Comment) outlines the biggest update to Next.js since it was introduced in 2016: Nested Layouts: Build complex applications with nested routes. Designed for Server Components: Optimized for subtree navigation. Improved Data Fetching: Fetch in layouts while avoiding waterfalls. Using React 18 Features: Streaming, Transitions, and Suspense. Client and Server Routing: Server-cen

    Layouts RFC
  • 【検証】React.FC と React.VFC はべつに使わなくていい説

    こんにちは、クレイの正岡です。 コロナ禍が始まってから小学生時代以来のゲーム生活を送っています。ゲームボーイと呼んでください。 さて、今回は React × Typescript でコードを書いている人/書こうとしている人に向けて、Reactコンポーネントの型定義について頭の片隅に置いておいて欲しい情報を共有したいと思います。 寝ながら使えてしまうReactコンポーネントの3つの型 () => JSX.Element 型 interface Props { text: string } const Hoge = ({ text }: Props) => { return ( <p>{ text }</p> ) } 上記のように返り値の型を特に指定していない場合、 このコンポーネントは JSX.Element型 を返す関数( () => JSX.Element )として返ります。 React

    【検証】React.FC と React.VFC はべつに使わなくていい説
  • 私の推しフロントエンドディレクトリ構成と気をつけたいポイント

    どうも、sakitoです。 今回は私の推しフロントエンドディレクトリ構成と気をつけたいポイントを紹介します。ちぇけら! 2023年5月29日 追記 この記事を読みにきていただきありがとうございます。 私が記事を書いた時期はまだNext.jsのApp Routerが発表されたばかりで、App Routerを使用したディレクトリ構成の考慮はされていません。 先日、App Routerがリリースされ、Next.jsのドキュメントにApp Routerのディレクトリ構成について記事が出ているので、Next.jsを使用されている場合は、まず参照することをオススメします。 はじめに 今回、私の紹介する推し構成は、機能単位で設計するパターンです。 Reactのディレクトリ構成のベストプラクティスを集めたBulletproof Reactで紹介されているパターンにかなり似ています。さらに詳細なプロダクト構

    私の推しフロントエンドディレクトリ構成と気をつけたいポイント
  • なぜReactは標準でComponentをmemo化しないのか?

    はじめに 普段はスタートアップでBtoB SaaSの開発をしているtaroと申します。 今回は、Reactのmemo化について考えている中で抱いた 「なんでReactは標準でComponentをmemo化していないんだろう?」 という疑問を解消するために、色々と調べたり考えたりした内容をまとめました! 途中でrenderのタイミングや、memo化で再renderが抑えられる理由などの前提知識の復習も含めていて、memo化について詳しくない方もmemo化の勉強にもなると思うので、ぜひぜひ読んでみてくださいー! なぜこんな疑問を抱いたのか? まずはそもそも僕がタイトルにあるような疑問を抱いた背景です。 疑問を抱くまでの思考プロセスはこんな感じです。 「再renderが余分に走ってて画面が重いから最適化したいなー」 →「React.memo()を使ってComponentをmemo化しよう!」 →

    なぜReactは標準でComponentをmemo化しないのか?
  • Next.js の「next start・next dev」挙動差分一覧

    Next.js で開発をしていると、ドキュメントに書かれている通りに記述してもうまく動かず、実は「next build && next start しないと確認できないものだった」という事がしばしばあります。そこで、気づいた時雑多に放り込む場所があると良さそうと思い、スクラップを開きました。 どなたでも投稿大歓迎です。

    Next.js の「next start・next dev」挙動差分一覧
  • CLIツールを作るためにoclifを試してみたら簡単すぎて吃驚した | Trial and Spiral

    CLI用のコマンドを作ってみようと思いたったのですが、CLI開発フレームワークoclifを試してみたらとても簡単で環境構築もすんなりできたのでびっくりしたという話。 概要 ある用途で思いたってCLIのコマンド作ろうと思った oclifというCLI用のフレームワークがあったので試してみた 簡単すぎてびっくりした 追加でPrettierとJestも対応してみました 動機 誰しもCLIのコマンドをつくりたくなることがたまにある。僕はある。 今回はGUIを作るまでもなく、コマンドでシュッと実行したい作業があったので勉強と遊びを兼ねてコマンドを作ることにしました。CLIの開発ツールはいろいろありますが、今回はやりたいことを実現するのにすでに知見としてあるものを流用したい背景aからNode.jsでやることにしまた。 Node.jsにもCLI用を作るためのライブラリがさらにいくつかありますが、今回はoc

    CLIツールを作るためにoclifを試してみたら簡単すぎて吃驚した | Trial and Spiral
  • TypeScriptのユニットテスト環境を構築してみた | DevelopersIO

    はじめに アノテーションの髙嶋です。 私は業務でよくGoogle Apps Script(以降、GAS)を書いています。 ただGASの実行環境で実行できるテスト用フレームワークがなく、関数単位での動作確認がしづらい状態です。 なので、多少でもローカル環境でテストを実施できるようにユニットテスト実行環境を構築したので、その手順を記述します。 ただ、ユニットテストはTypeScriptで書いた状態で実行しています。 そのため、GASの関数部分はモックする必要があり、実行環境での最終的な動作確認は別途必要になります。 なんでテストが必要なの? そもそもなんでテストをする必要があるのか。 よく聞く話かもしれませんが、プログラムは考えたとおりに動くわけではなく、書かれたとおりに動きます。 ですので、プログラムが仕様どおり(考えたとおり)に動作していることを確認するためにはテストの実施が必要です。 テ

    TypeScriptのユニットテスト環境を構築してみた | DevelopersIO
  • 3値論理

    なぜ「= NULL」ではなく「IS NULL」と書かなくてはならないのか? これは、気になっている人も多いはずです。まだ SQL に不慣れな頃、ある列が NULL である行を選択しようとして、 SELECT * FROM table_A WHERE col_1 = NULL; というクエリを書いてしまい、エラーになったり思い通りの結果が得られなかった、という経験は、ほぼ全ての人が持っているでしょう。ちょうど C言語や JAVA を習い始めのころに「if (a = 5)」と書いてしまう間違いとよく似ています。最初は、言語仕様の汚さにぶつぶつ文句をいいながらも、そのうち「IS NULL」という書き方に慣れてしまって、疑問を持たなくなります。 でもどう考えても奇妙な書き方ですよね。こんな素直でない書き方をしなくてはならないということには、やはりそれなりの理由があるのです。今からその理由を説明しま

  • データベース設計におけるNULL - kawasima

    NULL絶対ダメ論や現実的には無理だから上手く付き合っていくしかないんだよ論など見られるが、せっかくCodd博士が上図の分類を提示しておられるので、これを元にもっと詳細化して考えてみよう。

    データベース設計におけるNULL - kawasima
  • かつて人類は1と0を打ち込んでプログラムを書いていたらしい

    それじゃあまりにも天才しかできないだろうということでニーモニックというのを持ったアセンブリ言語ができた 多分当時の人の中にあった議論は、こんなの1と0の羅列に名前つけただけだろ、なんかいいことあんの?という人たちと、まさにブレークスルーだ世界が変わるとエキサイトした人たちだろう。 色々あったが、人にも読めるソースをアセンブリ言語に変換してくれるCが出来た。 多分このときも単なるアセンブリのスーパーセットだろ?なんか意味あんのか?っていう人たちと、やばいレベルでプログラミング書きやすくなったとエキサイトする人たちに分かれたことだろう。 その後Javaが登場してオブジェクト指向が花開いた。 このときも、構造化プログラミングに毛が生えた程度のもんだろ?何が嬉しいんだ?という人と、オブジェクト指向なら何でもできる!とエキサイトした人たちで溢れかえったことだろう。 Java以降のIT界隈ではもはやオ

    かつて人類は1と0を打ち込んでプログラムを書いていたらしい
  • 「なんのために作るか分からへん」と愚痴っていたらPMさんが救ってくれた話 - Qiita

    ※今回はほぼ実話です。 システム開発会社勤務 プログラマーワイ ワイ「さあ、今日も開発をしていこか」 ワイ「とあるWebサービスの管理画面を作らなアカンのや」 ワイ「今日は、どんな機能を作らなアカンのやったかな」 ワイ「せや、クライアントさんからもらった機能一覧.xlsを見てみよか」 ワイ「あとは、デザインデータも見ながら、詳細設計書でも作っていこか」 ワイ「・・・ふーむ、作るべき機能の一覧は書いてあるんやけど」 ワイ「なんか、やる気が出ぇへんなぁ」 ワイ「仕方ないから、社内のSlackで愚痴っとこか」 ワイ「今のプロジェクト、誰のために何を作ってるのかがイマイチ分からんから」 ワイ「モチベーションが上がらへんなぁ」 ワイ「この管理画面を使って、どんな課題を解決したいのか」 ワイ「どういう風にユーザーさんの業務をうまく回したいのか」 ワイ「そんなんがピンと来てないから、作るべきモノもはっき

    「なんのために作るか分からへん」と愚痴っていたらPMさんが救ってくれた話 - Qiita