Flutter はプロダクション開発に耐えうるのか / Flutter ready for production?Flutter はプロダクション開発に耐えうるのか / Flutter ready for production?
Content-Length: 232312 | pFad | https://b.hatena.ne.jp/wonder-wall/20201019#bookmark-4692922067244366082
世界でたったひとつの識別子として活用される「UUID」はどのように生成されているのか
オンライン対戦システムやランキングシステムの都合などで「世界中で唯一の値である識別子」をサーバーに接続せずに作成する必要がある場合があり、そうした場合に活用されるのが「UUID」です。そのUUIDの性質について、エンジニアのアリアマン・シャーダさんが解説しています。 Understanding How UUIDs Are Generated - Digital Bunker https://digitalbunker.dev/2020/09/30/understanding-how-uuids-are-generated/ UUIDは世界中で重複がないユニークな値となるよう設計されており、さらにその一意性が中央サーバーなどの要素に依存しないようになっています。こうした特徴をもつUUIDをデータベースの主キーに利用すると他人のデータベースと結合したり、データを別のデータベースに移動したりする
レガシーおじさん、SPAを始めてみた。そして限界を知る
はじめに 最近、Webの記事を見てるとReactだVue.jsばかりが上がっていてJSPやERBの話をしてる人は誰もいません。jQueryの記事ももちろん見ない。 つまり、Webだけ見る限りではほとんどの人がSPAを使ってるように見えます。 私はWeb界隈には居るもののどちらかというとバックエンド寄り、もっというとそもそもWebとか関係ない領域を見る事が多いので、ちょっとキャッチアップを兼ねていくつかの個人プロダクトにVue.jsを採用してみました。 jQueryくらいで頭が止まってたので。サーバサイドもマイクロサービスでAPI化が進んでるのでフロントもそれに合った技術を選ばないとですしね。 というわけで、今回はその中で得た知見というか、従来型のサーバサイドでのWeb開発をしていた人の視点でVue.jsをキャッチアップする流れで書いていきたいと思います。 まあ最終的な結論は正直「これすごく
jestのテストが遅い場合に確認すべきこと - ishikawa_pro's memorandum
こんにちは。 急に寒くなりましたね。 僕は最近iPad Air4 を予約しました。 今日は、javascriptのテストフレームワークのjestについてです。 業務では去年くらいから新規サーバーアプリケーションはjavascriptではなくTypeScriptを使っています。 それに合わせてテストフレームワークもmochaからjestへ移行しました。 jestjs.io jestの特徴の１つは、一意なグローバル状態を持つことを保証しつつ、複数のテストを別プロセスで並列に実行してくれるため、安全に高速なテストをすることが可能なことです。 しかし、僕が前にいたチームでjestのテストにかかる時間がやたら長いことが話題になってました。 今日は、この高速なはずのjestがやたら遅い問題が社内で話題になっていたので調査してまとめてみたので、もしjestが遅くて困っている方は参考にしてみてください。
「コマンドプロンプトは黒い画面に文字がたくさん出て怖い」→「チャット風」にしてみた LINEみたいで「分かりやすい」と話題に
黒い画面に“コマンド”を入力して操作を実行する「コマンドプロンプト」。慣れていないと少しとっつきにくいその画面を、LINEっぽくすることで親しみやすくした「チャット風コマンドプロンプト」を実際に作ってみた人が現れ話題になっています。 プログラマーでITエンジニアのkenji（@kenjinote）さんが開発し、GitHubでソースコードなどを公開しています。 チャットでメッセージのやり取りをしているような見た目で、こちらがコマンド（命令文）を入力すると、返信のような形で内容が表示・出力されます。入出力がはっきり分かれていて見やすく、“相手側”がアイコン付きなのが、なんだかホッとします。なにより全体的にかわいらしい。 チャット風コマンドプロンプト（画像提供：@kenjinoteさん） 通常のWindowsのコマンドプロンプト このアイデアは、Web制作企業ビックリマークの代表取締役でエンジニ
Amazon SQS を使ったアプリケーションを本番で運用する際に考慮すべき基本的な 5 つのこと
Amazon SQS は可用性やスケーラビリティの高いメッセジキューサービスであり、AWS の代表的なサービスの 1 つと言えるでしょう。ところが、本番の運用に耐えられるアプリケーションにしようと思うと考えることが意外に多いものです。本エントリーでは簡単なサンプルアプリケーションをベースに、本番で運用するために考慮すべき点・注意点について見ていきます。題材として扱うのが SQS なだけで、SQS 以外を使ったアプリケーションにも応用できる内容もあるでしょう。 なお、SQS には Standard queue と FIFO queue がありますが、Standard queue を使う前提とします。 アジェンダは次のとおりです。 サンプルアプリケーション 1. ログ 2. At-least-once delivery と visibility timeout 3. デプロイ 4. 異常系 5
コードレビューの目的と考え方 - osa_k’s diary
まえがき コードレビューの目的 大目的 小目的 チェックリスト 優先度高（大きな損失を生む問題・後からの修正が困難な問題） 優先度中 優先度低（システムに大きな影響を与えない問題・後からの修正が容易な問題） レビューを負担にしないために レビューサイズのコントロール 誰がレビューをするか 議論をどうまとめるか 批判と個人攻撃 レビュワー向けアドバイス Code author向けアドバイス 参考文献 まえがき コードレビューの有効性が説かれるようになって久しい。しかし、コードレビューをするべきという観念ばかりが先立ってしまい、何のためにコードレビューをするのか、どのような点をレビューするべきなのかといった、目的や進め方に対する意識が曖昧なケースも数多くあるように思われる[6]。コードレビューの目的を理解せずに惰性でレビューしているだけでは、いずれレビューそのものが形骸化し、単に承認のハンコを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Fetched URL: https://b.hatena.ne.jp/wonder-wall/20201019#bookmark-4692922067244366082
Alternative Proxies: