Romeは本当に速かった - @ledsun blog
RomeプロジェクトのJavaScriptフォーマッターがリリースされました。 rome.tools ちょうどPrettier を使っているプロジェクトがあったので比較してみました。 本当にめちゃくちゃ速い。 prettierで8秒掛かるのが0.5秒とかで終わる。— ぎゃばん@手洗い (@ledsun) April 6, 2022 prettierを速く動かしたくてparallel-prettierに.prettierignoreを読む修正を加えて動かして速くなったか - Qiita でNode.jsのまま並列化したparallel-prettierを試したときは やったね1.25倍速くなりました！ でした。 それと比べてるとRomeは10倍以上速くなっています。 驚異的です。 JavaScriptパーサーやASTを扱うライブラリーなどの資産がないrustで書き直すのは、大変な労力に思えま
Node.jsのスーパープログラマ達の今 - @ledsun blog
僕がNode.jsを熱心に勉強していた頃に、スーパープログラマとして憧れていた人たちが、今何をやっているのか調べてみました。 github.com Express.jsなんかを作っていたtjは、Go言語がメインに書いているようです。 OSS活動自体あまりやっていなさそうです。 github.com Browserifyをつくっていたsubstackは、主にrustを書いているようです。 サーバーを書いていた人はGo言語に、CLIを書いていた人がrustに行くのかもしれません。 github.com Babelを書いていたsebmckもrustです。 github.com Rad VaggはGo言語とPythonのようです。 github.com tjfontaineはOSS活動がほとんど無くなっています。 ここからはNode.jsを去っていない人たちです。 github.com Guill
#技術書典 #技術書典4 で「現代Webフロントエンドデザインパターン」を頒布します - @ledsun blog
techbookfest.org モチベーション これを解消したくて「現代Webフロントエンドデザインパターン」書いているけど、とてもSPA/SSRまではたどりつかない。（それ以前の部分で、僕の書く同人誌としては、十分のボリュームになっている。） https://t.co/BSMQwPRxfP— ぎゃばん＠技術書典4 か-20 (@ledsun) 2018年4月16日 Webフロントエンドの技術は、なかなか必要な状況や解決したい問題が明確にされないまま「流行っているからこの技術が良い」みたいな選択されることが大いように思っています。 もちろん、「新しくてかっこいい技術を使いたい」というモチベーションで新しい技術に取り組むのは良いのです。 それはそうとして、うまくマッチしない問題に適用してみて「イマイチな技術だ」っていう感想を抱いたり、 あれもこれも流行っているのに「どれにも自分は手を出せて
エンジニアの採用面接対策 - @ledsun blog
paiza.hatenablog.com に、面接で落とした理由があります。 最近は技術者が面接をすることが多いです。 技術者は採用面接に不慣れなことが多く、質問が下手くそです。 面接官側の不手際で、コミュニケーションに齟齬があって落ちていることもあると思います。 自分の採用面接経験での「こういうことが聞きたかったんだよ」という辺りを書きます。 実践すれば面接に受かることを保証するものではありません。 1位：自己表現(プレゼンテーション)力 職務経歴を聞かれて、一から十まで細かく説明しようとする人 面接の最初にお互いの緊張をほぐすために、自己紹介をしてほしくて使います。 面接官がどっから本題に入っていいのかわからないので、とりあえず聞いてみます。 30秒〜1分くらいで、簡単に説明してもらえれば良いです。 内容よりは、喋り方を見ています。 評価をするためよりは、これから会話をして行くときに「
優秀なプログラマになるために - @ledsun blog
みんな良いこと言うので、刺激を受けて考えたことを記録します。 生きてるだけで丸儲け ストレス対処法 撤退戦術 タスク殺すマシーン 人間に戻る儀式 運 技術力を身につける方法 車輪を再発明する 脱ゴールデンハンマー病 学習の助 優秀なプログラマとは？ おまけ 生きてるだけで丸儲け 優秀なプログラマーになるためのコツ · GitHub 優秀なプログラマーに「育つ」んだし、それには時間が必要 優秀なプログラマーになるということは、上記の通り長時間を要するということも踏まえると、メンタルヘルスにリスクがある環境に長時間暴露されることが不可避である 業界で長きにわたり活躍し続けている人というのは、それだけですでにひとかどの人物 すごく良いです。 優秀なプログラマになる前に、死んでしまっては元も子もありません。 生き延びることはなにより大切です。 幸か不幸か現状のIT業界はハードなストレスにさらされや
論理削除フラグという名の死亡フラグ - @ledsun blog
RDB - DELETE_FLAG を付ける前に確認したいこと。 - Qiita 論理削除が云々について - mike-neckのブログ Kazuho's Weblog: 論理削除はなぜ「筋が悪い」か 流行っているので乗っかります。 結論 「データ制約の強力さと集合としての表現力を捨てながら、Relational Databaseを使うのはなぜか？」 論理削除フラグのデメリット 大体三つあると考えています。 ユーザーの言葉でない データ制約の弱さ 集合として認識できない ユーザーの言葉でない 私の経験上は、ユーザーから「論理削除」という言葉を聞いたことがありません。 次のような要件は、聞いたことがあります 社員が退職（・転属）する （売掛金の回収を諦めて）売上を打ち消す 「お知らせメッセージ」を公開日がくるまで非表示にする 既読メッセージを表示しない 保存期間が過ぎたアンケート結果をオペレ
えぇー！MVCのContollerはプレゼンテーションロジックのinput担当だったのかい！？ - @ledsun blog
この話はMVC（Model-View-Controller）の話です。 特にクライアントMVCの話です。WebMVCの話ではありません。 事前 ViewとModelを分けるためにControllerを挟むのだと思っていました。 事後 Contollerはプレゼンテーションロジックのinput担当でした。 参考文献 The Model-View-Controller (MVC) Its Past and Present を読んでください。すべてが書いてあります。 本題 WebMVCから考えた俺のコントローラー そんなことより聞いてくださいよ。 WebMVCからMVCに入った口としてはViewとControllerの分け方なんて考えたこともないんですよ。 分かれてて当たり前ジャンと思ってたんですよ。 ところがJavaScriptで3000行くらいあるDOMをゴリゴリするアプリケーションをいじっ
社内勉強会はヤメだ。自主的はいらん、全員技術発表だ！ - @ledsun blog
社内勉強会について僕にも思うところがある*1。 社内勉強会をやらない理由 - 勘と経験と読経 社内内弁慶を社外勉強会に参加させる方法: ソフトウェアさかば 最初に言っておくと弊社は20人くらいしか居ないし、受託開発と派遣が半々くらいのSIerだ。 id:kent4989 の会社とはだいぶ状況が違う。 社内勉強会はやらない 結論から言うと社内勉強会はやっていない。やらない理由は発表者のコストが高くてメリットが少ない。 勉強会のつらさ IT系の勉強会のノリだと テーマに対して興味のある人が少なく参加者が少ない 最新ネタは業務と離れすぎていて、継続する努力がハイコスト過ぎる 研修のつらさ 教育を重視して基礎的な内容をやると 基礎的な内容だと教える側が刺激が足りなくて飽きる 教える側が教えるほどは理解していないので、事前準備がハイコスト過ぎる そんなわけで社内勉強会をやるのはやめました*2。 技術
アジャイルがダメなようでダメじゃないちょっとだけダメだと思う7つの理由 - @ledsun blog
素晴らしいエントリが立て続けに出ているので便乗します。 id:arclampさんのアジャイルがダメだと思う7つの理由 id:haradakiroさんのアジャイルがそんなにダメだと思わない7つの理由 1.全体スケジュールにコミットできない 主語を間違えやすいけど 経営者は顧客やVCと全体の計画にコミットしなきゃいけない の通りで全体スケジュールにコミットできるのはスポンサーだけなんです。開発者は「努力すること」しかコミットできません*1。 現実問題として、プロジェクトを上手くスタートするにはゴールをいつまでに何かって決める必要があります。アジャイル開発でも重視している。アジャイルサムライはインセプションデッキにかなりのページ数を割いています。 2. アーキテクチャ上の無駄が生じる アーキテクチャ設計を慎重に考えても元のビジネスモデルがウンコだったら役に立ちません。困ったことにビジネスモデルは
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
