こんにちは。ぬこすけ です。 皆さんは「 setTimeout とはどんな関数でしょう？」と聞いたら、どう答えますか？ おそらく、ほとんどの人が「指定した時間に処理が走るようにする関数」と答えるのではないでしょうか？ function main() { console.log('動いたよ！！'); } // 大体 ３ 秒後に main 関数が動き出す setTimeout(main, 3000); 大雑把な理解としては問題ないですが、実は setTimeout の隠された能力はそれだけではありません。 setTimeout の隠された能力を知るとどんな良いことがあるのでしょうか？ 例えば、次のような良いことがあります。 ブラウザに対する理解が深まる Web サイトのパフォーマンスを向上させることができる ドヤれる まず、 ブラウザに対する理解が深まります 。 かのアリストテレスはこう言い残

先日Herokuの完全有償化が発表されて以降、蜘蛛の子を散らすようにHerokuからの脱出が図られています。 そんなわけで概ねHerokuの代替となりそうな無料サービスを紹介していきます。 ほとんどの代替サービスは完全無料というわけではなく、機能の少ない無料プランと高機能の有料プランが存在します。 有料化前のHerokuと同じということですね。 各サービスについて、実際に使ってみたという参考記事を貼っておくので、実際の使い勝手等はそちらを参照してください(他力本願） Qiita内に使ってみた記事が見つからなかったサービスは、日本では人気がないのだろうということで選外にしました。 また概要は、各サービスの説明やドキュメントに記載されているものです。 代替サービス一覧 FLy Flyはグローバルなアプリケーション配布プラットフォームです。 Turbokuを使えばHerokuアプリをFly.io

SurrealDBというRust製データベースを知ったので紹介します。このデータベースはすごいです。リレーショナル、ドキュメント、グラフ、あらゆる種類のデータ構造を扱うことができ、かつインメモリ、単一ノード、分散環境、全てで動かすことができます。さらにHTTPやWebSocketによるアクセスと柔軟なユーザ認証、認可機能とがDB本体に内包されており、ブラウザから直に接続するWebDBとしても使えます。とにかくなんでもできる夢のデータベースといった感じです。 特徴 機能を挙げていたら多くなりすぎたので、特に面白い部分を挙げます。 配列やオブジェクトをネストした複雑なデータ構造を持てるのに、レコードリンクという機能によりリレーションに対応していてしかもSQLやMongoDBより簡潔にクエリが書ける。 スキーマレスで各レコードには任意のフィールドを持てるが、必要ならスキーマを定義することもできる

このコンテンツ作成の背景 プログラミングを体験できるコンテンツは沢山存在していますが、開発プロジェクト全体を通した流れを体験したり、実務では不可欠となるドキュメント作成を体験（学習）できるコンテンツは少ないので作ってみました。 とはいえドキュメント作成についてはテンプレート見ながら「こんなもんです」と解説する感じになります。。。 免責事項（いいわけ） 元々は社内の非技術系な人向けに研修用資料として作っていたものを、どうせなら公開するかな。という感じで再編したものなので、足りない部分やオレオレな部分、ゆらぎ、不整合、誤字脱字とかも多いと思います。「間違い」や「こうしたほうがいいよ」というのがあれば、コメント等で"優しく"教えていただけると助かります。少しずつ修正していこうと思ってます。 オレオレな情報だけでは申し訳ないので、一般社会ではプロジェクト関連のドキュメントはどう書くのか？については

はじめに 今回はFlyCode氏が紹介していた、Reactを学ぶ上で知っておくべきJavaScriptの基本概念を紹介します。 具体的なJavaScriptでのコード解説と、Reactではそれがどのように使われるのかを紹介します。 この記事の対象者 JavaScriptのよく使う基本文法を学びたい人 Reactの初心者から中級者 この記事の目標 React開発でよく使われるJavaScriptの文法や処理を理解する JavaScriptの基礎文法 本記事では下記の7つをピックアップして紹介します 三項演算子 分割代入 スプレッド構文 配列操作 アロー関数 非同期処理(Async/Await/Promise) APIコール 三項演算子 三項演算子はMDNでは下記のように解説されています。 条件 (三項) 演算子は JavaScript では唯一の、3 つのオペランドをとる演算子です。 三項演

前書き 5か月ほど前にQiitaに登録し、それから登下校中や休憩時間など、空いた時間は基本Qiitaを見るようになりました。 ストックした記事が106、LGTMした記事が12ページ分にもなり、記事の整理もかねて、特に好きな記事や理解が深まった記事などを振り返りつつまとめようと思います。 無言で記事を掲載しております。迷惑だったら申し訳ありません。 が、随時更新予定です。 追記(2022/10/18) Twitterにておすすめの記事を紹介していただきました！ 今後もそういった機会があることを信じて、ほかの方にオススメされた記事を紹介する枠を設けます。 誰に向けて Qiita触りたての人 プログラミング始めたての人 自分自身 最初に見ておくべき記事 最初の頃は数学と同じように変数を決めていたため、aやbとしていたが、この記事を見て驚愕した（笑） リーダブルコードを読むきっかけとなった記事。

はじめに 今でも語り継がれる「原則」は、それだけ価値のあるコンセプトです。 歴史を振り返ることは、失敗を防ぐための効率の良い方法になります。 👑 DRY (Don't repeat yourself) 「同じことを繰り返すな。」 Andy Hunt と Dave Thomas の著書『達人プログラマー』（1999 年）で提唱された原則で、プログラミングに関する最も重要な原則といっても過言ではありません。 DRY 原則だけでなく、どんなデザインパターンやベストプラクティスでも、同じ処理が重複することは基本的に許されていません。 これにはどういう意図が込められているのでしょうか。 🔖 表面的な理由 この原則は、コードの再利用性を高め、そのために疎結合な状態を保つことは、極めて有用なことを示唆します。 1 箇所を直せば済むべき箇所をあちこちに分散させてしまうのは、自分で事故を招いているのと同

はじめに 私がプログラマーとして働き始めて１年半がたちました。幸いなことに環境に恵まれ、私の身の回りには成果を出し続ける優秀なプログラマーがたくさんいます。 1年半彼らの仕事を観察して気づいたことは、成果を出すプログラマーは共通して 「コードを書かない努力をしている」 ということでした。 この記事では彼らが業務で行なっている、 「コードを書かないための思考、習慣」 についてまとめていきたいと思います。 前提 多くの人は「プログラマーはコードを書くことが仕事」だと考えています。この考えに基づくと、プログラマーが「コードを書かない努力をする」ということが、ひどくおかしなことに思えてしまうかもしれません。 そこでまず前提として3つの誤解を解くところから始めましょう。 [誤解１] プログラマーの仕事は「コードを書くこと」である 私たちプログラマーの多くは会社から給料をもらいながらコードを書いていま

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? ディップ Advent Calendar の4日目です。 はじめに こんにちは。 ディップでUXデザインや速度改善、潤滑油などをやっている@ysktsunaです。 今回は自分のチームに新メンバーを受け入れた時に発生した悩みと、それをソシャゲ風に解決した方法について書きます。 読んでほしい人 先輩として若手（特に新卒）の面倒を見る人 こんな話ありませんか？ 仲間が増えた 僕らのチームに新たなデザイナーが参画しました。 ：新卒ちゃん（デザイナ見習い） ：僕（おっさん） ＜ 新しくチームに入りました！ よろしくお願いします！ ＜ こちらこそよ

vite4がリリースされましたが、プロジェクト作成時に「vite@latest」を指定しているため問題ありません。 vite4は、以下を参照してください。 https://vitejs.dev/blog/announcing-vite4.html はじめに Reactの開発環境は、CRA(Create React APP)がよく使われますが、CRAは沢山のモジュールの整合性の確認などのため、アップデートがリリースされるまでの間隔が結構あります。 また、使われているモジュールをアップデートするとエラーに悩まされたりします。 ゼロからReactの開発環境を作成していたのですが、いろいろとトライを繰り返すうちに以下の方法に落ち着きました。 比較的短時間で環境が作成できますし、全て最新のモジュールが使えます。 Vite nodejsを用いたJavaSriptプロジェクトは、、Webpackなどでプ

はじめに 学童保育で使う検温結果提出アプリを作る際の要件として、 自分の子供の検温結果を入力できる 他の子供の結果は見えない があったので考えた。 社内アプリなど 複数人で使って 他人に情報を見られたくない 場合は必須設定になるかと思ってメモする。 もっと良い方法があれば教えてもらえると助かります。 考え方 検温結果を入力する際に、ログイン時のメールアドレスも自動的に非公開で入力するようにする 入力されたメールアドレスを、対象テーブルのセキュリティフィルタにてフィルタリングする 設定方法 ①カラムにメールアドレス入力列（メールアドレス）を追加し、以下設定をする。 非公開 編集不可 入力不要 初期値は関数で USEREMAIL() これで入力時に、ログインメールアドレスを勝手に入力してくれる。 ②テーブルの SECURITY の Security filter にて、以下設定をする。 [メー

2022年4月、Deno に以下のバグが報告されました。 fetch API を使って 300KB ぐらいあるファイルをアップロードすると、一定確率でアップロードされたファイルが壊れるというバグの報告です。 報告者によれば、1.20.6 まではバグは発生しておらず、1.21.0 から発生するようになったという事です。1.20.6 の次のリリースが 1.21.0 なので、パッチバージョン1個分まで、バグの発生時期が特定されている状態です。 fetch 周りは自分はほぼ実装していないので「担当範囲ではない」感覚だったので、普通にスルーしていました。 自分に限らず、Deno Land コアチームの誰もこの issue にピンと来る人が居なかったようで、stale ボット (数ヶ月進捗の無い issue を自動的にクローズしようとするボット) に2回もクローズされかけていました。Deno の st

ABAPに親しんだ人にとっては、Entity Type=構造の型、Entity Set=内部テーブル、Entity= 内部テーブルの1行と考えるとわかりやすいと思います。 Entity Type, Entity, Entity Setのイメージ 実際のmetadataを見てみる metadataを見る際はブラウザに <サービスURL>/$metadata と入力します。 試しにTripPin Serviceというサンプルサービスのmetadataを見てみましょう。 https://services.odata.org/TripPinRESTierService/(S(jiypl3wubcokjjg4zf40jtvx))/$metadata なんだかびっしり書かれていてわかりづらいですね。 それもそのはず、機械が読めるように記述してあるのですから。 あと、TripPin Serviceで利用

NoCode Advent Calendar 2020 7日目の記事です。 はじめに AppSheetではデータを受け取るインタフェースがスプレッドシート以外にもデータベースやSalesforceなどいくつか存在しています。その中にはデータベースのインタフェースもあり、これを使ってkintoneデータを使ったアプリを作成していきます。 ？？、kintoneデータをデータベースのインタフェースで？ となるかと思いますが、kintoneとAppSheetの間にCData ConnectというSaaS型サービスを挟むことで、SaaSが提供するAPIをOData、MySQL、SQLServerのインタフェースに変換して公開できるようになり、今回の構成（kintoneをMySQLとしてみる）が実現できます。 使うサービスはkintone、CData Connect、AppSheetの３つになりますが

今回はdim(オープンデータパッケージマネージャ) v1.0のリリースに伴って開発したツールの紹介をしたいと思います。 オープンデータもパッケージマネージャ(apt、npm、gem、pipなど)と同じようにnpm install xxxxxのような形でオープンデータをインストールして管理すると良いのではないかという話です。 以前のバージョンに関しては以下の記事で紹介 【個人開発】パッケージマネージャーの考えを流用してオープンデータ管理ツールを作ってみた話 以前の記事を読んでいてv1.0からの変更点に関して読みたい方 dim v1.0 変更点 オープンデータを無秩序に管理するのはやめたい ソフトウェアやライブラリの管理は世の中様々な体系化された方法が確立されつつあります。ソフトウェアであればaptやbrewなど、ライブラリであれば言語ごとにnpmやgemなどが存在します。しかし、データに関し

概要 最近は API Blueprint で仕様書を書くことが多かったのですが、Swagger が世界標準になるかもしれない、ということもあり、開発の効率化を進めるためにも概要をまとめてみようと思った次第です。 Swaggerとは Swagger は RESTful APIを構築するためのオープンソースのフレームワークのことです。「Open API Initiative」という団体がRESTful APIのインターフェイスの記述をするための標準フォーマットを推進していて、その標準フォーマットがSwaggerです。Swaggerには多くの便利なツールが提供されていることもあり、多くのメリットを享受できそうです。 Swagger Spec を書いておけば自動的にドキュメント生成までしてくれ、それだけではなく、ドキュメントから実際のリクエストを投げられる優れものです。 Swaggerのツール群

はじめに シェルスクリプトで二重起動防止やロックをする方法を検索すると、いろいろな方法や書き方が見つかりますが、どれを使えばよいのか、本当に正しく動くのか、不安になりますよね？ ディレクトリ (mkdir) やシンボリックリンク (ln) を使った独自実装の例も見かけますが、エラー発生時や予期せぬ電源断、CTRL+C で止めたときなどでも問題は発生しないのでしょうか？ まず、ディレクトリやシンボリックリンクを使った独自実装はしない。これを肝に銘じてください。シェルスクリプトでのロック管理はとても難しく、一般的な排他制御の知識に加えて、シェルスクリプト特有の問題、シグナルやトラップ、サブシェルや子プロセスの問題、さらには特定のシェル固有の仕様やバグなどさまざまな問題に対処する必要があり大変です。独自実装の例では古いロックファイルが残ってしまい、それをいつどのタイミングで片付ければ安全なのか？

外部のサービスからの通知を WebHookで受け取ってちょっとした処理をしたいことってたまにありませんか？ たとえば、アプリのクラッシュログを解析するFabricの Crashlytics には、新しいクラッシュが発生したり特定の閾値を超えると WebHookで通知してくれる、つまり特定の URL にPOSTを発行してくれる機能があります。 これを上手く使うと、下の図のように「新しいクラッシュが発生したら Backlogなどのチケット管理サービスに自動登録」といったことができそうです。 もちろんCrashlyticsから BacklogのAPIは直接叩けないので、このように WebHookを使ってこちらのサーバを叩いてもらい、そのサーバがあらためて Backlogの APIを使ってチケットを登録する、というよう感じになります。 以下は実際のClashlyticsの管理画面です。WebHoo

はじめに DiscordはGitHubからのWebhookには対応していますが、GitLabからのWebhookには対応していません。 そこで、Google Spreadsheet を簡易 Webサーバーとして動かして、手軽にWebHookを受け取る方法を参考に、GitLabからのWebhookをGoogle Spread Sheetでいったん受け取り、Discordに対応した形に整形してからPOSTする、ということをやってみました。 できたこと GitLabのJob eventsをトリガーにこんな感じでDiscordにメッセージを送信できました。ここでは、とりあえずジョブの名前とステータスだけ表示させていますが、もちろん他の情報も表示させることはできます。 中継サーバとなるGoogle Spread Sheetを準備する ここの内容はほとんどGoogle Spreadsheet を簡易

背景 Dockerコンテナを立てたらマルウェアに感染したのでサイバーセキュリティの啓蒙を兼ねてメモ書きしてみました。 注意事項 マルウェアに感染した被害の対処方法を記述しています。マルウェア自体の機能や解析の解説ではなく一般利用者ユーザーの視点から感染経路と対応方法についての記述になります。 マルウェア感染状況 症状 Dockerコンテナを稼働させたホストのロードアベレージ(CPU負荷)が常時4を超える状況になっていました。つまり400%でホストがフル回転してた訳ですな。 例えるならエヴァンゲリオン初号機が暴走してマヤちゃんがコンソール画面に向かって叫んでいるところです（違） こうなるとクラウドサービスのAWSとかだと英文で警告アラートが飛んで来ますし毎日課金されで膨大な利用料金請求が来ることになります。恐ろしい！！ 状況の調査 CPUの利用状況やメモリの使用量などを調査するツール類があり