IEサポートやめます！で使えるようになったもの
去年IEのサポートがきれ、やっとIEを気にせず制作ができるようになりましたね。 でも結局、IE対応が板につきすぎて、便利なプロパティを使い損ねたままコーディングしていませんか・・・？ ということで、「IE対応しなくていいなら、これも使えるよ！」をまとめていきたいと思います！ 自分用のメモも兼ねているので、網羅はせず、よく使いそうなものに絞っています。 (逆に「IEだめだったんだ、気にせず切り捨ててた・・・」みたいな要素やプロパティも省いてます。) IEなしなら使えるcss 改めて知ったので使っていきたいな〜 accent-color, caret-color accent-colorでフォーム要素(inputなど)の色がまとめて指定できます！ (caret-colorはキャレットのの色) フォームって、別のシステムが入る場合、デザインのトンマナを完全に合わせらないと思うのですが、 アクセン
エンジニアのための「Notion」入門
株式会社SODAの社内勉強会で使用した資料です こちらは株式会社SODAのエンジニア社内勉強会にて @decoch が発表したときの資料です。 株式会社SODAについては以下リンクなどをご覧ください。 これはなに？ いま流行りの Notion を使っている方は多いと思うのですが、いまいち使いこなせていない、メモ帳としては使っているけどデータベースってなに？ というエンジニアの方向けに Notion の使い方を書いた入門記事です。 Notion とは notion.so からお借りしました ドキュメントやテーブルだけでなく望み通りに機能するようにカスタマイズできるワークスペースです。 基本的な使い方 新しくページを作りメモをとったりチェックボックスでタスクを管理したり、Markdown のように使うことができます。 / と打つことでサジェストされ /page と入力し決定をすると新しいページ
Nuxt3で個人的にuseFetchよりuseAsyncDataを推したい理由
はじめに Nuxt3の安定版がリリースされ、しばらく経った。現在筆者もNuxt3を活用しているプロジェクトがある Nuxt3は以前の2系にも増して更に強力な機能を公開しており、快適な開発体験を提供してくれる 代表的な機能としては Auto-imports Data-fetching utilities Zero-config TypeScript support Universal rendering (Server-side rendering and hydration) といったものがある。またNitroという新しいサーバーエンジンが導入され、より高いパフォーマンスでのレンダリングが可能になった そしてNuxt3では2つの新しいAPIであるuseFetchとuseAsyncDataが導入されている(useLazyFetchとuseLazyAsyncDataも含めれば4つ)。useFe
どうやって技術的負債の雪だるまを生み出し、それを返済してきたか - 5年半越しの設計論
恥の多い生涯を送って来ました。 システムを開発していると、本当に多くの恥が生まれます。たとえば、こんな恥です。 テーブルの名前を付けミスったりは日常茶飯事。私が付けた変な名前が、自社の営業どころか他社のユーザーにまで浸透してたりもする。例えば、唐突に商品マスタに出てくる「グルーピングタグ」というカラムとか。（まじで意味不明） いま商品マスタと呼ばれているマスタの物理名が「kiosk_pricings」とか。日本語でおｋ。kiosk_pricings.grouping_tagってなんだよ。 「pricing」テーブルにはpriceカラムがあるが、全てのレコードで0になっていて、システムでは一切使っていないとか。（そのうち消したい） システムで使われている"正解"はkiosk_pricings.priceでした〜。 親子関係を間違えた事もある。チケットと決済の親子関係を入れ替えたりもした。 ま
実践 よくないコードに立ち向かう整理術 〜あなたのコードはどんな色？〜
ありがちな仕様とコードを題材に、よくないコードに立ち向かうための整理術を紹介します。 この Book にはデザインパターンや DDD やオニオンアーキテクチャや関数型プログラミングなどは一切登場しませんが、それらのエッセンスと日常のコーディングにおいて求められる基礎的な考え方の説明が含まれています。 この Book の内容は、特定の業務領域やプログラミング言語・フレームワークには限定されません。 Laravel でも RoR でも Spring でも React でも Nuxt.js でも、きっと役に立つはずです。 逆にこの本にはクラス設計のべき論や OOP vs FP のような議論は含まれません。 画一的なコードの良し悪しの定義は難しいですが、何かしら得るものがあったと感じてもらえたらうれしいです。
AlfredやClipyをやめてRaycastを導入したら、生産性爆上げだった件
Raycastとは Raycastとは、非常に高速で拡張可能なMacのランチャーアプリケーションです。Macの標準機能であるSpotlightの自由度を高めたようなアプリで、優れたUIUXによる利便性や拡張性も兼ね備えており（割と手軽に）作業の生産性を大いに高めることができます。 しかも、個人利用は実質無料（2022年10月現在）で、ユーザー登録をせずともすぐに生産性を向上させられる神アプリです🌟 以下公式サイトもしくは、Homebrew経由でインストールできます。 ■ 公式 ■ Homebrew Alfredからの卒業 Macの有名なランチャーアプリとしては、Alfredが非常に有名だと思います。今回紹介するRaycastと同様、様々な機能が用意されており、快適な作業と生産性の向上に大きく貢献する便利なアプリケーションです。 ただ、Alfredを本気で便利アプリとして使いこなすためには
【日々更新】Visual Studio Codeの便利なプラグインまとめ（コーダー・マークアップ・フロントエンドエンジニア視点）
Visual Studio Code（VsCode）本体のインストール まだインストールされていない方は、以下からVsCode本体をダウンロードしてください。 VsCodeのおすすめプラグイン（コーダー・マークアップ・フロントエンドエンジニア視点） 私が導入しているVsCodeのプラグインを紹介します。 フロントエンドエンジニアとして働いている自分の普段の業務ではHTML CSS Sass(Scss) EJS Pug JavaScript TypeScript React Next.js PHP WordPress Markdownファイル等を触ることが多いので、それらに関連したプラグインが多くなっています。 共通 プラグイン名 機能
話題のStable Diffusionがオープンソース化されたのでローカルで動かしてみる
話題のStableDiffusionがオープンソースで8/23に公開されたので、手元のマシンで動かすまで試したいと思います🖼 (下記に記載していますが、自分の環境だとVRAMが不足しているエラーが出てしまったのでイレギュラーな対応をしています🙏) ※ ↑追記 コメント欄にて、 @kn1chtさんが紹介してくださっているように、マシンのVRAMが10GB未満の環境では半精度（float16）のモデルがオススメされています。 本記事では、別の最適化されたものを紹介していますが、こちらの利用も検討してみると良さそうです👉 https://zenn.dev/link/comments/7a470dc767d8c8 StableDiffusionがどんなものかは、深津さんの記事が参考になります。 1. 環境 Razer Blade (RTX 2070, VRAM 8GB) CUDA Toolk
高齢者向けサービスにおけるUIデザイン｜『高齢者のためのユーザインタフェースデザイン』の書評
現在、本業・副業ともにWEBデザイナーとしてデザイン・コーディングをしているゆるけーです。 本業で携わっているWEBサービスが割と高齢者向けのサービスで、ITリテラシーやUIが今の自分と考え方が異なるよなーと思っているなか、『高齢者のためのユーザインタフェースデザイン』という書籍に出会いました。 高齢者関係なく普通にアクセシビリティの観点でも重要な視点がたくさんあり、とてもいい書籍だったので、ざっくり大事だと思った箇所を抜粋しつつ自分で探した事例等をざっと記事にまとめていきますー。 視覚 高齢者になると視力が低下する傾向があります。ただ、視力の低下＝フォントを大きくするだけではありません。 視力の低下は老眼や光覚の減少などより複雑です。 主な視力の低下の具体例は以下のような点。 老眼：近く・遠くのものの焦点が合わない 周辺視野のぼやけ：画面の端に気づきにくい 中心視野の損失：画面の中央が暗
見積・提案書に書いておくと不幸を減らせる前提条件
はじめに ちょっとつぶやいたら思いのほか需要がありそうだったので、簡単にまとめておきます。 おことわり これを書いておけば、すべての不幸を避けられるというものではありません 提出先との関係性次第では、書かないほうがいいこともあるかも 私自身が普段提案している内容が、すべて記載されているわけでもありません（うろ覚えで書いてたり、大人の事情） これを流用しておこったすべての事項について、何らかの責任をとることはできません 本稿では請負による開発を想定しています でも共有することで、この業界の不幸が減ればいいなということでつらつら書いてみます。 他にもあるようなら、Twitterなりコメントなりで提案してもらえると嬉しいです。 前提条件を書く目的 見積・提案書通りに、実施するために必要な条件を明確にする 条件を逸脱したときに、どうなるのかハッキリさせる 上記は概ねつぎのとおり 実現が不可能になる
Postgres と MySQL における id, created_at, updated_at に関するベストプラクティス
読者対象 ある程度データベースに関する知識を持っている，経験年数 1 年以上のバックエンドエンジニア 特定のプログラミング言語に依存する部分は含めないため，すべての SQL 使用者を対象とする また，ゼロからの丁寧な説明というよりは，リファレンス感覚で使える記事という形にまとめる。 RDBMS の対象バージョン PostgreSQL: 9.4 以降 MySQL: 8.0.28 以降 id （データ型と INSERT 時のデフォルト埋め） 導入 一般的に採用されやすいプライマリキー用の値として，以下を考える。 連番整数 MySQL では AUTO_INCREMENT， Postgres では IDENTITY や SERIAL と呼ばれるもの UUID v1: ハードウェアごとにユニークな単調増加値 UUID v4: ランダム値 UUID v7（ドラフト）: 単調増加であるタイムスタンプとラ
GitHub ActionsにおけるStep/Job/Workflow設計論
この記事について GitHub Actionsには、以下3つの実行単位が存在します。 Workflow Job Step パイプラインを組む中で出てくる複数個の処理を、1つの実行単位でまとめてしまうか、それとも分割するのかというのは悩むポイントかと思います。 一つのstepのrunフィールドにコマンドを詰め込む？それともstepを分けた方がいい？ 一つのJobの中のstepとして記述した方がいい？それとも別のJobに定義した方がいい？ 一つのWorkflowの中にJobをたくさん定義する？それともWorkflowを別にする？ この記事では、Workflow・Job・Stepそれぞれの性質を踏まえた上で、ベストな処理単位の選び方を考察します。 使用する環境・バージョン GitHub Actions: 2022/5/15時点での機能をもとに考察 読者に要求する前提知識 GitHub Actio
ITエンジニア採用入門
今、IT関連の技術は様々な企業の競争力の源泉です。一方で、実際に企業が必要とするよりもITエンジニアの数は少ないため、採用競争は激化するばかりです。そこで、元ウェブエンジニアでITエンジニアの採用担当を経験した私の視点で、ITエンジニア採用に関する情報をまとめることにしました。 なお、ここでいうITエンジニアはアプリケーションエンジニア、インフラエンジニア、機械学習エンジニア、QAエンジニアなどIT関連エンジニア全般を指します。 # 更新情報 * 2022/05/17 - 公開 * 2022/05/17 - 中途採用前提であることを Chapter 1 に追記 * 2022/05/18 - 誤字の修正 Chapter 15 「行進」 -> 「更新」 ※はてなブックマークでの指摘ありがとうございます * 2022/05/19 - 活用事例の Chapter を追加 * 2022/05/20
CTOになったので、やってみたフルリモートワークでの実験的な施策の紹介
この日に関してはリリースの開発工数日に含まないように事前スケジュールし、 普段の仕事中にやれていない対応、作業の整理やコミュニケーションを行なう日としています。 社内イベントは、Gather.Townを使用して運用しています。 メリット / デメリット メリット エンジニアチーム全体に情報を共有するの提供 仕事以外の会話の場が増えた デメリット 運用コスト 特に組織にマッチさせて、継続的に実施できるフォーマットが決まるまでのコストがかかる ある程度繰り返し実施するとフォーマットが確定するのでコストは下がっていく ☕ Coffee Chat 内容 社内イベントで大人数で集まるコミュニケーションの場を設けることはできたが、 リモートで大人数集まっても同時に喋れるのは3〜4人程度ということも、何回か実施して分かってきました。 そこで以下のスライドで紹介されていた、Coffee Chatを取り入れ
【VSCode】開発環境を自動で立ち上げる
突然ですが世の中には2種類のエンジニアがいます。 開発環境をずっと立ち上げっぱなしにするエンジニアと毎回落とすエンジニアです。 自分を含む毎回落とすエンジニアにとって、開発環境を立ち上げる度に複数のターミナルを開き、それぞれでコマンドをたくさん打たないといけないのは苦痛です🥺 そこでこの記事ではVSCodeでプロジェクトを開いたときに開発環境を自動で立ち上げる方法をご紹介します！ おまけで紹介するAlfredまで設定するとコマンド一発で開発環境が立ち上がるようになり、こんな感じになります！ ではいってみましょう！ 対象読者 開発環境を毎回落とすエンジニア VSCodeを使っている 開発環境を立ち上げるためのコマンドがたくさんあって毎回打つのがめんどくさい 環境 VSCode: 1.66.0 macOS Monterey Hello Custom Task! VSCodeでプロジェクトを開
ソフトウェア開発の見積もり入門
見積もりとは？ Wikipediaによると見積もりとは、以下のようにあります。 見積（みつもり。見積り、見積もりとも書く）とは、金額・量・期間・行動を前もって概算すること。見積もること。あらましの計算をすること。また、その計算。目算。「所要時間を見積る」、「一日の来客者数をざっと見積もった」など、おおよその感覚で数字の見当をつける場合の口語体表現でも使われる。 Wikipedia このように見積もりとは、なにかを行う前に事前にその結果を予想しておくことを言います。 見積もりを使うケースは、ソフトウェア開発に限った話ではありませんが、製造業であるソフトウェア開発においては『見積もり』というタスクは様々なケースで登場します。 見積もりが苦手な人は多い ソフトウェア開発では、「この機能を開発するときにどのくらいで完成できますか？」といったケースが見積もりのシチュエーションとしては多いかと思います
ランニングコストほぼゼロから始めるスケーラブルな本番環境
はじめに 私は個人開発で一山当てたいと常々思っていて、そのためにいくつかヒットしそうなサービスのアイデアがあります。エンジニアであればアイデアを具現化することに躊躇してはいけないと思うわけですが、一度リリースしてしまうとランニングコストが発生するわけで、仮に全く人気がでなかったとしたらランニングコスト分の赤字を垂れ流すことになります。 一方、個人開発者というのはおそらく誰しも夢見がちなので、リリース後バズったりしてユーザーが大量に押し寄せてきてしまってサーバーダウンする可能性も考えてしまいます。 その結果、「全く誰も来なくてランニングコストが赤字になったらどうしよう」という不安と「めちゃくちゃバズってしまってサーバーダウンしてチャンスを逃したらどうしよう」という不安が、心の中でせめぎ合うことになります。 そこで、今回はその2つの不安を一気に解消する「使われなければランニングコストが限りなく
webアプリ開発における環境変数まわりのベストプラクティス
nodejsを例に解説します。nodejsでは環境変数はprocess.env.環境変数名でとりだせます。また、開発環境・テスト環境・本番環境をそれぞれNODE_ENVという環境変数にdevelopment test productionと入れる文化があります。 アプリケーションコードに自分が今いる環境(開発|ステージング|本番)を意識させない これはつまり、コード内で環境識別変数(今回で言うところのNODE_ENV)によってif分岐を作らないという意味です。各環境にどのような設定が入るかはアプリケーションコード外にその種類分作成しましょう！ bad if(開発環境){ const logger = new Logger({ level: 'debug' }); } else if (ステージング環境){ const logger = new Logger({ level: 'info }
大企業でプロダクトエンジニアとして働いたら、コーディングのスキルが下がっていた
背景 Shopifyという会社に1年半前に転職しました。あれよあれよと会社が拡大して、現在は従業員一万人弱くらいです。 画像元 公式ではない雑な情報です。あくまでイメージ その前はChartmogulという、せいぜい20人、30人ぐらいの会社にいました。 なぜ表題のようなことを思ったか 面接インタビュアー側として、出題することになるコーディング問題を自分で試しに解いていました。一年半前には自分が受ける側の立場だったので、自分の腕前の定点観測ができました。 やってみてどうだったか。 コーディングにおけるシャープさという観点では明らかに衰えているな、と思いました。問題が与えられて、それに短時間で、論理的に向き合う力とでもいうのでしょうか。 自分は現職でマネージャの立場になったわけでもないので、これはマズイ。なんとなくこの一年くらいそんな気はしていたので、これを機会にもうちょっと深堀してみます。
Production Ready GraphQLはGraphQLを採用するなら必ず読んでおきたい良書
タイトルのとおりです。この本を読まずにGraphQLについての記事を書いたりしツイートしてたのが恥ずかしいくらいに良質なプラクティスが記載されています。GraphQLを採用して悩むことのほとんどはこの本に書いてあるくらいな印象で、この本を読むと効率よくGraphQLを使った開発の品質を向上できると思います。 どんな人が書いた本なのか 著者はMarc-André Girouxという方で、GitHubとShopifyに勤務しGraphQL APIを開発する仕事をしていたと書籍に書いてあります。GraphQLをやってる人ならこの時点でもう刺さったかもしれませんが、どちらの企業もGraphQLを採用していることで有名です。GraphQLスキーマを設計する上でGitHubやShopifyのスキーマや記事を参考にする方も多いのではないでしょうか。その両方で働いてたという時点で納得の説得力です。Grap
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
