Frontend Study #1 訂正: 最後のzennの記事のリンク先は、正しくは https://zenn.dev/mizchi/articles/c638f1b3b0cd239d3eea です

今回のエントリでは先日、僕が勤めているソニックガーデンで話題になったプログラミング関連の小ネタを書きます。 それは何かというと、「プログラミング初心者は変数名やメソッド名を略さない方がいい」という話です。 長い変数名やメソッド名はつい略したくなります。 実際、僕も長い名前を略すときはよくあります。 ですが、略称を使うのは長年の経験から「この略称は一般的だから誤解を招くことはきっと少ないだろう」とか「前後の文脈から、変数の中身は誰が見ても明らかだろう」という想像が付いた場合だけです。 一方、プログラミング初心者の人は経験が浅いため、「一般的かどうか」とか、「誤解が発生しないかどうか」といった判断ができません。 そのため、他の人が見たときに「え、何この変数名？」と思ってしまうような略称を付けてしまう恐れがあります。 たとえば、先日のコードレビューで、初心者の人がrev_noという名前の変数を定

概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Keep up with the Tines: Rails frontend revamp — Martian Chronicles, Evil Martians’ team blog 原文公開日: 2020/06/03 著者: Rita Klubochkina、Andy Barnov サイト: Evil Martians -- ニューヨークやロシアを中心に拠点を構えるRuby on Rails開発会社です。良質のブログ記事を多数公開し、多くのgemのスポンサーでもあります。 日本語タイトルは内容に即したものにしました。 アセットパイプラインで提供される既存のjQueryやCoffeeScriptのフロントエンドを一切損なわずに、「React」「MobX」「GraphQL」「Tailwind CSS」「Webpacker」の複雑な

アプリ開発者向けにアプリをリリースする前段階から知っておくとよいGoogle Analytics for Firebaseの使い方とアプリの成長を可視化するテクニックを紹介します。

単純に仕事の用事なのですが、俗に言う経営層と言える立場の方々にヒアリングする機会が増えたことで、とあるセリフを頻繁に耳にするようになりました。 「事業の話ができるエンジニアがいないんだよね。本当に困りますよ」です。 これは僕が事業の話をできるとかそういうことを言いたいのではなくて、各社の経営層の切実な想いであり１つや２つの組織で聞いた発言ではなく、あらゆる組織で耳にする強烈なペインであると言いたいんです。 本当に、文字通り、全ての組織でこの発言を聞きました。 僕個人としては、「え？そうなんですか？結構いると思いますが」って当初反応してたんですよね。何故なら、自分の周りには幸い「技術にだけ興味があるエンジニア」が少ないからでして、彼らがそこまでの切実さで何を求めているのかはっきりとわかっていませんでした。ただ、僕も諸事情あって彼らと似たような視点を持たなければいけない状況になり、この発言の理

フロントエンド/Node.js エンジニアの mizchi です。plaid では新しい分析エンジンのフロントエンド側の技術的な仕様を考えたり、それを実装したりしています。趣味として社内の他のプロダクトのパフォーマンスを勝手に測って、貼り付けていくこともあります。 plaid のエンジニア組織には「組」という制度があって、メインとなるプロダクト以外にも、そのテーマで会社横断で活動するグループがあ

Webフルスタックエンジニアになるためのチェックリスト Zennでの投稿にあたって この記事は、2020/03/22に自分のgithubリポジトリで公開していた内容を、Zennのgithubリポジトリ連携機能を用いて一般公開したものです。 投稿にあたって、Zennの記事連携フォーマットに準拠する以外の修正は加えておりませんので、一部Zennというプラットフォームの方針や雰囲気に合わない内容などあるかもしれません。あらかじめご了承ください。 はじめに 日本のWeb開発業界で「フルスタックエンジニア」になるために必要な知識を、個人的経験からまとめました。 フルスタックエンジニアの定義ですが、ここでは、 企業で開発リーダー/テックリードとして、Webブラウザアプリケーションを前提としたサービスの立ち上げからリリース、運用まで面倒を見られる。 というロールと仮定し、前提条件としては、どちらかという

