「Rails vs Node.js」を観た｜laiso
このYouTubeライブはフロントエンドの最適化を専門にするmizchiさんがCloudflare Meet-up Tokyoで行った同タイトルのプレゼンを、RustやRDBの実装に詳しいkoba789さんを話し相手に語っていくというものだ。背景としては2人ともチーム開発の現場でのRailsが活発に利用されていた時期にウェブ開発を経験し、現在はNode.jsのサーバーサイドも実践している。 ライブは3時間半という長時間におよび、スライド外の周辺情報や持論や余談など多岐に渡るので、すでにこのプレゼンに触れた人でもさらに深掘りできるようなコンテンツになっている。 全体を大まかに1時間ごとの3パートに区切って視聴するとわかりやすい。前半はRailsからNext.jsに辿り着くまでのウェブ開発の変遷。ORMの話は主に後半戦で。最後の1時間はアフタートークになっている。 内容としてはRailsアプリ
視座を上げない自由｜laiso
ビジネスパーソンとして経験を積んでゆくとだんだん組織とか事業に対して影響を与えることを期待されたり自ら望むようになって視座が上がっていく これは個々の意志の問題ではなくピラミッド型の集団が成長する構造によって自然に発生する特性だと考えている なので成長する組織で誠実に過ごしているとコミットメントに応じて勝手に視座が上がっていく そうでない場合はブリリアントジャークになっているのかもしれない 私はこれをコントロールしたいといつも思っている 例えば飲み会で全社一丸となってがんばっていきまっしょい💪と発言した数時間後にもう余生は猫を吸うだけの生活をしたいと発言したとしても問題なく両方の気持ちは成立してほしい ひとつは組織に属さないことだと思う コンサルは視座を運用する商売であるからのぞくとして、たとえば下町の1人親方の技術工は平均的なメガベンチャーのエンジニアリングマネージャーより視座が低い
デバッガーをどう使っているか｜laiso
まわりのサーバーサイドエンジニアでデバッガーを使っている人は思ったより少ない 感覚で言うと半数ぐらい プリントデバッグとE2Eテストでなんとかなるらしくそれは私も同意する これは作っている対象がステートレスなウェブアプリケーションだというのが影響していると思う モバイルアプリやフロントエンドのSPA開発はステートフルなので内部状態を確認しながら開発したいタイミングが結構ある 私もXcodeとgcc のデバッガーで便利さを覚えた ただ最近はステートレスなコンポーネントを構築するスタイルに移ってきているのでなんとかなるのかもしれない コミュニティによって差もあり、言語処理系や組込み系、システムプログラミングに違い領域の人は常用していたりする これによってRailsはRuby処理系の人たちが多かったのでpry 人口が多かった気がする でデバッガーの使い方なんですけどブレークポイントで止めて変数を
自分を救うプログラミング｜naoya
子どものころは絵を描くのが好きだった。 学校の休み時間は、クラスメートはみな外にサッカーをしにいっていたが一人教室にのこってノートに漫画を描いている、そんな小学生だった。 自宅に戻っても、自室にこもってよく漫画を描いていた。 漫画と書くいっても、別に人を楽しませるために描いているわけではなかった。もちろん褒められると嬉しかったが、それが目的だったわけではなく、いま思えば、それは自分で自分を癒すかのような行為だった。自分を救うために絵を描いていた。 絵を描いているときは、それに夢中で没頭していて、ほかの何にも代えがたい時間を過ごすことが出来た。この時間が、どこか自分の救いになっていた。 中学二年生ぐらいになって思春期にさしかかった頃だろうか。教室で絵を描いていると浮いてしまうことに気づいて、恥ずかしくなって、描かなくなった。 それでもやっぱり絵を描いたりなにか作品を作ったりするのは好きだった
パスキーは本当に２要素認証なのか問題、またの名を、あまり気にせず使えばいいと思うよ。｜kkoiwai
この記事の内容は、個人の意見であり感想です。くれぐれもよろしくおねがいします。 とりあえずドラフトですが公開します。識者のみなさまの暖かく、そして鋭いツッコミを期待します。 パスキーについて、非常にわかりやすいブログをえーじさんが書いてくださいました。コレを読んで頂ければほとんどのことが分かると思います。 先日の次世代Webカンファレンスで、私は、「結局、パスキーは秘密鍵と公開鍵のペア」と申し上げた立場からも、この疑問はごもっともだと思いましたので、すこし、私の思うところを述べたいと思います。 パスキーは２要素認証の場合が多いほとんどのユーザは、OS標準のパスキーを使うのではないかと思います。そして、生体認証、もしくは画面ロック用のパスワードやPIN等が設定されていない限り、OS標準のパスキーを使うことができません。そして、OS標準パスキーの利用時には、生体認証もしくは画面ロック解除のため
パスキーとID連携の関係を考察する際の観点｜ritou
パスキーの登場以来、ID連携、特にソーシャルログインは認証方法として比べられることが多くなりました。この記事では、この2つを比較したりその関係を考察する際に意識しておくべき観点を整理しておきます。 それぞれの特徴両者は異なる特徴を持っています。 パスキー 用途: 認証 パスキーの管理: プラットフォームが提供するパスワードマネージャー、サードパーティーのパスワードマネージャー、セキュリティキー、ブラウザ 属性情報: 一緒に保持できて引き回せるデータは User Handle ぐらい ID連携 用途: 新規登録、認証、属性情報の取得/同期 アカウント情報の管理: Identity Provider 属性情報: プロフィール情報、確認済みメールアドレスなどを取得可能なのが一般的 特徴が異なるために、導入箇所や意味合いも異なります。 ざっと思いつくのが 新規登録 ログイン 再認証 ぐらいでしょう
ライブラリを気軽に導入しないこと｜Katashin
本をよく読むエンジニアであれば、ライブラリの導入には慎重になるべきだということは共通の認識になっていると思う。しかし、どういったライブラリを導入すべきかという選定基準は自分の中ではまだ言語化できてないことに最近気がついた。絶対的な基準を設けるのではなく、ある程度柔軟に考えるべきだと思うが、自分がどう考えて選定するかを考えてみる。 品質 テストが書かれているか 自分のプロダクトでテストを書いているのであれば、ライブラリにもテストを求めるべき 長い間継続してメンテナンスされている（いた）か 急に出てきてセンセーショナルな売り文句で注目を浴びるライブラリは怪しむべき コードの品質は悪くないか 導入する前にライブラリのコードは読むべき 効果 その後の実装効率をどれだけ上げるか 導入しない場合と大して変わらないのであれば不要 自分でそれを書いた場合と比べてどうか 短時間で同じようなものを書けるのであ
都内から地方移住して家ビルドした体験談｜yymm
こちらは子育てエンジニア Advent Calendar 11日目の記事です、しずかなインターネットからお送りします。初参加です、お手柔らかによろしくお願いします。 まずはじめに私の子育て状況私は都内のとあるスタートアップにてソフトウェアエンジニアとして働いています。ご人家族で三人の女の子のパパです、上から8歳、5歳、3歳になります。 子どもが小さく超絶大変な時期を乗り越えつつあり、どちらかといえばこれからの進学などを見据えた教育費のことや住環境への関心度合いが高まっている頃合いです。色々大変だった頃の話はいくらでもあるのですが、今回の記事は特に住環境についての話になります。 地方移住タイトルにもある通り現在はすでに静岡県三島市に在住しており、家を建てました。念願のマイホームパパです。 もしかしたら子育てをしている方で地方移住を検討している方もいるかなと思い、私の移住にあたっての体験談を共
GraphQLのよくないところ｜adwd
銀の弾丸ではないので良し悪しあるのは当然として、それを差し引いても以下の2つの要素があるのではと思った。 なんとなく使ってもメリットが十分得られない RESTでできてたことができなくなる（※ちゃんと調べればできる） なんとなく使ってもメリットが十分得られないWeb界隈は良くも悪くも新しい技術をとりあえず使ってみるところがあると思っていて、そこがGraphQLは十分に事前知識を持って導入しないとメリットが薄いところとミスマッチを起こしてネガティブな意見が出るのかなと思う。 GraphQLはもともとFacebookがReact, Relayとの組み合わせで使い始めたもので、クライアントライブラリとしてのRelayと、IDやページネーションについての追加仕様を公開している。ライブラリとしてのRelayは使わなくても仕様に乗っかることはできるのでそれをRelayスタイルと言ったりする。出典を忘れた
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
