はてなブックマーク

この記事はNuco Advent Calendar 2023の1日目の記事です。 はじめに 2023年最新のフロントエンド開発環境についての紹介記事です。 分野別に、おすすめツール群と、その特徴などを紹介していきます。 デファクトスタンダードとみなせるようなツールや、最近盛り上がりを見せているものなどをラインナップしました。 これからフロントエンド開発を始めたい人はもちろん、長くご経験のある人にもプラスになる情報がきっとあるため、ぜひ参考にしてもらえると嬉しいです。 フロントエンド開発おすすめツール集 エディタ エディタやIDEは好みの問題も大きいので、メジャーなものを簡単に紹介だけしておきます。 Visual Studio Code もはや説明の必要が無いほどに普及しているエディタと言っても良いと思います。 フロントエンド向けの拡張機能も幅広く存在しているため、自分に合うカスタマイズが可

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

各機能とツールについて、説明していきます。 エディタ Visual Studio Code エディタやIDE(統合開発環境)は好きに選んでいただければ良いとは思いますが、特に希望がないならば、Visual Studio Codeを選んでおけば間違いないでしょう。 Pythonを含む幅広い言語に対応し、豊富な拡張機能を備えている非常にリッチなエディタです。とりわけPythonプロジェクトについては、これさえ有れば、特にIDEなどは必要ないと思います。 インストールは↓から。 バージョン管理ソフト Python3系は日夜アップデートされていて、2022年12月現在の最新verは、3.11.1が提供されています。 とはいえ、プロジェクトによっては、3.7.1までしか動作が担保されていないもの、3.9.0で現在開発中のもの...などがあります。最新のPythonが常に必要、というわけでは決してなく

この記事はNuco Advent Calendar 2022の18日目の記事です データ可視化のアンチパターンとは？ そのチャート、分析結果を正しく伝えられてますか？ データの調査・分析タスクはデータサイエンティストの花形とも言える業務ですが、その結果を正しくレポーティングすることは、それらと同等か、もしくはそれ以上に重要なミッションです。 あなたがいかに巧みに、膨大なデータを俯瞰し、切り口を見定め、ビジネスインパクトがあると考えられる統計的特徴を見出したとしても、レポーティング・可視化の仕方が悪ければ、相手に全く伝わらないことが起こりえます。 この記事では、そんな「やってはいけない」データ可視化の方法を紹介していきます。 データサイエンティストだけでなく、あらゆる資料作成者が最低限守るべき可視化の基本になりますので、ぜひチェックしてみてください。 「伝わる可視化」と「伝わらない可視化」

はじめに 「未経験だけど、エンジニアになりたい」という人に、僕がまずやってもらっていることを、この記事にまとめてみました。 「習得してほしい」というのももちろんですが、何よりも自分自身がエンジニアに向いているかを確かめる意味でも、これらを一通りこなすことがその試金石になるのでは...と考えています。 以下、やってみてほしいことと、その理由を書いていきます。それぞれ、無料で取り組めるサービスがあるものは、それも紹介していきます。 ブラインドタッチの練習 初っ端からプログラミングと関係ない感じですが、この業界に携わる上での根幹部分になると思ってます。 タイピングスピードは、あらゆるタスクの解決スピードを底上げしてくれます。コーディングはもちろん、ちょっとした調べごと、メールやチャットでの相談など、仕事のあらゆる場面で、僕たちはキーボードを触ることを求められます。 エンジニアに限った話ではないで

この記事の目的 「プログラミング学習につまずいている」 「基礎的な式や文は覚えたけど、応用できずに悩んでいる」 そんな人達に、「自分がうまくいかない原因が何なのか」を考えるきっかけにしてほしいです。 特に、「プログラミングで何か問題を解く」的なことが苦手な人に、少しでも参考になればと思います。 「プログラミングができない」をもっと細かく切り分けてみる 「プログラミング難しい、向いてないかも...。」と思う前に、「自分が何につまずいているのか」を分析してみましょう。 実は、難しいのはプログラミングじゃない？ プログラミング自体は、あくまでコンピュータに何かを実行させるための命令でしかありません。 なので、そのやりたい「何か」自体が難しい場合、自ずとそれをプログラミングするのも難しくなります。 ただ、目の前で取り組んでいるものが「プログラミング」なので、その状態を「プログラミングが難しい」と考

概要 AWS Fargate の起動が遅くてつらいことが多く、イメージサイズを減らせば速くなるんだろうか、ということを調べてみた。 結果 「起動時間」には以下の構成要素が含まれていると推測する。 ENI の Allocate (10秒程度) コンテナイメージの Pull (かかる時間のほとんど) コンテナの起動(Firecrackerの起動？) IAM 関連の処理 AWS のネットワークはだいたいリソースサイズによってパフォーマンスが設定されているものがほとんどなので、Fargate も同様であると考えられる。 そのため、リソースが大きければそのぶんイメージの Pull にかかる時間は短縮されると考えられる。 Fargate のネットワークの性能については、計測された記事があった。 今回、各10回ほど繰替えし計測を行なったが、起動時間の変化はほとんどなかったため、イメージはキャッシュされて

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

はじめに ここのところ terraform を使い AWS の構成を管理するようにしています。 コードで管理することで、PullRequestベースでレビューしあうことができ、かつリポジトリに過去の履歴が全て残るという点がすばらしいですね。 その分、コードに落す工数がかかってしまいますが。 今開発しているサービスでは Mackerel を監視に使用するつもりでいます。 Mackerel は go で書かれたライブラリがあり、簡単にAPIへのアクセスができます。 監視ルールも AWS と同じく terraform で管理できると良いな、と思い、terraform で Mackerel を管理する provider を作ってみました。 terraform-provider-mackerel terraform-provider-mackerel とは Hashicorp社が開発している ter