この記事の内容 blitz-js が生まれた背景 prisma の紹介 blitz で簡単なブログを作ってみる blitz を vercel にデプロイしてみる tldr blitz-js は next.js + prisma で rails を再現しようとしているフレームワーク Prisma ORM それ自体が良い。blitz の理解のためにも、まず Prisma を学べ blitz-js 自体はまだ α 品質だけど、今から注目しておく価値はある。デファクトになるかは不明。思想は継承されそう。 はじめに next.js はとても良いフレームワークだが、永続層を持たない。なのでフロントエンドとフロントサーバーに閉じている。 永続層、つまり DB を持たないので、初学者や流行りのプログラミングスクールの教材に選ばれない。また、JavaScript の学習資料が散らばっている。 要は Rail

セキュリティは難しいです。 ですが、プログラミング初学者の皆さんは必要以上に萎縮せず、どんどんアプリケーションを作り、公開することにチャレンジして欲しいと私は思っています。 一方、事実として、脆弱なアプリケーションが公開されている（サーバ上でアクセス可能な状態になっている）だけで、全く無関係な第三者が被害を被る可能性があることは知っておく必要があります。 それはWordPressを使った単なるWebサイトであったとしても同じです。 また、あなたのアプリケーションが破壊されて困らないものであったり、 個人情報を保持していないものであったとしても、です。 だから、知らなかった、では済まされないこともあります。 この記事では、PHPのソースを例に、 特にプログラミング初学者が生み出しやすいアプリケーションの脆弱性について、 具体的なコードを挙げながら解説します。 なお、本記事のサンプルコードはも

死にかけのジジババが死んだ、以外のことで頼む。 かかったら何が危険で怖いの？

濱渦伸次| NOT A HOTEL CEO @shinji_hamauzu NOT A HOTEL創業者、CEO。2007年宮崎でアラタナを創業→ZOZOにM&A、ZOZOテクノロジーズ取締役を兼任→2020年4月にNOT A HOTELを創業 https://t.co/dlAu1Stvaq 濱渦伸次| NOT A HOTEL CEO @shinji_hamauzu お世話になってるアパレル経営者のIT相談に乗ってたのだけど、数千万かけてつくろうとしてたシステムが、SaaSの組合せでほぼ0円で実現できる事が判明。「保険の見直し本舗」ならぬ「システム見直し本舗」みたいなフラットな相談所つくってよと言われ、マジでニーズあると思ったので誰か笑 2020-09-24 09:11:46 小島辰弥💅 ｜AI年齢診断マイナス15歳 @tatsuya_kojima @shinji_hamauzu まさに

カラーミーショップ サービス基盤チームのkymmtです。この記事では、サーバサイドレンダリングするシングルページアプリケーションとAPIサーバからなるWebアプリケーションのセッション管理方法について紹介します。 アプリケーションの構成 構成の概要 今回は例としてEC事業部で提供するカラーミーリピートをとりあげます。構成としては、Railsで作られたAPIサーバ1と、Vue.jsで作られたシングルページアプリケーション(SPA)からなります。また、SPAはExpressが動くフロントエンドサーバでサーバサイドレンダリング(SSR)します。APIサーバはSPAかフロントエンドサーバだけが呼び出します。各ロールはサブドメインが異なります。 APIサーバでセッションIDを持つCookieを発行し、Redisを用いてセッション管理します。また、APIサーバへのセッションが有効なリクエストはフロント

開発者にはしばしば必要なものがないという状況が訪れます。デベロッパーエバンジェリストの成瀬氏が、実際に10名弱のチームで新規プロダクトを作る際にクリーンアーキテクチャの構成を実践してみた話をしました。　Part.3はクリーンアーキテクチャの実装例について。動画はこちら。 これに従って実装すれば、見えるものがあるんじゃない？ 詳しくいきましょうか。実装例がどういうものか？ 右下の図がすごく大事という話をしましたよね。これをもっと細かくしましょう。そういう図が実はクリーンアーキテクチャのWebと書籍にもありました。Robert C. Martin、この人はかなり有名な人で、あのSOLID原則を定義した人です。Robert C. Martinがこのクリーンアーキテクチャというのを発表して、iOSクリーンアーキ……iOSのほうでかな。発表して（※のちに勘違いだったとYouTube説明欄で訂正）、そ

こんにちは。 ご機嫌いかがでしょうか。 "No human labor is no human error" が大好きなネクストモード株式会社 の吉井です。 今回は AWS Perspective を紹介します。 Developers.IO を読んでくださっている方々はシステム担当者(アプリもインフラも)が多いと想像しています。 みなさまは詳細度、解像度の高低はあれどアーキテクチャー図を作成していることと思います。 個人的な意見ですが、作成ドキュメントの弱点は ”更新されないことがある” ことにあると考えています。 変更管理を細かく行っている企業ならそんな心配は要らないかもしれませんが、大抵の場合システム稼働日数が増えれば増えるほどドキュメントは置いてけぼりになりがちです。 それはある意味理解ができてドキュメントは無くてもシステムは動くので、システム構成変更時のドキュメント更新の優先度が下

最近良く話していることなのですが、社会人として働き始めた新卒の技術者は、最初の数年は成長していきます。与えられた業務を遂行しながら、そのための学習もしていくからです。しかし、2、3年すると開発業務をこなせるようになり、特に新たな勉強をしなくても、日々、会社に行って開発業務が遂行できるようになります。 この状態、つまり、継続した学習をしなくなった状態で、10年とか経過すると、ソフトウェアの世界は大きく変化している可能性があり、新たな技術が登場し、その人の技量は相対的に今度は低下しはじめます。しかし、この時点で、新たなことを学習するのは困難だったりします。学習する習慣が無いわけですから、勉強しろと言っても、「なぜ、休みの日に勉強しなければならないのですか」ということになります。 そのような人に対して、マネジメントは、その人ができる仕事を与えて、何とか仕事をしてもらいますので、「新たなことを勉強

JavaScript での時刻操作に Moment.js ではなく Day.js を利用し続けている理由2020/09/21 昨日、拙作の Nuxt.js プラグインである @nuxtjs/dayjs の v1.2.0 をリリースしました。 このプラグイン自体は2019年3月に開発をはじめて、おおよそ一年半ほど管理してるのですが、それ以前から JavaScript での時刻操作では Day.js を使ってきました。 Moment.js のプロジェクト終了が告知され、時刻操作ライブラリに注目が集まっていることなので、今一度 Day.js の採用理由についてまとめてみます。 Day.js について iamkun によって開発されている時刻操作のライブラリです。Moment や date-fns などは Organization によって管理されていますが、時刻操作ライブラリとしては珍しく個人に

しばらく前、React 17 RCが発表されました。現行のReact 16に比べて、いくつかの破壊的変更がある一方、新機能が何もないというのが特徴です。Reactチームとしては、新機能が無いとはいえ、破壊的変更も少なくなっておりなるべく16から17へのアップデートを行なってほしいという考えのようです。 この記事では、React 17における破壊的変更のうち、useEffectのクリーンアップのタイミングに関する変更を取り上げます（以下は公式サイトから引用）。 In React 17, the effect cleanup function also runs asynchronously — for example, if the component is unmounting, the cleanup will run after the screen has been updated.

突然ですが、以下の機能がそれぞれどういうものか すべて ご存知でしょうか？ CloudWatch ServiceLens X-Ray CloudWatch Contributor Insights CloudWatch Synthetics CloudWatch Container Insights CloudWatch Logs Insights CloudWatch メトリクス Metric Math 検索式 カスタムメトリクス CloudWatch ダッシュボード CloudWatch 異常検出（Anomaly Detection） CloudWatch 埋め込みメトリックフォーマット CloudWatch アラーム 異常検出に基づいたアラーム 複合アラーム 私はわからなかったですね。ここ 1〜2年のCloudWatch系のアップデート量は凄まじいなと個人的には思っていて、Cloud